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. The benefit of this one is that you don't actually need the cert. You could just provision a public key this way. The binding of the public key to the identity is done by virtue of the the fact that the web server represents "example.com". It's conceptually the same as if you had put a TA in DNSSEC, it just routes through the HTTPS cert. DANE: DNS Root --DNSSEC--> example.com --DANE--> example.com S/MIME TA --PKIX--> id/key binding WebFinger: DNS Root --DNSSEC--> example.com --DANE--> example.com TLS TA --WebFinger--> id / key binding > 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? > It pushes them down the stack. The TLS layer uses DANE; the application layer doesn't. You still have to be able to do DNSSEC if you want DANE for the HTTPS connection, but you don't have to. --Richard > > --Paul Hoffman
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
