Viktor, Thanks for the continued considered replies. I don't mean to ignore you, it's just that I typically reply in chronological order and hadn't yet finished writing a response to your email :)
Much of this probably stems from my confusion around 0/2 in the DANE spec. 0 says the cert MUST be found in the path - it doesn't say the cert has to be the root. 2 implies that the cert has to be the root. For us, the thing we want to pin to (our intermediate CA) would be in the middle of the chain, so I had read that to imply that only 0 would be available. What I hear you saying is that it would still work with pinning to that intermediate using 2, and presumably the client should use the cert in 2 as the root of the trust chain and ignore any signatures on that root from other CAs it knows about. This wasn't entirely clear to me in the spec, but if that's how it is supposed to work, then yes, I believe that would work for our use case. -Ian On Wed, Sep 4, 2013 at 8:20 AM, Viktor Dukhovni <[email protected]>wrote: > On Wed, Sep 04, 2013 at 08:13:30AM -0700, Ian Fette (????????) wrote: > > > Ond?ej, I might be getting it wrong, but since our CA is cross-signed by > > another CA, the chain that most clients will build will be rooted in > > something else. You can see this if you go to https://mail.google.com - > > GeoTrust shows as the root, which signs Google Internet Authority G2, > which > > signs a cert for mail.google.com. If someone is using openssl and it > > follows AIA chaining or otherwise constructs a trust chain up to > GlobalSign > > and we had specified "2" with the intermediate, would that break or still > > work? (Sorry, this is probably the most confusing part of the spec) > > Usage 2 chains work just like PKIX chains with the additional > freedom that the trust-anchor need not be a root CA previously > known to the client. > > If you also read > > https://tools.ietf.org/html/draft-dukhovni-dane-ops-01 > > you'll see that since the client will typically not have the associated > CA certificate on hand, the server's certificate chain (sent in the > TLS handshake) must include the trust anchor certificate. > > If the trust-anchor in a TLSA "2 1 1" record is an intermediate > CA, the above will typically already be the case. When the "2 1 > 1" trust-anchor is actually a root CA (I encourage you to use a CA > as close as possible to the leaf server that is stable enough to > publish in your TLSA RRs) you now need to make sure that it is > sent in the TLS handshake since unlike the PKIX case, the client > won't have it on hand. > > -- > Viktor. > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane >
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
