The TLS Working Group is in the final stages of approving RFC 7250, "Using Raw Public Keys in TLS/DTLS":
https://www.rfc-editor.org/authors/rfc7250.txt The draft modifies the TLS protocol to allow clients and servers to negotiate and exchange types of authentication material other than PKIX certificate chains, and defines a format for exchanging a raw public key. These public keys are authenticated "out of band", outside the TLS protocol, for example by prior administration (in some Internet-of-Things cases), or by the use of DANE. Paul Wouters was the main author, and the protocol and document were significantly improved by several co-authors from the TLS WG. In reviewing the draft, I noticed that it doesn't ever describe how you store such a public key in a TLSA record. And the TLSA RFC 6698 explicitly specifies that TLSA records can ONLY store PKIX certificates! The relevant sections are: RFC 6698 Sec. 1.3: This document only applies to PKIX [RFC5280] certificates, not certificates of other formats. RFC 6698 Sec. 2.1.1: The certificate usages defined in this document explicitly only apply to PKIX-formatted certificates in DER encoding [X.690]. If TLS allows other formats later, or if extensions to this RRtype are made that accept other formats for certificates, those certificates will need their own certificate usage values. I remember fighting this fight in the DANE WG, and the result was something along the lines of "We'll narrow the RFC now, and then if-and-when raw public keys are approved by the TLS WG, then we'll amend it to include them." Well, the time has come. Raw public keys are approved by the TLS WG. The trouble is that nobody has bothered to amend the TLSA RFC, so the new draft RFC tells people "just use DANE", but the DANE TLSA RFC says, "No you can't". I propose to add some text to the draft RFC 7250 that extends RFC 6698 by defining how raw public keys are stored in TLSA records. My coauthors seem to prefer that we just ignore the entire issue, issue RFC 7250, and ignore the conflict between the two. As someone who learned most of what I know about protocols (and the Internet) from reading Saint Jon Postel's clearly written RFCs, I would hate to inflict that on future readers. We should not release documents that contain deliberate incompatabilities. We think RFC 7250 is ready to go except for this remaining issue. It has been approved by the TLS WG, the IESG, the RFC Editor, and all the co-authors but me. Here's my proposed wording change for RFC 7520. Improvements welcome. Start from this version: https://www.rfc-editor.org/authors/rfc7250.txt Section 4.4. OLD (entire section): When the TLS server has specified RawPublicKey as the server_certificate_type, authentication of the TLS server to the TLS client is supported only through authentication of the received client SubjectPublicKeyInfo via an out-of-band method. NEW (entire section): When the TLS server has specified RawPublicKey as the server_certificate_type, authentication of the TLS server to the TLS client is supported only through authentication of the received client SubjectPublicKeyInfo via an out-of-band method. In order to support out-of-band authentication via DANE [RFC6698], this document extends the DANE TLSA record definition to allow such records to describe raw public keys as well as PKIX [RFC5280] certificates. This extension does not define any new field values; it merely defines how existing fields are processed when being matched to raw public keys provided by TLS servers. A raw public key is represented in a TLSA record by specifying a certificate usage of 3 (domain-provided), a selector of 1 (SubjectPublicKeyInfo), and a matching type of 0. The SubjectPublicKeyInfo that holds the public key is placed in the certificate association data. Matching types other than 0 may also be used, by placing the corresponding hash value into the certificate association data. DANE [RFC6698] section 1.3 is extended to say: This document only applies to raw public keys and to PKIX [RFC5280] certificates, not certificates of other formats. DANE section 2.1.1 is extended to say: The certificate usages 0, 1 and 2 defined in this document explicitly only apply to PKIX-formatted certificates in DER encoding [X.690]. If TLS allows other formats later, or if extensions to this RRtype are made that accept other formats for certificates, those certificates will need their own certificate usage values. In DANE section 2.1.1, in addition to the definition of certificate usage 3 with TLS servers that use PKIX certificates, certificate usage 3 may also be used with TLS servers that use raw public keys: 3 -- Certificate usage 3 is also used to specify a raw public key that MUST match the raw public key presented by the server in TLS. When the TLS server provides a raw public key, there is no PKIX certificate and no PKIX validation is done; the TLS server's raw public key MUST match the raw public key provided in the TLSA record. This certificate usage is sometimes referred to as "domain-issued" because it allows a domain administrator to directly certify a domain's public keys. I believe that this wording reflects the up-to-now tacit consensus on how the DANE WG expects TLS raw public keys to be represented and processed in TLSA records. In the absence of significant dissent or further improvements, I propose to provide the above updates to the RFC Editor and release the new RFC. John _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
