Code change:
connection are dispatched to the origin server with the following modifications: <del> The client certificate is be placed in the "Client-Cert" header field of the dispatched request as defined in header. </del> <ins> The client certificate is placed in the "Client-Cert" header field of the dispatched request, as described in header. </ins> <del> Any occurrence of the "Client-Cert" header field in the original incoming request MUST be removed or overwritten before forwarding the request.  An incoming request that has a "Client-Cert" header field MAY be rejected with an HTTP 400 response. </del> <ins> If so configured, the validation chain of the client certificate is placed in the "Client-Cert-Chain" header field of the request, as described in chain-header. Any occurrence of the "Client-Cert" or "Client-Cert-Chain" header fields in the original incoming request MUST be removed or overwritten before forwarding the request.  An incoming request that has a "Client-Cert" or "Client-Cert-Chain" header field MAY be rejected with an HTTP 400 response. </ins> Requests made over a TLS connection where the use of client certificate authentication was not negotiated MUST be sanitized by <del> removing any and all occurrences "Client-Cert" header field prior to dispatching the request to the backend server. </del> <ins> removing any and all occurrences of the "Client-Cert" and "Client- Cert-Chain" header fields prior to dispatching the request to the backend server. </ins> Backend origin servers may then use the "Client-Cert" header field of the request to determine if the connection from the client to the

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.