Re: [pkix] [smime] Key lookup service via draft-bhjl-x509-srv-00

["Miller, Timothy J." <[e-mail]>]

> I wouldn't disagree, but I would also point out that there are a lot of people
> who are eager to add a per-domain key lookup to their mail service.
> There are proposals in DANE to publish PGP and S/MIME keys directly in the
> DNS which are a bad idea for various reasons, but I don't see any reason that
> a domain operator shouldn't be able to offer a key server if it wants.  Scott
> Rose at NIST and Richard Lau at ICANN have expressed interest in the DANE
> versions, so I'd like to give them an option that could work.

DANE's purpose is to allow me to clearly associate a trust anchor to a domain name, which is critical to resolve the "How do I signal which CA is authoritative?" problem in TLS/SSL, but I'm not sure that ports over to S/MIME.  In TLS the association between DNS name and a CA is virtually always 1:1 (domain name owner and the service owner are the same organization), but in S/MIME it's 1:many (the domain name owner and email users are not always the same organization; e.g., yahoo.com, gmail.com, hotmail.com, &etc.).

Providing an option sounds good on paper, but in practice not so much.  Options add complexity and ambiguity, and that leads to violated expectations, which is counter to the goal of having something that "just works" such that it can be taken up without penalty.  Simplicity serves that goal far better.

> My main concern would be to keep it crystal clear that the key server
> semantics are "foo.com asserts this is the key for [e-mail]" rather than
> "this is the key for [e-mail]".

A certificate repository is, at best, relaying *stale* information it got from somewhere else.  Only the MUA actually knows what keys are held by the user at any given moment.  So why have a middleman?  Convenience?  Convenient access to the MUA's knowledge can be had without a central repository.  Why else?  

-- T