ietf-mailsig
[Top] [All Lists]

Re: DKIM - DNS RR

2005-07-18 16:40:03

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,new
querytype" where as I think  you want to allow just "q=newquerytype"

DNS was selected because (a) we have to specify some method (b) there is precident for it in this context with SPF, DK, IIM, etc (c) it's already being used in the real world for SPF and DK widely (d) doesn't require the rolling out of some new software package. It doesn't seem logical to specify no mandatory mechanism. That being the case, and absent any other viable alternatives, q=dns wins the job.

No, new mechanisms MUST NOT require revisison of spec

Right, and I think we've achieved that with the existing language (if I'm wrong please tell me). I see nothing in the language now that would prevent me from creating a new mechanism (q=http/<URL here> or q=LDAP/<parms>) or something along those lines which, in principle at least, could get the public key via some non-DNS based means (as long as it's supported by the verifier). This could be specified separately, outside the core document. The key is to have the ability in the core document (which I think we do) and later capitalizing on it can be done separately. This is adequately provided for in the existing language. Do you agree?

--
Arvel




<Prev in Thread] Current Thread [Next in Thread>