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