On 05/03/2013 01:47 PM, Phillip Hallam-Baker wrote: > +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. Hey, DNS is just a protocol. I don't think anybody is suggesting running end-user data off of bind9 :-)
The critical question is one of trust management: using webfinger ties you to the "web pki" for all practical purposes. Using dane ties you to the dnssec root. Personally I'd prefer more options. > > 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] > <mailto:[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] <mailto:[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
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
