On Tue, Apr 16, 2013 at 04:11:43PM -0700, Paul Hoffman wrote: [ The use-case under discussion is that the client gets a DIGEST of the TA certificate or public key from TLSA, not the actual certificate or public key. The digest alone cannot direct directly be used to validate any chains, since we can't check the TA signature given just a digest of its certificate or public key. ]
> > On 16 apr 2013, at 16:52, Viktor Dukhovni <[email protected]> wrote: > > > >> Does either RFC 6698, or draft-ietf-dane-srv mandate (or it is too > >> obvious to state in either standard) that: > >> > >> - Servers with "IN TLSA 2 x [12]" associations are obligated to include > >> the full TA cert in their TLS "certificate_list". > > > > I believe that is the case. > > And your co-author strongly disagrees. > > > RFC 6698 says: "The target certificate MUST pass PKIX certification > > path validation, with any certificate matching the TLSA record > > considered to be a trust anchor for this certification path > > validation." > > Yes. > > > It is not possible to do path validation without having the > > full trust anchor certificate, > > Errr, why not? If the client has a certificate that says "the > public key of the trust anchor that signed me is keyX", and you > get keyX from TLSA, why do you need a full trust anchor certificate? You get a digest of KeyX or a certificate that contains keyX from TLSA. You don't get KeyX. The client, by hypothesis receives an incomplete chain: EE Server Certificate 0 Some Issuer 1 (of 0) Some Issuer 2 (of 1) The TA whose *digest* is in TLSA is "Some issuer 3 (of 2)" whose certificate is not sent in the server chain. How is the client supposed to verify the chain? > > thus the server needs to provide it in most cases. If it is > > not provided, and the client does not have its own copy, validation > > will fail. > > Didn't the client just get it from TLSA? What am I missing here? The client got a digest which could be compared to the TA certificate, if only that certificate were on hand. Otherwise the client is out of luck. -- Viktor. _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
