On May 3, 2013, at 8:15 AM, Leif Johansson <[email protected]> wrote: > 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. >
Using webfinger, but requiring that you get there with DANE ties you to *both* -- if that good or not is left as an exercise to the reader :-) W > >> >> 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 > > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane -- A. No Q. Is it sensible to top-post? _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
