+1 to the original post and Paul's. Putting per user data in the DNS is a lousy approach, it has never been a succes because the DNS administrators are typically network admins and they are a separate class to DNS admins.
A better approach would be to use WebFinger/XKMS/LDAP/TBS to serve up an EE cert for the end user and to use DANE to establish a trust anchor under which the EE cert is issued. The amount of email that is protected by message layer security is a negligible fraction of that protected by STARTTLS. One of the main reasons for that is that the per client user model is fundamentally broken. On Fri, Apr 19, 2013 at 5:03 PM, Paul Hoffman <[email protected]> wrote: > On Apr 19, 2013, at 1:29 PM, Richard Barnes <[email protected]> wrote: > > > Just a thought: It might be simpler to do S/MIME certificate discovery > using WebFinger than using DANE. You would just have to do an HTTPS query > to a URI of the form... > > > > < > https://example.com/.well-known/webfinger?resource=mailto:[email protected]&rel=certificate > > > > > > ... then parse a JSON object to find the certificate. As opposed to > having an appropriately upgraded DNS library, being able to do DNSSEC, and > parsing the binary record format. > > That might be a good way to do certificate discovery, but not really a > good way to have a second trust anchor if one wanted to get away from the > distributed PKIX hierarchies. > > There are plenty of ways to do certificate discovery. The question is how > to be sure that the certificate you get is one you want to use. > > > This process could still benefit from DANE, via TLSA validation on the > HTTPS connection. And basically the only documentation you would need > would be to define the "certificate" relation type. > > Um, doesn't that wipe out the supposed advantages you list above? > > --Paul Hoffman > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
