-----Original Message-----
From: Simon Josefsson [mailto:jas(_at_)extundo(_dot_)com]
Sent: Thursday, August 14, 2003 3:29 PM
To: Steve Hole
Cc: Blake Ramsdell; ietf-smime(_at_)imc(_dot_)org
Subject: Re: PKI and S/MIME
Note that distributing certificate DNS does not depend on DNSSEC.
Thus the argument that DNSSEC may or may not be deployable is not
relevant to distributing certificate via DNS.
I think that the intent is to point out that in order to get an
implementation of the CERT record, you usually get that in conjunction
with a DNSSEC implementation. This may be too sweeping a
generalization, however.
Even here there is an advantage for DNS: mail clients already
implement DNS. There is no need to open ports in firewalls etc for
LDAP or XKMS. There is no need to implement new client code in the
mail client. Instead modify the existing code to query for a CERT
record where it now queries for MX and A records. Yes, I know this
doesn't apply in all situations, such as corporate mode Outlook and
Exchange, which doesn't use Internet protocols to send and receive
mail. But we are here to find a solution for applications that uses
IETF standards, not Microsoft implementations, aren't we?
Well, I'm not sure I agree with you here. End user SMTP/POP3/IMAP mail
clients today don't implement lots of DNS operations -- they just say
"all mail goes to this SMTP server" which is a simple gethostbyname
style call. Specifically, they don't deal with MX records. It has
actually been pointed out in other forums (and I've had experience with
this myself) that Windows is particularly ornery to work with for
arbitrary DNS record types that aren't supported through native APIs (I
had to write my own DNS client code to handle MX records back in the
day, and Peter Gutmann told me he got slapped around pretty good trying
to work with SRV records).
Now, this situation might have changed, but I want to point out that the
DNS operations done by mail clients today are nowhere near the same as
would be required to handle CERT records.
Blake