1.2. Terminology and Applicability

1.2. Terminology and Applicability

This document uses the following terminology from Section 3 of [STRUCTURED-FIELDS] to specify syntax and parsing: List and Byte Sequence.

Phrases like "TLS client certificate authentication" or "mutually authenticated TLS" are used throughout this document to refer to the process whereby, in addition to the normal TLS server authentication with a certificate, a client presents its X.509 certificate [RFC5280] and proves possession of the corresponding private key to a server when negotiating a TLS connection or the resumption of such a connection. In contemporary versions of TLS [TLS] [TLS1.2], mutual authentication requires the client to send the Certificate and CertificateVerify messages during the handshake and the server to verify the CertificateVerify and Finished messages.

HTTP/2 restricts TLS 1.2 renegotiation (Section 9.2.1 of [HTTP/2]) and prohibits TLS 1.3 post-handshake authentication (Section 9.2.3 of [HTTP/2]). However, they are sometimes used to implement reactive client certificate authentication in HTTP/1.1 [HTTP/1.1] where the server decides whether to request a client certificate based on the HTTP request. HTTP application data sent on such a connection after receipt and verification of the client certificate is also mutually authenticated and thus suitable for the mechanisms described in this document. With post-handshake authentication, there is also the possibility, though unlikely in practice, of multiple certificates and certificate chains from the client on a connection. In this case, only the certificate and chain of the last post-handshake authentication are to be utilized for the header fields described herein.