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