What I was proposing was the following: example.com wants to issue S/MIME certs for all its account holders, to do this they:
1) Establish a PKIX CA 2) Create a self signed root cert or a request a cert chained to a public root [in which case it MUST be constrained to only issue S/MIME certs and only for the specified domain] 3) Create a DANE record to attest to the certificate signing certificate. 4) Issue S/MIME certs under the CA. This approach uses DANE for certificate attestation but does not attempt to turn DANE into a certificate discovery protocol for end user certificates. On Fri, 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. > > > > > 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]> <[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 [email protected]https://www.ietf.org/mailman/listinfo/dane > > > > _______________________________________________ > 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
