On Wed, Sep 04, 2013 at 08:25:56AM -0700, Ian Fette (????????) wrote:
> Much of this probably stems from my confusion around 0/2 in the DANE spec.
Perhaps 6698 could be more clear, but this is a general issue with
standards documents, they are always too concise unless one is
steeped in the art.
> 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.
You're misreading the specification. In both cases the certificate can
be anywhere in the path. With 0, the client is required to have prior
trust in an additional root CA to anchor the path. With 2 the requirement
is dropped.
The trust-anchor in usage 2 can be an intermediate certificate or
a root certificate. As far as the DANE client is concerned of course
path construction can terminate at the usage 2 TA, and need not go any
higher. However, the actual usage 2 TA may be an intermediate from
a PKIX perspective and may be issued by some "authority", ...
> 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.
You're misreading the specification. Go ahead and pin the intermediate
with usage 2, this just works. Best practice for your case is to
publish a "2 1 1" association that is a SHA256 digest of the
intermediate CA's public key.
> 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.
Yes, that's how it is meant to work. A thorough and careful reading
of 6698 should make this clear, even if it is not obvious at first
glance.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
