Code change:
commonly occurring functionality could improve and simplify interoperability between independent implementations. <del> This document aspires to standardize an HTTP header field named "Client-Cert" that a TLS terminating reverse proxy (TTRP) adds to requests that it sends to the backend origin servers.  The field value contains the client certificate from the mutually-authenticated TLS connection between the originating client and the TTRP.  This enables the backend origin server to utilize the client certificate information in its application logic.  While there may be additional proxies or hops between the TTRP and the origin server (potentially even with mutually-authenticated TLS connections between them), the scope of the "Client-Cert" header field is intentionally limited to exposing to the origin server the certificate that was presented by the originating client in its connection to the TTRP. </del> <ins> This document aspires to standardize two HTTP header fields, "Client- Cert" and "Client-Cert-Chain", which a TLS terminating reverse proxy (TTRP) adds to requests sent to the backend origin servers.  The "Client-Cert" field value contains the end-entity client certificate from the mutually-authenticated TLS connection between the originating client and the TTRP.  Optionally, the "Client-Cert-Chain" field value contains the certificate chain used for validation of the end-entity certificate.  This enables the backend origin server to utilize the client certificate information in its application logic. While there may be additional proxies or hops between the TTRP and the origin server (potentially even with mutually-authenticated TLS connections between them), the scope of the "Client-Cert" header field is intentionally limited to exposing to the origin server the certificate that was presented by the originating client in its connection to the TTRP. </ins> 1.1.

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.