One of the topics from today's jabber session was how to handle DNS
queries with the advent of a DNS RR record in the future. Do we keep the
TXT references in the current document? Do we make references to the DNS
RR record? Do we define in base how to cascade from RR to TXT? It all
boils down to the question of "what does q=dns" mean.
My suggestion in the jabber session was:
1) making q=dns mean *only* a DNS TXT lookup,
2) define that lookup within base
3) when the DNS RR draft comes out, it would also define a new q=
value, something like dnsrr, that says to do a lookup using new
DNS RR record.
4) given that q= can take a list, the question of handling both RR
and TXT records could be denoted by using q=dnsrr,dns, rather
than saying that q=dnsrr should search both.
Specific suggested wording changes from -01 follow.
Tony Hansen
tony(_at_)att(_dot_)com
Section 3.5:
OLD: q= A colon-separated list of query methods used to retrieve the
OLD: public key (plain-text; OPTIONAL, default is "dns"). Each
OLD: query method is of the form "type[/options]", where the syntax
OLD: and semantics of the options depends on the type. If there are
OLD: multiple query mechanisms listed, the choice of query mechanism
OLD: MUST NOT change the interpretation of the signature. Currently
OLD: the only valid value iis "dns" which defines the DNS lookup
OLD: algorithm described elsewhere in this document. No options are
OLD: defined for the "dns" query type, but the string "dns" MAY have
OLD: a trailing "/" character. Verifiers and signers MUST support
OLD: "dns".
OLD:
OLD: INFORMATIVE RATIONALE: Explicitly allowing a trailing "/" on
OLD: "dns" allows for the possibility of adding options later and
OLD: makes it clear that matching of the query type must terminate
OLD: on either "/" or end of string.
NEW: q= A colon-separated list of query methods used to retrieve the
NEW: public key (plain-text; OPTIONAL, default is "dns"). Each query
NEW: method is of the form "type[/options]", where the syntax and
NEW: semantics of the options depends on the type. If there are
NEW: multiple query mechanisms listed, the choice of query mechanism
NEW: MUST NOT change the interpretation of the signature. An
NEW: implementation MUST use the recognized query mechanisms in the
NEW: order presented.
NEW:
NEW: Currently the only valid value is "dns" which defines the DNS
NEW: lookup algorithm described elsewhere in this document.
Section 3.6:
OLD: This document defines a single binding, using DNS to distribute
OLD: the keys.
NEW: This document defines a single binding, q=dns, that uses DNS TXT
NEW: records to distribute the keys. Other bindings may be defined in
NEW: the future.
Section 3.6.2:
OLD: 3.6.2 DNS binding
OLD: A binding using DNS as a key service is hereby defined. All
OLD: implementations MUST support this binding.
NEW: 3.6.2 DNS Binding for q=dns
NEW:
NEW: A binding using DNS TXT records as a key service is hereby
NEW: defined, q=dns. All implementations MUST support this binding.
NEW:
NEW: No options are defined for the "dns" query type, but the string
NEW: "dns" MAY have a trailing "/" character. Verifiers and signers
NEW: MUST support "dns".
NEW:
NEW: INFORMATIVE RATIONALE: Explicitly allowing a trailing "/" on
NEW: "dns" allows for the possibility of adding options later and
NEW: makes it clear that matching of the query type must terminate
NEW: on either "/" or end of string.
Section 3.6.2.1:
OLD: 3.6.2.1 Name Space
NEW: 3.6.2.1 Name Space for q=dns
Section 3.6.2.2:
OLD: 3.6.2.2 Resource Record Types for Key Storage
OLD:
OLD: [[This section needs to be fleshed out. ACTUALLY: will be
OLD: addressed in another document.]]
OLD:
OLD: Two RR types are used: DKK and TXT.
OLD:
OLD: The DKK RR is expected to be a non-text, binary representation
OLD: intended to allow the largest possible keys to be represented
OLD: and transmitted in a UDP DNS packet. Details of this RR are
OLD: described in [ID-DKIM-RR].
OLD:
OLD: TXT records are encoded as described in Section 3.6.1.
OLD:
OLD: Verifiers SHOULD search for a DKK RR first, if possible,
OLD: followed by a TXT RR. If the verifier is unable to search for a
OLD: DKK RR or a DKK RR is not found, the verifier MUST search for a
OLD: TXT RR.
NEW: 3.6.2.2 q=dns Resource Record Types for Key Storage
NEW:
NEW: q=dns uses the TXT DNS RR type. The TXT records are encoded as
NEW: described in Section 3.6.1.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html