(Note: part4 of the reply)
On Wed, 13 Jul 2005, Jim Fenton wrote:
6. DNS RR
From section 3.7.2.2 -
"Verifiers SHOULD search for a DKIM RR first, if possible, followed by a
TXT RR. If the verifier is unable to search for a DKK RR or a DKK RR is
not found, the verifier MUST search for a TXT RR."
First of what is "DKIM RR" - I assume you meant "DKK RR". Second is that
above system (copied from SPF) would lead to double the necessary number
of queries. This is not SPF and you have email message with data space
available where you can actually say which RR to check (something that
I saw and took care of immediatly even in absolute MTA Signatures first
spec year ago). The simplest for DKIM syntax is to specify type of record
as part of "q" tag and instead of using "dns" to mean above search in
DKK RR and TXT RR, specify that "dns/dkk" means search dkk rr is present
and "dns/txt" means that txt record is present. You can still do default
"dns" and specify that with your search algorithm if you want, but I'd
say that having particular available RR specified should be considered
RECOMMENDED.
The potential issue here is that the signer doesn't know whether the
verifier has the capability to use DKK RRs, possibly due to a
restriction such as a firewall.
The signer would use the first method from the list that he/she can support.
Those that publish both TXT and DKK records would have something like:
q=dns/dkk,dns/txt;
Note: it might be simpler if it was "q=dns/dkk,txt", but your current
semantics don't specify how to do multiple "options". Eventhough you
call it "options" and not "option" you don't specify how these options
are separated from each other after "/" and "," is already separator
used for listing of multiple methods. This is something that MUST
be addressed and new separator for options listed.
The signer therefore still needs to publish TXT, although this
would let the recipient know that DKK exists and save a query in the event
that it doesn't.
The case of firewall not letting use new DKK type is pretty rare, just
for that case requiruing everyone to do two queries for both DKK and TXT
is not inappopriate use of dns.
Also note that rationale for "verifiers and signers MUST support dns"
is unclear to me. Either you want new algorithms supported or you do
not but specifying that they "MUST" support dns means that you can
not have anything other then "q=dns,newquerytype" where as I think
you want to allow just "q=newquerytype"
The whole issue of upgrading to new mechanisms is problematic, since the
signer and verifier can't negotiate with each other. It will probably need
to be a gradual process, with the dns querytype continuing to be supported
well into the future. In any case, a new mechanism will require a revision
of the spec and this can be relaxed when appropriate.
No, new mechanisms MUST NOT require revisison of spec (it does not happen
for S/MIME after all). All it requires is that NEW spec be published that
specifies this new mechanism and than when signer supports new meachanism
and lists it in "q" (possibly along with some old mechanism for
compatibility) and verifier knows about it, they both can use it.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net