Paul Wouters wrote: > Peter Koch wrote: > >> I've read the draft but not any preceding discussion. Publishing (not >> "authenticating", please) raw keys in the DNS makes a lot of sense IMHO, >> but it's not obvious to me why the TLSA RR type is the right one. >> The document does not explain why the expansion of the usage "3" >> is backwards compatible, i.e., not confusing old clients. > > old clients that did not support bare public key could not even use > TLSA, so how can extending support break older clients?
To me this looks like you're talking past each other. The Selector Type 1 "SubjectPublicKeyInfo" is already defined (Section 7.3) and explained (Appendic A.1.2.2) in rfc6698: https://tools.ietf.org/html/rfc6698#section-7.3 https://tools.ietf.org/html/rfc6698#appendix-A.1.2.2 Existing TLSA/DANE-aware TLS clients will (silently) assume, that this selector refers to a public key that is embedded in a more-or-less regular X.509 certificate, and that this certificate will appear in the (PKIX) certification path that the TLS client came up with for certificate path verification. The newly envisoned usage scenario seems to be for use by TLS peers with bare public keys (i.e. that do not exchange any certificates at all and do not, or not necessarily manage such keys with an X.509 cert wrapper/container. In theory, this looks like TLSA/DANE aware clients might get confused, assuming that they will be able to locate a cert in the computed (or server-supplied) certificate chain, and fail DANE validation if they cannot match. In practice, a guidance for the server admin to supply cert-based TLSA records might be sufficient, whenever interop with clients that do not support bare public is desired. To be usable with bare public keys at all, both, client and server will have to support bare public keys, and the client will have to offer their use in ClientHello through a TLS extension and the server will have to agree using it. The server does not (currently) learn whether the client is DANE/TLSA-aware, but certainly knows whether the client supports and is willing to accept a bare server key in the TLS handshake. One common case where the SPKI selector may help in traditional PKIX is in CrossCA / Bridged PKI scenarios, or the backward-compatibility-hack usage scenarios used by a few public CAs these days -- where the current PKI is normally operated with a 2048-bit self-signed RootCA certificate, but that new self-signed RootCA cert might not be known to older TLS clients, and therefore many servers are sending out a crossCA certificate in the forward certification path of the Server's Certificate TLS handshake message for the new 2048-bit root that is signed by the old 1024-bit root that is known to old TLS clients. One common example is the VeriSign/Symantec CN=VeriSign Class 3 Public Primary Certification Authority - G5 which exists as a self-signed rootCA cert and as a crossCA cert signed by the 1024-bit RSA key of the old OU=Class 3 Public Primary Certification Authority And of that latter old VeriSign Root, there exist two different (three if one includes the jan-2004 expired root in the count) certs with the same public key (i.e. SubjectPublicKeyInfo) in them: serial (md2RSA sig): 70 ba e4 1d 10 d9 29 34 b6 38 ca 7b 03 cc ba bf serial (sha1RSA sig): 3c 91 31 cb 1f f6 d0 1b 0e 9a b8 d0 44 bf 12 be -Martin _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
