Paul Hoffman wrote: > > Viktor Dukhovni <[email protected]> wrote: >> >> 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.
In which case this will result in an interop problem. The purpose of IETF RFCs/specification is to promote interop. Any information that will generally be necessary to obtain interop, and that is lacking from an RFC/specification, is a defect in of the omission kind. rfc2026 on Proposed Standard: Implementors should treat Proposed Standards as immature specifications. It is desirable to implement them in order to gain experience and to validate, test, and clarify the specification. However, since the content of Proposed Standards may be changed if problems are found or better solutions are identified, deploying implementations of such standards into a disruption-sensitive environment is not recommended. > > 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. That is a silly argument. The client could have the server certificate pre-loaded, could use just that for verification, and save itself the headaches of PKIX and DANE validation entirely. The intention, and default operational model of DANE is (or at least should be), that it works as soon as the DNSSEC key bootstrapping has been solved, the server's zone has been DNSSEC enabled, and a TLSA record has been configured. While it is OK for a TLS client to pin a server cert or certs from the server's certificate chain in addition to DANE, or have any of those certificates pre-loaded, that is an *ADDITIONAL* TLS client option. It would be silly to assert that such extra complications would be the default DANE operational model. -Martin _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
