On Mon, 18 Jul 2005, Arvel Hathcock wrote:
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.
All of the above applies to HTTP as well and its use for public key
retrieval is well documented and has many more years of experience
(i.e. PGP) then with dns and with PGP keyservers there is obviously
package available if you're worried about that.
As I pointed out before, DNS is particularly good for retrieval small
fixed size data associated with given host or domain. Its use for public
key data (especially one in text format with non-fixed record size) is
questionable to say it lightly. On the other hand dns seems a lot better
suited for fixed size fingerprint object data.
I believe that at least two types of signature verification methods
should be available and dns should be one of them but should not be
the only one.
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).
The way I read the draft, it does not make it easy to introduce new
methods and Jim said as much too.
What also worries me is that there seems to be taken an approach that any
methods must be such that public key is retrieved from somewhere. I do not
believe that there has been an agreement on this issue as part of MASS
list discussions or that technical arguments say that this is better then
verifying public key included in the message. If anything it seems in
some cases one is better while in others the other and this means both
options should be on the table.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net