summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc9440.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc9440.txt')
-rw-r--r--doc/rfc/rfc9440.txt734
1 files changed, 734 insertions, 0 deletions
diff --git a/doc/rfc/rfc9440.txt b/doc/rfc/rfc9440.txt
new file mode 100644
index 0000000..554b3c6
--- /dev/null
+++ b/doc/rfc/rfc9440.txt
@@ -0,0 +1,734 @@
+
+
+
+
+Internet Engineering Task Force (IETF) B. Campbell
+Request for Comments: 9440 Ping Identity
+Category: Informational M. Bishop, Ed.
+ISSN: 2070-1721 Akamai
+ July 2023
+
+
+ Client-Cert HTTP Header Field
+
+Abstract
+
+ This document describes HTTP extension header fields that allow a TLS
+ terminating reverse proxy (TTRP) to convey the client certificate
+ information of a mutually authenticated TLS connection to the origin
+ server in a common and predictable manner.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are candidates for any level of Internet
+ Standard; see Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc9440.
+
+Copyright Notice
+
+ Copyright (c) 2023 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (https://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Revised BSD License text as described in Section 4.e of the
+ Trust Legal Provisions and are provided without warranty as described
+ in the Revised BSD License.
+
+Table of Contents
+
+ 1. Introduction
+ 1.1. Requirements Notation and Conventions
+ 1.2. Terminology and Applicability
+ 2. HTTP Header Fields and Processing Rules
+ 2.1. Encoding
+ 2.2. Client-Cert HTTP Header Field
+ 2.3. Client-Cert-Chain HTTP Header Field
+ 2.4. Processing Rules
+ 3. Deployment Considerations
+ 3.1. Header Field Compression
+ 3.2. Message Header Size
+ 3.3. TLS Session Resumption
+ 4. Security Considerations
+ 5. IANA Considerations
+ 5.1. HTTP Field Name Registrations
+ 6. References
+ 6.1. Normative References
+ 6.2. Informative References
+ Appendix A. Example
+ Appendix B. Select Design Considerations
+ B.1. Field Injection
+ B.2. The Forwarded HTTP Extension
+ B.3. The Whole Certificate and Certificate Chain
+ Acknowledgements
+ Authors' Addresses
+
+1. Introduction
+
+ A fairly common deployment pattern for HTTPS applications is to have
+ the origin HTTP application servers sit behind a reverse proxy that
+ terminates TLS connections from clients. The proxy is accessible to
+ the Internet and dispatches client requests to the appropriate origin
+ server within a private or protected network. The origin servers are
+ not directly accessible by clients and are only reachable through the
+ reverse proxy. The backend details of this type of deployment are
+ typically opaque to clients who make requests to the proxy server and
+ see responses as though they originated from the proxy server itself.
+ Although HTTPS is also usually employed between the proxy and the
+ origin server, the TLS connection that the client establishes for
+ HTTPS is only between itself and the reverse proxy server.
+
+ The deployment pattern is found in a number of varieties such as
+ n-tier architectures, content delivery networks, application load-
+ balancing services, and ingress controllers.
+
+ Although not exceedingly prevalent, TLS client certificate
+ authentication is sometimes employed, and in such cases the origin
+ server often requires information about the client certificate for
+ its application logic. Such logic might include access control
+ decisions, audit logging, and binding issued tokens or cookies to a
+ certificate, including the respective validation of such bindings.
+ The specific details needed from the certificate also vary with the
+ application requirements. In order for these types of application
+ deployments to work in practice, the reverse proxy needs to convey
+ information about the client certificate to the origin application
+ server. At the time of writing, a common way this information is
+ conveyed is by using non-standard fields to carry the certificate (in
+ some encoding) or individual parts thereof in the HTTP request that
+ is dispatched to the origin server. This solution works, but
+ interoperability between independently developed components can be
+ cumbersome or even impossible depending on the implementation choices
+ respectively made (like what field names are used or are
+ configurable, which parts of the certificate are exposed, or how the
+ certificate is encoded). A well-known predictable approach to this
+ commonly occurring functionality could improve and simplify
+ interoperability between independent implementations.
+
+ The scope of this document is to describe existing practice while
+ codifying specific details sufficient to facilitate improved and
+ lower-touch interoperability. As such, this document describes 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.
+
+1.1. Requirements Notation and Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+ capitals, as shown here.
+
+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.
+
+2. HTTP Header Fields and Processing Rules
+
+ This document designates the following headers, defined further in
+ Sections 2.2 and 2.3, respectively, to carry the client certificate
+ information of a mutually authenticated TLS connection. The headers
+ convey the information from the reverse proxy to the origin server.
+
+ Client-Cert:
+ The end-entity certificate used by the client in the TLS handshake
+ with the reverse proxy.
+
+ Client-Cert-Chain:
+ The certificate chain used for validation of the end-entity
+ certificate provided by the client in the TLS handshake with the
+ reverse proxy.
+
+2.1. Encoding
+
+ The headers in this document encode certificates as Byte Sequences
+ (Section 3.3.5 of [STRUCTURED-FIELDS]) where the value of the binary
+ data is a DER-encoded [ITU.X690] 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.
+
+ Note that certificates are often stored in an encoded textual format,
+ such as the one described in Section 5.1 of [RFC7468], which is
+ already nearly compatible with a Byte Sequence. If certificates are
+ encoded as such, it will be sufficient to replace "---(BEGIN|END)
+ CERTIFICATE---" with ":" and remove line breaks in order to generate
+ an appropriate item.
+
+2.2. Client-Cert HTTP Header Field
+
+ In the context of a TLS terminating reverse proxy deployment, 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.
+
+ Client-Cert is a Byte Sequence with the value of the header encoded
+ as described in Section 2.1.
+
+ The Client-Cert header field is only for use in HTTP requests and
+ MUST NOT be used in HTTP responses. It is a singleton header field
+ value as defined in Section 5.5 of [HTTP], which MUST NOT have a list
+ of values or occur multiple times in a request.
+
+ Figure 2 in Appendix A has an example of the Client-Cert header
+ field.
+
+2.3. Client-Cert-Chain HTTP Header Field
+
+ In the context of a TLS terminating reverse proxy deployment, the
+ proxy MAY make the certificate chain available to the backend
+ application with the Client-Cert-Chain HTTP header field.
+
+ Client-Cert-Chain is a List (Section 3.1 of [STRUCTURED-FIELDS]).
+ Each item in the List MUST be a Byte Sequence encoded as described in
+ Section 2.1. The order is the same as the ordering in TLS (as
+ described in Section 4.4.2 of [TLS]).
+
+ Client-Cert-Chain MUST NOT appear unless Client-Cert is also present,
+ and it does not itself include the end-entity certificate that is
+ already present in Client-Cert. The root certificate MAY be omitted
+ from Client-Cert-Chain, provided that the target origin server is
+ known to possess the omitted trust anchor.
+
+ 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.
+
+ Figure 3 in Appendix A has an example of the Client-Cert-Chain header
+ field.
+
+2.4. Processing Rules
+
+ This section outlines the applicable processing rules for a TTRP that
+ has negotiated a mutually authenticated TLS connection to convey the
+ client certificate from that connection to the backend origin
+ servers. This technique is to be used as a configuration or
+ deployment option, and the processing rules described herein are for
+ servers operating with that option enabled.
+
+ A TTRP negotiates the use of a mutually authenticated TLS connection
+ with the client, such as is described in [TLS] or [TLS1.2], and
+ validates the client certificate per its policy and trusted
+ certificate authorities. Each HTTP request on the underlying TLS
+ connection is dispatched to the origin server with the following
+ modifications:
+
+ 1. The client certificate is placed in the Client-Cert header field
+ of the dispatched request, as described in Section 2.2.
+
+ 2. 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 Section 2.3.
+
+ 3. 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.
+
+ Requests to the TTRP made over a TLS connection where the use of
+ client certificate authentication was not negotiated MUST be
+ sanitized by removing any and all occurrences of the Client-Cert and
+ Client-Cert-Chain header fields prior to dispatching the request to
+ the backend server.
+
+ Backend origin servers may then use the Client-Cert header field of
+ the request to determine if the connection from the client to the
+ TTRP was mutually authenticated and, if so, the certificate thereby
+ presented by the client. Access control decisions based on the
+ client certificate (or lack thereof) can be conveyed by selecting
+ response content as appropriate or with an HTTP 403 response, if the
+ certificate is deemed unacceptable for the given context. Note that
+ TLS clients that rely on error indications at the TLS layer for an
+ unacceptable certificate will not receive those signals.
+
+ When the value of the Client-Cert request header field is used to
+ select a response (e.g., the response content is access-controlled),
+ the response MUST either be uncacheable (e.g., by sending Cache-
+ Control: no-store) or be designated for selective reuse only for
+ subsequent requests with the same Client-Cert header field value by
+ sending a "Vary: Client-Cert" response header. If a TTRP encounters
+ a response with Client-Cert or Client-Cert-Chain in the Vary header
+ field (Section 12.5.5 of [HTTP]), it SHOULD prevent the user agent
+ from caching the response by transforming the value of the Vary
+ response header field to "*".
+
+ Forward proxies and other intermediaries MUST NOT add the Client-Cert
+ or Client-Cert-Chain header fields to requests or modify an existing
+ Client-Cert or Client-Cert-Chain header field. Similarly, clients
+ MUST NOT employ the Client-Cert or Client-Cert-Chain header field in
+ requests.
+
+3. Deployment Considerations
+
+3.1. Header Field Compression
+
+ If the connection between the TTRP and origin is capable of field
+ compression (e.g., HPACK [HPACK] or QPACK [QPACK]), and the TTRP
+ multiplexes more than one client's requests into that connection, the
+ size and variation of Client-Cert and Client-Cert-Chain field values
+ can reduce compression efficiency significantly. An origin could
+ mitigate the efficiency loss by increasing the size of the dynamic
+ table. If the TTRP determines that the origin dynamic table is not
+ sufficiently large, it may find it beneficial to always send the
+ field value as a literal rather than entering it into the table.
+
+3.2. Message Header Size
+
+ A server in receipt of a larger message header than it is willing to
+ handle can send an HTTP 431 (Request Header Fields Too Large) status
+ code per Section 5 of [RFC6585]. Due to the typical size of the
+ field values containing certificate data, recipients may need to be
+ configured to allow for a larger maximum header size. An
+ intermediary generating client certificate header fields on
+ connections that allow for advertising the maximum acceptable header
+ size (e.g., HTTP/2 [HTTP/2] or HTTP/3 [HTTP/3]) should account for
+ the additional size of the header of the requests it sends, versus
+ the requests it receives, by advertising a value to its clients that
+ is sufficiently smaller so as to allow for the addition of
+ certificate data.
+
+3.3. TLS Session Resumption
+
+ Some TLS implementations do not retain client certificate information
+ when resuming. Providing inconsistent values of Client-Cert and
+ Client-Cert-Chain when resuming might lead to errors, so
+ implementations that are unable to provide these values SHOULD either
+ disable resumption for connections with client certificates or
+ initially omit a Client-Cert or Client-Cert-Chain field if it might
+ not be available after resuming.
+
+4. Security Considerations
+
+ The header fields described herein enable a TTRP and backend or
+ origin server to function together as though, from the client's
+ perspective, they are a single logical server-side deployment of
+ HTTPS over a mutually authenticated TLS connection. However, use of
+ the header fields outside that intended use case may undermine the
+ protections afforded by TLS client certificate authentication.
+ Therefore, steps such as those described below need to be taken to
+ prevent unintended use, both in sending the header field and in
+ relying on its value.
+
+ Producing and consuming the Client-Cert and Client-Cert-Chain header
+ fields SHOULD be configurable options, respectively, in a TTRP and
+ backend server (or in an individual application in that server). The
+ default configuration for both should be to not use the header
+ fields, thus requiring an "opt-in" to the functionality.
+
+ In order to prevent field injection, backend servers MUST only accept
+ the Client-Cert and Client-Cert-Chain header fields from a trusted
+ TTRP (or other proxy in a trusted path from the TTRP). A TTRP MUST
+ sanitize the incoming request before forwarding it on by removing or
+ overwriting any existing instances of the fields. Otherwise,
+ arbitrary clients can control the field values as seen and used by
+ the backend server. It is important to note that neglecting to
+ prevent field injection does not "fail safe" in that the nominal
+ functionality will still work as expected even when malicious actions
+ are possible. As such, extra care is recommended in ensuring that
+ proper field sanitation is in place.
+
+ The communication between a TTRP and backend server needs to be
+ secured against eavesdropping and modification by unintended parties.
+
+ The configuration options and request sanitization are necessary
+ functionalities of the respective servers. The other requirements
+ can be met in a number of ways, which will vary based on specific
+ deployments. The communication between a TTRP and backend or origin
+ server, for example, might be authenticated in some way with the
+ insertion and consumption of the Client-Cert and Client-Cert-Chain
+ header fields occurring only on that connection. Appendix B.3 of
+ [HTTPSIG] gives one example of this with an application of HTTP
+ Message Signatures. Alternatively, the network topology might
+ dictate a private network such that the backend application is only
+ able to accept requests from the TTRP and the proxy can only make
+ requests to that server. Other deployments that meet the
+ requirements set forth herein are also possible.
+
+5. IANA Considerations
+
+5.1. HTTP Field Name Registrations
+
+ IANA has registered the following entries in the "Hypertext Transfer
+ Protocol (HTTP) Field Name Registry" defined by "HTTP Semantics"
+ [HTTP]:
+
+ +===================+===========+=====================+
+ | Field Name | Status | Reference |
+ +===================+===========+=====================+
+ | Client-Cert | permanent | RFC 9440, Section 2 |
+ +-------------------+-----------+---------------------+
+ | Client-Cert-Chain | permanent | RFC 9440, Section 2 |
+ +-------------------+-----------+---------------------+
+
+ Table 1: Hypertext Transfer Protocol (HTTP) Field
+ Name Registry
+
+6. References
+
+6.1. Normative References
+
+ [HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
+ Ed., "HTTP Semantics", STD 97, RFC 9110,
+ DOI 10.17487/RFC9110, June 2022,
+ <https://www.rfc-editor.org/info/rfc9110>.
+
+ [ITU.X690] ITU-T, "Information technology - ASN.1 encoding rules:
+ Specification of Basic Encoding Rules (BER), Canonical
+ Encoding Rules (CER) and Distinguished Encoding Rules
+ (DER)", ITU-T Recommendation X.690, February 2021,
+ <https://www.itu.int/rec/T-REC-X.690/en>.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+ Housley, R., and W. Polk, "Internet X.509 Public Key
+ Infrastructure Certificate and Certificate Revocation List
+ (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
+ <https://www.rfc-editor.org/info/rfc5280>.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+ May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+ [STRUCTURED-FIELDS]
+ Nottingham, M. and P-H. Kamp, "Structured Field Values for
+ HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021,
+ <https://www.rfc-editor.org/info/rfc8941>.
+
+6.2. Informative References
+
+ [HPACK] Peon, R. and H. Ruellan, "HPACK: Header Compression for
+ HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015,
+ <https://www.rfc-editor.org/info/rfc7541>.
+
+ [HTTP/1.1] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
+ Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
+ June 2022, <https://www.rfc-editor.org/info/rfc9112>.
+
+ [HTTP/2] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
+ DOI 10.17487/RFC9113, June 2022,
+ <https://www.rfc-editor.org/info/rfc9113>.
+
+ [HTTP/3] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
+ June 2022, <https://www.rfc-editor.org/info/rfc9114>.
+
+ [HTTPSIG] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP
+ Message Signatures", Work in Progress, Internet-Draft,
+ draft-ietf-httpbis-message-signatures-17, 2 May 2023,
+ <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
+ message-signatures-17>.
+
+ [QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK:
+ Field Compression for HTTP/3", RFC 9204,
+ DOI 10.17487/RFC9204, June 2022,
+ <https://www.rfc-editor.org/info/rfc9204>.
+
+ [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status
+ Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012,
+ <https://www.rfc-editor.org/info/rfc6585>.
+
+ [RFC7239] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension",
+ RFC 7239, DOI 10.17487/RFC7239, June 2014,
+ <https://www.rfc-editor.org/info/rfc7239>.
+
+ [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX,
+ PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468,
+ April 2015, <https://www.rfc-editor.org/info/rfc7468>.
+
+ [RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T.
+ Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication
+ and Certificate-Bound Access Tokens", RFC 8705,
+ DOI 10.17487/RFC8705, February 2020,
+ <https://www.rfc-editor.org/info/rfc8705>.
+
+ [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol
+ Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
+ <https://www.rfc-editor.org/info/rfc8446>.
+
+ [TLS1.2] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.2", RFC 5246,
+ DOI 10.17487/RFC5246, August 2008,
+ <https://www.rfc-editor.org/info/rfc5246>.
+
+Appendix A. Example
+
+ In a hypothetical example where a TLS client would present the client
+ and intermediate certificate from Figure 1 when establishing a
+ mutually authenticated TLS connection with the TTRP, the proxy would
+ send the Client-Cert field shown in Figure 2 to the backend. Note
+ that line breaks and extra spaces have been added to the field value
+ in Figures 2 and 3 for display and formatting purposes only.
+
+ -----BEGIN CERTIFICATE-----
+ MIIBqDCCAU6gAwIBAgIBBzAKBggqhkjOPQQDAjA6MRswGQYDVQQKDBJMZXQncyBB
+ dXRoZW50aWNhdGUxGzAZBgNVBAMMEkxBIEludGVybWVkaWF0ZSBDQTAeFw0yMDAx
+ MTQyMjU1MzNaFw0yMTAxMjMyMjU1MzNaMA0xCzAJBgNVBAMMAkJDMFkwEwYHKoZI
+ zj0CAQYIKoZIzj0DAQcDQgAE8YnXXfaUgmnMtOXU/IncWalRhebrXmckC8vdgJ1p
+ 5Be5F/3YC8OthxM4+k1M6aEAEFcGzkJiNy6J84y7uzo9M6NyMHAwCQYDVR0TBAIw
+ ADAfBgNVHSMEGDAWgBRm3WjLa38lbEYCuiCPct0ZaSED2DAOBgNVHQ8BAf8EBAMC
+ BsAwEwYDVR0lBAwwCgYIKwYBBQUHAwIwHQYDVR0RAQH/BBMwEYEPYmRjQGV4YW1w
+ bGUuY29tMAoGCCqGSM49BAMCA0gAMEUCIBHda/r1vaL6G3VliL4/Di6YK0Q6bMje
+ SkC3dFCOOB8TAiEAx/kHSB4urmiZ0NX5r5XarmPk0wmuydBVoU4hBVZ1yhk=
+ -----END CERTIFICATE-----
+ -----BEGIN CERTIFICATE-----
+ MIIB5jCCAYugAwIBAgIBFjAKBggqhkjOPQQDAjBWMQswCQYDVQQGEwJVUzEbMBkG
+ A1UECgwSTGV0J3MgQXV0aGVudGljYXRlMSowKAYDVQQDDCFMZXQncyBBdXRoZW50
+ aWNhdGUgUm9vdCBBdXRob3JpdHkwHhcNMjAwMTE0MjEzMjMwWhcNMzAwMTExMjEz
+ MjMwWjA6MRswGQYDVQQKDBJMZXQncyBBdXRoZW50aWNhdGUxGzAZBgNVBAMMEkxB
+ IEludGVybWVkaWF0ZSBDQTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABJf+aA54
+ RC5pyLAR5yfXVYmNpgd+CGUTDp2KOGhc0gK91zxhHesEYkdXkpS2UN8Kati+yHtW
+ CV3kkhCngGyv7RqjZjBkMB0GA1UdDgQWBBRm3WjLa38lbEYCuiCPct0ZaSED2DAf
+ BgNVHSMEGDAWgBTEA2Q6eecKu9g9yb5glbkhhVINGDASBgNVHRMBAf8ECDAGAQH/
+ AgEAMA4GA1UdDwEB/wQEAwIBhjAKBggqhkjOPQQDAgNJADBGAiEA5pLvaFwRRkxo
+ mIAtDIwg9D7gC1xzxBl4r28EzmSO1pcCIQCJUShpSXO9HDIQMUgH69fNDEMHXD3R
+ RX5gP7kuu2KGMg==
+ -----END CERTIFICATE-----
+ -----BEGIN CERTIFICATE-----
+ MIICBjCCAaygAwIBAgIJAKS0yiqKtlhoMAoGCCqGSM49BAMCMFYxCzAJBgNVBAYT
+ AlVTMRswGQYDVQQKDBJMZXQncyBBdXRoZW50aWNhdGUxKjAoBgNVBAMMIUxldCdz
+ IEF1dGhlbnRpY2F0ZSBSb290IEF1dGhvcml0eTAeFw0yMDAxMTQyMTI1NDVaFw00
+ MDAxMDkyMTI1NDVaMFYxCzAJBgNVBAYTAlVTMRswGQYDVQQKDBJMZXQncyBBdXRo
+ ZW50aWNhdGUxKjAoBgNVBAMMIUxldCdzIEF1dGhlbnRpY2F0ZSBSb290IEF1dGhv
+ cml0eTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABFoaHU+Z5bPKmGzlYXtCf+E6
+ HYj62fORaHDOrt+yyh3H/rTcs7ynFfGn+gyFsrSP3Ez88rajv+U2NfD0o0uZ4Pmj
+ YzBhMB0GA1UdDgQWBBTEA2Q6eecKu9g9yb5glbkhhVINGDAfBgNVHSMEGDAWgBTE
+ A2Q6eecKu9g9yb5glbkhhVINGDAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQE
+ AwIBhjAKBggqhkjOPQQDAgNIADBFAiEAmAeg1ycKHriqHnaD4M/UDBpQRpkmdcRF
+ YGMg1Qyrkx4CIB4ivz3wQcQkGhcsUZ1SOImd/lq1Q0FLf09rGfLQPWDc
+ -----END CERTIFICATE-----
+
+ Figure 1: Certificate Chain (with Client Certificate First)
+
+ Client-Cert: :MIIBqDCCAU6gAwIBAgIBBzAKBggqhkjOPQQDAjA6MRswGQYDVQQKDBJ
+ MZXQncyBBdXRoZW50aWNhdGUxGzAZBgNVBAMMEkxBIEludGVybWVkaWF0ZSBDQTAeFw0
+ yMDAxMTQyMjU1MzNaFw0yMTAxMjMyMjU1MzNaMA0xCzAJBgNVBAMMAkJDMFkwEwYHKoZ
+ Izj0CAQYIKoZIzj0DAQcDQgAE8YnXXfaUgmnMtOXU/IncWalRhebrXmckC8vdgJ1p5Be
+ 5F/3YC8OthxM4+k1M6aEAEFcGzkJiNy6J84y7uzo9M6NyMHAwCQYDVR0TBAIwADAfBgN
+ VHSMEGDAWgBRm3WjLa38lbEYCuiCPct0ZaSED2DAOBgNVHQ8BAf8EBAMCBsAwEwYDVR0
+ lBAwwCgYIKwYBBQUHAwIwHQYDVR0RAQH/BBMwEYEPYmRjQGV4YW1wbGUuY29tMAoGCCq
+ GSM49BAMCA0gAMEUCIBHda/r1vaL6G3VliL4/Di6YK0Q6bMjeSkC3dFCOOB8TAiEAx/k
+ HSB4urmiZ0NX5r5XarmPk0wmuydBVoU4hBVZ1yhk=:
+
+ Figure 2: Header Field in HTTP Request to Origin Server
+
+ If the proxy were configured to also include the certificate chain,
+ it would also include the Client-Cert-Chain header field. Note that
+ while the following example does illustrate the TTRP inserting the
+ root certificate, many deployments will opt to omit the trust anchor.
+
+ Client-Cert-Chain: :MIIB5jCCAYugAwIBAgIBFjAKBggqhkjOPQQDAjBWMQsw
+ CQYDVQQGEwJVUzEbMBkGA1UECgwSTGV0J3MgQXV0aGVudGljYXRlMSowKAYDVQQ
+ DDCFMZXQncyBBdXRoZW50aWNhdGUgUm9vdCBBdXRob3JpdHkwHhcNMjAwMTE0Mj
+ EzMjMwWhcNMzAwMTExMjEzMjMwWjA6MRswGQYDVQQKDBJMZXQncyBBdXRoZW50a
+ WNhdGUxGzAZBgNVBAMMEkxBIEludGVybWVkaWF0ZSBDQTBZMBMGByqGSM49AgEG
+ CCqGSM49AwEHA0IABJf+aA54RC5pyLAR5yfXVYmNpgd+CGUTDp2KOGhc0gK91zx
+ hHesEYkdXkpS2UN8Kati+yHtWCV3kkhCngGyv7RqjZjBkMB0GA1UdDgQWBBRm3W
+ jLa38lbEYCuiCPct0ZaSED2DAfBgNVHSMEGDAWgBTEA2Q6eecKu9g9yb5glbkhh
+ VINGDASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBhjAKBggqhkjO
+ PQQDAgNJADBGAiEA5pLvaFwRRkxomIAtDIwg9D7gC1xzxBl4r28EzmSO1pcCIQC
+ JUShpSXO9HDIQMUgH69fNDEMHXD3RRX5gP7kuu2KGMg==:, :MIICBjCCAaygAw
+ IBAgIJAKS0yiqKtlhoMAoGCCqGSM49BAMCMFYxCzAJBgNVBAYTAlVTMRswGQYDV
+ QQKDBJMZXQncyBBdXRoZW50aWNhdGUxKjAoBgNVBAMMIUxldCdzIEF1dGhlbnRp
+ Y2F0ZSBSb290IEF1dGhvcml0eTAeFw0yMDAxMTQyMTI1NDVaFw00MDAxMDkyMTI
+ 1NDVaMFYxCzAJBgNVBAYTAlVTMRswGQYDVQQKDBJMZXQncyBBdXRoZW50aWNhdG
+ UxKjAoBgNVBAMMIUxldCdzIEF1dGhlbnRpY2F0ZSBSb290IEF1dGhvcml0eTBZM
+ BMGByqGSM49AgEGCCqGSM49AwEHA0IABFoaHU+Z5bPKmGzlYXtCf+E6HYj62fOR
+ aHDOrt+yyh3H/rTcs7ynFfGn+gyFsrSP3Ez88rajv+U2NfD0o0uZ4PmjYzBhMB0
+ GA1UdDgQWBBTEA2Q6eecKu9g9yb5glbkhhVINGDAfBgNVHSMEGDAWgBTEA2Q6ee
+ cKu9g9yb5glbkhhVINGDAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBh
+ jAKBggqhkjOPQQDAgNIADBFAiEAmAeg1ycKHriqHnaD4M/UDBpQRpkmdcRFYGMg
+ 1Qyrkx4CIB4ivz3wQcQkGhcsUZ1SOImd/lq1Q0FLf09rGfLQPWDc:
+
+ Figure 3: Certificate Chain in HTTP Request to Origin Server
+
+Appendix B. Select Design Considerations
+
+B.1. Field Injection
+
+ This document requires that the TTRP sanitize the fields of the
+ incoming request by removing or overwriting any existing instances of
+ the Client-Cert and Client-Cert-Chain header fields before
+ dispatching that request to the backend application. Otherwise, a
+ client could inject its own values that would appear to the backend
+ to have come from the TTRP. Although numerous other methods of
+ detecting and preventing field injection are possible, such as the
+ use of a unique secret value as part of the field name or value or
+ the application of a signature, HMAC, or AEAD, there is no common
+ general mechanism. The potential problem of client field injection
+ is not at all unique to the functionality of this document;
+ therefore, it would be inappropriate for this document to define a
+ one-off solution. Since a generic common solution does not currently
+ exist, stripping and sanitizing the fields is the de facto means of
+ protecting against field injection in practice. Sanitizing the
+ fields is sufficient when properly implemented and is a normative
+ requirement of Section 4.
+
+B.2. The Forwarded HTTP Extension
+
+ The Forwarded HTTP header field defined in [RFC7239] allows proxy
+ components to disclose information lost in the proxying process. The
+ TLS client certificate information of concern to this document could
+ have been communicated with an extension parameter to the Forwarded
+ field; however, doing so would have had some disadvantages that this
+ document endeavored to avoid. The Forwarded field syntax allows for
+ information about a full chain of proxied HTTP requests, whereas the
+ Client-Cert and Client-Cert-Chain header fields of this document are
+ concerned only with conveying information about the certificate
+ presented by the originating client on the TLS connection to the TTRP
+ (which appears as the server from that client's perspective) to
+ backend applications. The multi-hop syntax of the Forwarded field is
+ expressive but also more complicated, which would make processing it
+ more cumbersome and, more importantly, would make properly sanitizing
+ its content, as required by Section 4 to prevent field injection,
+ considerably more difficult and error-prone. Thus, this document
+ opted for a flatter and more straightforward structure.
+
+B.3. The Whole Certificate and Certificate Chain
+
+ Different applications will have varying requirements about what
+ information from the client certificate is needed, such as the
+ subject and/or issuer distinguished name, subject alternative
+ name(s), serial number, subject public key info, fingerprint, etc.
+ Furthermore, some applications, such as that described in [RFC8705],
+ make use of the entire certificate. In order to accommodate the
+ latter and ensure wide applicability by not trying to cherry-pick
+ particular certificate information, this document opted to pass the
+ full, encoded certificate as the value of the Client-Cert field.
+
+ The validation of the client certificate and chain of the mutually
+ authenticated TLS connection is typically performed by the TTRP
+ during the handshake. With the responsibility of certificate
+ validation falling on the TTRP, the end-entity certificate is
+ oftentimes sufficient for the needs of the origin server. The
+ separate Client-Cert-Chain field can convey the certificate chain for
+ origin server deployments that require this additional information.
+
+Acknowledgements
+
+ The authors would like to thank the following individuals who have
+ contributed to this document in various ways, ranging from just being
+ generally supportive of bringing forth the document to providing
+ specific feedback or content:
+
+ * Evan Anderson
+
+ * Annabelle Backman
+
+ * Alan Frindell
+
+ * Rory Hewitt
+
+ * Fredrik Jeansson
+
+ * Benjamin Kaduk
+
+ * Torsten Lodderstedt
+
+ * Kathleen Moriarty
+
+ * Mark Nottingham
+
+ * Erik Nygren
+
+ * Mike Ounsworth
+
+ * Lucas Pardue
+
+ * Matt Peterson
+
+ * Eric Rescorla
+
+ * Justin Richer
+
+ * Michael Richardson
+
+ * Joe Salowey
+
+ * Rich Salz
+
+ * Mohit Sethi
+
+ * Rifaat Shekh-Yusef
+
+ * Travis Spencer
+
+ * Nick Sullivan
+
+ * Willy Tarreau
+
+ * Martin Thomson
+
+ * Peter Wu
+
+ * Hans Zandbelt
+
+Authors' Addresses
+
+ Brian Campbell
+ Ping Identity
+ Email: bcampbell@pingidentity.com
+
+
+ Mike Bishop (editor)
+ Akamai
+ Email: mbishop@evequefou.be