Code change:
2.1. <del> The field-values of the HTTP header field defined herein utilize the following encoded form. </del> <ins> The headers in this document encode certificates as Structured Field Byte Sequences (Section 3.3.5 of RFC8941) where the value of the binary data is a DER encoded ITU.X690.1994 X.509 certificate RFC5280. In effect, this means that the binary DER certificate is encoded using base64 (without line breaks, spaces, or other characters outside the base64 alphabet) and delimited with colons on either side. </ins> <del> A certificate is represented in text as an "EncodedCertificate", which is the base64-encoded (Section 4 of RFC4648) DER ITU.X690.1994 PKIX certificate.  The encoded value MUST NOT include any line breaks, whitespace, or other additional characters.  ABNF RFC5234 syntax for "EncodedCertificate" is shown in the figure below. </del> <ins> Note that certificates are often stored encoded in a textual format, such as the one described in Section 5.1 of RFC7468, which is already nearly compatible with a Structured Field Byte Sequence; if so, it will be sufficient to replace "---(BEGIN|END) CERTIFICATE---" with ":" and remove line breaks in order to generate an appropriate item. </ins> 2.2. In the context of a TLS terminating reverse proxy (TTRP) deployment, <del> the TTRP makes the TLS client certificate available to the backend application with the following header field. </del> <ins> the proxy makes the TLS client certificate available to the backend application with the Client-Cert HTTP header field.  This field contains the end-entity certificate used by the client in the TLS handshake. </ins> <del> The end-entity client certificate as an "EncodedCertificate" value. </del> <ins> Client-Cert is an Item Structured Header RFC8941.  Its value MUST be a Byte Sequence (Section 3.3.5 of RFC8941).  Its ABNF is: </ins> <del> The "Client-Cert" header field defined herein is only for use in HTTP requests and MUST NOT be used in HTTP responses.  It is a single HTTP header field value as defined in Section 3.2 of RFC7230, which MUST NOT have a list of values or occur multiple times in a request. </del> <ins> The value of the header is encoded as described in encoding. The "Client-Cert" header field is only for use in HTTP requests and MUST NOT be used in HTTP responses.  It is a single HTTP header field value as defined in Section 3.2 of RFC7230, which MUST NOT have a list of values or occur multiple times in a request. </ins> 2.3. <ins> In the context of a TLS terminating reverse proxy (TTRP) deployment, the proxy MAY make the certificate chain used for validation of the end-entity certificate available to the backend application with the Client-Cert-Chain HTTP header field.  This field contains certificates used by the proxy to validate the certificate used by the client in the TLS handshake.  These certificates might or might not have been provided by the client during the TLS handshake. Client-Cert-Chain is a List Structured Header RFC8941.  Each item in the list MUST be a Byte Sequence (Section 3.3.5 of RFC8941) encoded as described in encoding. The header's ABNF is: The "Client-Cert-Chain" header field is only for use in HTTP requests and MUST NOT be used in HTTP responses.  It MAY have a list of values or occur multiple times in a request.  For header compression purposes, it might be advantageous to split lists into multiple instances. The first certificate in the list SHOULD directly certify the end- entity certificate provided in the "Client-Cert" header; each following certificate SHOULD directly certify the one immediately preceding it.  Because certificate validation requires that trust anchors be distributed independently, a certificate that specifies a trust anchor MAY be omitted from the chain, provided that the server is known to possess any omitted certificates. However, for maximum compatibility, servers SHOULD be prepared to handle potentially extraneous certificates and arbitrary orderings. 2.4. </ins> This section outlines the applicable processing rules for a TLS terminating reverse proxy (TTRP) that has negotiated a mutually- authenticated TLS connection to convey the client certificate from

Related discussion:
text: based on .
This PR would address both and
also would
based on some twitter feedback URL
NAME wrote: might be needed/wanted by the backend application (to independently evaluate the cert chain, for example, although that seems like it would be terribly inefficient) and that any intermediates as well as the root should also be somehow conveyed, which is an area for further discussion should this draft progress. One potential approach suggested by a few folks is to allow some configurability in what is sent along with maybe a prefix token to indicate what's being sent - something like Client-Cert: FULL \ \ \Client-Cert: EE \ as the strawman. Or a perhaps a parameter or other construct of {{?RFC8941}} to indicate what's being sent. It's also been suggested that the end-entity certificate by itself might sometimes be too big (esp. e.g., with some post-quantum signature schemes). Hard to account for it both being too much data and not enough data at the same time. But potentially opening up configuration options to send only specific attribute(s) from the client certificate is a possibility for that. In the author's humble opinion the end-entity certificate by itself strikes a good balance for the vast majority of needs and avoids optionality. But, again, this is an area for further discussion should this draft progress.
I would propose a separate header for the chain that would use the structure List value format.
I'd also argue strongly for enabling the certificate chain (even if as a list of sha256 checksums of entities in the chain). End-entity certificates are effectively namespaced by the rest of the chain, so not including the full chain and/or not tying the end-entity cert to the chain are some of the top foot-guns I've found with people using this.
I like NAME suggestion: separating the EE certificate out is sensible. The assumption here is that the terminating proxy validates the signature from the EE cert when establishing the connection. That makes it different. That said, the origin server might need to assemble and validate the chain, so including all the data presented in TLS is likely necessary. (I don't think hashes are as generically useful; space savings can be achieved with header compression, assuming that you use VERY large tables.)
From a header compression standpoint, I suspect we should note that multiple instances of the header will compress more efficiently than a single instance with a long list, assuming there are multiple possible intermediate cert paths.