On Mon, 18 Jul 2005, Arvel Hathcock wrote:
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
So what? This is an open IETF WG (or its supposed to be, probably will not
happen), its supposed to explore technology as a whole not particular
experimental use for testbed purposes.
And BTW - HTTP was used in IIM in case you forget that is supposed to be
equal part of DKIM (I do happen to agree how it was used in IIM, I think
fingerprints are in fact natural fit for dns, where as public keys and
certificates are natural for http retrieval and DK & IIM seems to have
gotten that all reversed).
and so there's no worldwide deployed infrastructure based on HTTP which
we can take advantage of in this context.
I'm sure users of PGP will disagree with above and will point out to many
more years of deployment of PGP signing and PGP key servers then about
year of limited tests done with DK.
That's another and an important reason q=dns got the job.
No its not. It was done in DK because that is the technology Yahoo claims
in its patent and it did not want to consider anything else, but instead
chose the method of marketing what they got as FUSSP (something they
learned from Meng no doubt...). Just because something is in the patent
does not at all means its the best solution in given fields, similarly it
also does not mean its the only solution and thare are no equal alternatives.
In this case both are true and in reality HTTP is better use for retrieving
public keys data then dns (and it has years of use for that with S/MIME
& X.509 ceritificates with LDAP and XKMS service, PGP and their key
servers, etc).
In reality DNS is designed for providing routing records for highier-up
protocols and IS NOT universal database good for anything and everything.
DNS is at the core of the internet, it really is not supposed to be
abused and a lot of considerations should be given into any new data to be
put into it (and amount and size of any such data, etc).
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.
But I would. Just like with many security protocols, several methods are
available and while one method is better in one case, another methid is
better in another and in fact the choice does not make it more difficult
for deployment, but in fact opens it up to wider range of use.
I think that would just be extra burden on
implementers which translated into additional barriers to deployment.
See above.
And if an additional HTTP based mechanism was defined as optional then
it's place in the core spec seems superfluous?
No, it does not. Just like it was fine in IIM and just like its fine in
other protocols.
It could be much more carefully treated separately (outside the core
specification) IMO.
There is no reason to believe that the spec is supposed to be one document,
in fact already DKIM has 3 of them, it could be one or two more if you
want things clearly separated.
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""
The above line should be part of separate document that specifies txt dns
record, its format and its use. The main document should be free from how
public key is abtained and only define core signature syntax elements.
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?
Its at http://www.metasignatures.org/path_and_cryptographic_authentication.htm
---
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net