Shepherd writeup


Sean Turner is the DS.
Ben Kaduk is the responsible AD.

Exported Authenticators (EAs) provide a way for endpoints of a TLS connection to prove ownership over multiple identities (certificates) outside of TLS. Endpoints can export authenticators to applications for transmission and verification. Mechanically, authenticators mirror certificate proofs in the TLS handshake, i.e., triggered by an authenticator (certificate) request, an endpoint can provide an authenticator response  comprised of a certificate, signature, and enveloping MAC (Certificate, CertificateVerify, and Finished). Endpoints may encode requests and responses using standard TLS encoding rules for transmission at the application layer, e.g., within CERTIFICATE_REQUEST and CERTIFICATE HTTP/2 frames as specified in [1]. Authenticator MACs are computed using keys exported from the underlying TLS connection, which means that authenticators are only useful to endpoints party to that keying material. As an authentication mechanism, EAs provide an alternative to post-handshake client authentication in TLS 1.3 and renegotiation in TLS 1.2 (with the extended master secret extension). Moreover, unlike Token Binding, which is negotiated via an extension, there is little risk of endpoint non-interoperatbility due to non-compliant or extension-stripping middle boxes.

EAs received formal security review from Cas Cremers and Jonathan Hoyland [2] (which in turn led to followup work in [3]). EAs guarantee compound authentication, i.e., proof of multiple separate identities, bound to a single TLS connection against an attacker without access to certificate private keys or TLS secrets. 

The intended status is Standards Track, given its use for HTTP/2 Secondary Certificates [1]. The document has received ample review from the WG members, as well as discussion in the httpbis working group with respect to its use in Secondary Certificates.

Review and Consensus

Nick presented the document several times to the WG. Over 50 emails were exchanged on the draft during its lifecycle in the WG. The group waited to move to WGLC until the security review [2] was complete. The document went through three WGLCs, with the first leading to non-trivial changes in the document before completion. (Some editorial, and some content changes that came out of the security review.) There were no objections or blocking issues during the second WGLC. The 3rd WGLC addressed changes introduced as a result of a secdir review that returned the draft to the WG.

Intellectual Property

The DS confirmed with the author that any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79.

Other Considerations

EAs have been implemented by at least two independent parties. To the best of our knowledge, no browser has yet implemented the mechanism yet.