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.
True, but HTTP wasn't used with DK and so there's no worldwide deployed
infrastructure based on HTTP which we can take advantage of in this context.
That's another and an important reason q=dns got the job. That said, I
think that an HTTP mechanism would be a natural and (from my perspective)
most welcome addition. I wouldn't want to see a second _mandated_ mechanism
required in the DKIM core spec. I think that would just be extra burden on
implementers which translated into additional barriers to deployment. And
if an additional HTTP based mechanism was defined as optional then it's
place in the core spec seems superfluous? It could be much more carefully
treated separately (outside the core specification) IMO.
The way I read the draft, it does not make it easy to introduce new
methods and Jim said as much too.
Well, not making it easy isn't the same as precluding it :) The only
negative text I see is this:
"Currently the only valid value is "dns""
I think changing the text thusly would completely clear this issue up:
"This specification declares and defines the value "dns""
That change would take away the notion that text such as "the only valid
value" intimates while not losing any of the force or intent behind the
original idea. It's clear from the semantics of the q= that multiple
methods are expected and that the spec is trying to provide a mechanism for
their future reference.
On a completely other topic: William, you did an excellent paper recently
on path and crypto authentication methods which itemized all of them in nice
detail. Toward the end you put a summary and suggestions on how path can
compliment crypto, etc. Do you still have a link to that somewhere?
--
Arvel