On Apr 16, 2013, at 4:27 PM, Viktor Dukhovni <[email protected]> wrote:
> 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. Sorry, I missed that. Jakob's answer threw me off track from the question. > 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. ] Correct. But that still does not mean that the TLS server needs to send it. >> 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? As Jim points out, the client might already have it pre-loaded. If the client doesn't have it pre-loaded, the TLS handshake fails. Getting the key or certificate from the TLS server would help, but it is not required for the scenario to work. --Paul Hoffman _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
