One document matched: draft-thomson-http2-client-certs-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.28 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc ipr="trust200902" docName="draft-thomson-http2-client-certs-01" category="std">
<front>
<title abbrev="HTTP/2 Client Certs">Reactive Certificate-Based Client Authentication in HTTP/2</title>
<author initials="M." surname="Thomson" fullname="Martin Thomson">
<organization>Mozilla</organization>
<address>
<email>martin.thomson@gmail.com</email>
</address>
</author>
<author initials="M." surname="Bishop" fullname="Mike Bishop">
<organization>Microsoft</organization>
<address>
<email>michael.bishop@microsoft.com</email>
</address>
</author>
<date year="2016" month="January"/>
<area>General</area>
<workgroup>HTTP</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>Some HTTP servers provide a subset of resources that require additional
authentication to interact with. HTTP/1.1 servers rely on TLS renegotiation
that is triggered by a request to a protected resource. HTTP/2 made this
pattern impossible by forbidding the use of TLS renegotiation. While TLS 1.3
provides an alternate mechanism to obtain client certificates, this mechanism
does not map well to usage in TLS 1.2.</t>
<t>This document describes a how client authentication might be requested by a
server as a result of receiving a request to a protected resource.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>Many existing HTTP <xref target="RFC7230"></xref> servers have different authentication requirements
for the different resources they serve. Of the bountiful authentication options
available for authenticating HTTP requests, client certificates present a unique
challenge for resource-specific authentication requirements because of the
interaction with the underlying TLS <xref target="I-D.ietf-tls-tls13">RFC5246</xref> layer.</t>
<t>For servers that wish to use client certificates to authenticate users, they
might request client authentication during or immediately after the TLS handshake.
However, if not all users or resources need certificate-based authentication,
a request for a certificate has the unfortunate consequence of triggering the
client to seek a certificate. Such a request can result in a poor experience,
particularly when sent to a client that does not expect the request.</t>
<t>The TLS 1.3 CertificateRequest can be used by servers to give clients hints about
which certificate to offer. Servers that rely on certificate-based
authentication might request different certificates for different resources.
Such a server cannot use contextual information about the resource to construct
an appropriate TLS CertificateRequest message during the initial handshake.</t>
<t>Consequently, client certificates are requested at connection establishment time
only in cases where all clients are expected or required to have a single
certificate that is used for all resources. Many other uses for client
certificates are reactive, that is, certificates are requested in response to
the client making a request.</t>
<t>In Yokohama, there was extensive working group discussion regarding why certificate
authentication could not easily be done at the HTTP semantic layer. However, in
subsequent discussion, it became apparent that the HTTP <spanx style="emph">framing</spanx> layer did not
suffer from the same limitation.</t>
<t>In this document, a mechanism for doing certificate-based client authentication
via HTTP/2 frames is defined. This mechanism can be implemented at the HTTP layer
without requiring new TLS stack behavior and without breaking the existing interface
between HTTP and applications which employ client certificates.</t>
<section anchor="reactive-certificate-authentication-in-http11" title="Reactive Certificate Authentication in HTTP/1.1">
<section anchor="using-tls-12-and-previous" title="Using TLS 1.2 and previous">
<t>In HTTP/1.1, a server that relies on client authentication for a subset of users
or resources does not request a certificate when the connection is established.
Instead, it only requests a client certificate when a request is made to a
resource that requires a certificate. TLS 1.2 <xref target="RFC5246"></xref> accomodates this
by permitting the server to request a new TLS handshake, in which the server
will request the client’s certificate.</t>
<t><xref target="ex-http11"/> shows the server initiating a TLS-layer renegotiation in response
to receiving an HTTP/1.1 request to a protected resource.</t>
<figure title="HTTP/1.1 Reactive Certificate Authentication with TLS 1.2" anchor="ex-http11"><artwork><![CDATA[
Client Server
-- (HTTP) GET /protected -------------------> *1
<---------------------- (TLS) HelloRequest -- *2
-- (TLS) ClientHello ----------------------->
<------------------ (TLS) ServerHello, ... --
<---------------- (TLS) CertificateRequest -- *3
-- (TLS) ..., Certificate ------------------> *4
-- (TLS) Finished -------------------------->
<-------------------------- (TLS) Finished --
<--------------------------- (HTTP) 200 OK -- *5
]]></artwork></figure>
<t>In this example, the server receives a request for a protected resource (at *1
on <xref target="ex-http11"/>). Upon performing an authorization check, the server
determines that the request requires authentication using a client certificate
and that no such certificate has been provided.</t>
<t>The server initiates TLS renegotiation by sending a TLS HelloRequest (at *2).
The client then initiates a TLS handshake. Note that some TLS messages are
elided from the figure for the sake of brevity.</t>
<t>The critical messages for this example are the server requesting a certificate
with a TLS CertificateRequest (*3); this request might use information about
the request or resource. The client then provides a certificate and proof of
possession of the private key in Certificate and CertificateVerify messages (*4).</t>
<t>When the handshake completes, the server performs any authorization checks a
second time. With the client certificate available, it then authorizes the
request and provides a response (*5).</t>
</section>
<section anchor="using-tls-13" title="Using TLS 1.3">
<t>TLS 1.3 <xref target="I-D.ietf-tls-tls13"></xref> introduces a new client authentication mechanism
that allows for clients to authenticate after the handshake has been completed.
For the purposes of authenticating an HTTP request, this is functionally
equivalent to renegotiation. <xref target="ex-tls13"/> shows the simpler exchange this
enables.</t>
<figure title="HTTP/1.1 Reactive Certificate Authentication with TLS 1.3" anchor="ex-tls13"><artwork><![CDATA[
Client Server
-- (HTTP) GET /protected ------------------->
<---------------- (TLS) CertificateRequest --
-- (TLS) Certificate, CertificateVerify ---->
<--------------------------- (HTTP) 200 OK --
]]></artwork></figure>
<t>TLS 1.3 does not support renegotiation, instead supporting direct client
authentication. In contrast to the TLS 1.2 example, in TLS 1.3, a server can
simply request a certificate.</t>
</section>
</section>
<section anchor="reactive-client-authentication-in-http2" title="Reactive Client Authentication in HTTP/2">
<t>An important part of the HTTP/1.1 exchange is that the client is able to easily
identify the request that caused the TLS renegotiation. The client is able to
assume that the next unanswered request on the connection is responsible. The
HTTP stack in the client is then able to direct the certificate request to the
application or component that initiated that request. This ensures that the
application has the right contextual information for processing the request.</t>
<t>In HTTP/2, a client can have multiple outstanding requests. Without some sort
of correlation information, a client is unable to identify which request caused
the server to request a certificate.</t>
<t>Thus, the minimum necessary mechanism to support reactive certificate
authentication in HTTP/2 is an identifier that can be use to correlate an HTTP
request with a request for a certificate.</t>
<t>Such an identifier could be added to TLS 1.2 by means of an extension,
but many TLS 1.2 implementations do not permit application data to
continue during a renegotiation. This is problematic for a multiplexed
protocol like HTTP/2. Instead, this draft proposes bringing the TLS 1.3
CertificateRequest, Certificate, and CertificateVerify messages into
HTTP/2 frames, making client certificate authentication
TLS-version-agnostic.</t>
<t>This could be done in a naive manner by replicating the messages as
HTTP/2 frames on each stream. However, this would create needless
redundancy between streams and require frequent expensive signing
operations. Instead, this draft lifts the bulky portions of each message
into frames on stream zero and permits the on-stream frames to
incorporate them by reference as needed.</t>
<t>On each stream where certificate authentication is required, the server
sends a <spanx style="verb">CERTIFICATE_REQUIRED</spanx> frame, which the client answers with a
<spanx style="verb">USE_CERTIFICATE</spanx> frame either indicating the certificate to use, or
indicating that no certificate should be used. These frames are simple,
referencing information previously sent on stream zero to reduce
redundancy.</t>
<t><spanx style="verb">CERTIFICATE_REQUIRED</spanx> frames reference a <spanx style="verb">CERTIFICATE_REQUEST</spanx> on
stream zero, analogous to the CertificateRequest message.
<spanx style="verb">USE_CERTIFICATE</spanx> frames reference a sequence of <spanx style="verb">CERTIFICATE</spanx> and
<spanx style="verb">CERTIFICATE_PROOF</spanx> frames on stream zero, analogous to the the
Certificate and CertificateVerify messages.</t>
<t>The exchange then looks like this:</t>
<figure title="HTTP/2 Reactive Certificate Authentication" anchor="ex-http2"><artwork><![CDATA[
Client Server
-- (streams 1,3) GET /protected ------------>
<---------- (stream 0) CERTIFICATE_REQUEST --
<------ (streams 1,3) CERTIFICATE_REQUIRED --
-- (stream 0) CERTIFICATE ------------------>
-- (stream 0) CERTIFICATE_PROOF ------------>
-- (streams 1,3) USE_CERTIFICATE ----------->
<-------------------- (streams 1,3) 200 OK --
]]></artwork></figure>
<t>To avoid the extra round-trip per stream required for a challenge and
response, the <spanx style="verb">AUTOMATIC_USE</spanx> flag enables a certificate to be
automatically used by the server on subsequent requests without sending
a <spanx style="verb">CERTIFICATE_REQUIRED</spanx> exchange.</t>
<t><xref target="certs-http2"/> describes how certificates can be requested and presented
at the HTTP/2 framing layer using several new frame types which parallel
the TLS 1.3 message exchange. <xref target="errors"/> defines new error types which
can be used to notify peers when the exchange has not been successful.
Finally, <xref target="setting"/> describes how an HTTP/2 client can announce
support for this feature so that a server might use these capabilities.</t>
</section>
<section anchor="terminology" title="Terminology">
<t>RFC 2119 <xref target="RFC2119"></xref> defines the terms “MUST”, “MUST NOT”, “SHOULD” and “MAY”.</t>
</section>
</section>
<section anchor="certs-http2" title="Presenting Client Certificates at the HTTP/2 Framing Layer">
<t>An HTTP/2 request from a client that has signaled support for reactive
certificate authentication (see <xref target="setting"/>) might cause a server to request
client authentication. In HTTP/2 a server does this by sending at least one
<spanx style="verb">CERTIFICATE_REQUEST</spanx> frame (see <xref target="http-cert-request"/>) on stream zero
and sending a <spanx style="verb">CERTIFICATE_REQUIRED</spanx> frame (see
<xref target="http-cert-required"/>) on the affected stream(s).
The <spanx style="verb">CERTIFICATE_REQUEST</spanx> and <spanx style="verb">CERTIFICATE_REQUIRED</spanx> frames are correlated
by their <spanx style="verb">Request-ID</spanx> field. Subsequent <spanx style="verb">CERTIFICATE_REQUIRED</spanx> frames
with the same Request-ID MAY be sent on other streams where the
server is expecting client authentication with the same parameters.</t>
<t>A server MAY send multiple concurrent <spanx style="verb">CERTIFICATE_REQUIRED</spanx> frames on
the same stream. If a server requires that a client provide multiple
certificates before authorizing a single request, it MUST send a
<spanx style="verb">CERTIFICATE_REQUIRED</spanx> frame with a different request identifier and a
corresponding <spanx style="verb">CERTIFICATE_REQUEST</spanx> frame describing each required
certificate.</t>
<t>Clients respond to requests by sending one or more <spanx style="verb">CERTIFICATE</spanx> frames
(see <xref target="http-certificate"/>), followed by a <spanx style="verb">CERTIFICATE_PROOF</spanx> frame (see
<xref target="cert-proof"/>), on stream zero containing the <spanx style="verb">Request-ID</spanx> to which
they are responding. The <spanx style="verb">USE_CERTIFICATE</spanx> (see
<xref target="http-use-certificate"/>) frame is sent on-stream to notify the server
the stream is ready to be processed.</t>
<t>To reduce round-trips, the client MAY set the <spanx style="verb">AUTOMATIC_USE</spanx> flag on a
<spanx style="verb">CERTIFICATE_PROOF</spanx> frame, indicating that the server SHOULD
automatically apply the supplied certificate to any future streams
matching that request, rather than sending a <spanx style="verb">CERTIFICATE_REQUIRED</spanx>
frame.</t>
<section anchor="http-cert-required" title="The CERTIFICATE_REQUIRED frame">
<t>The <spanx style="verb">CERTIFICATE_REQUIRED</spanx> frame (0xFRAME-TBD2) is sent by servers to
indicate that processing of an HTTP request is blocked pending
certificate authentication. The frame includes a request identifier
which can be used to correlate the stream with a previous
<spanx style="verb">CERTIFICATE_REQUEST</spanx> frame received on stream zero. The
<spanx style="verb">CERTIFICATE_REQUEST</spanx> describes the client certificate the server
requires to process the request.</t>
<t>The <spanx style="verb">CERTIFICATE_REQUIRED</spanx> frame contains 1 octet, which is the
authentication request identifier. A client that receives a
<spanx style="verb">CERTIFICATE_REQUIRED</spanx> of any other length MUST treat this as a stream
error of type <spanx style="verb">PROTOCOL_ERROR</spanx>. Frames with identical request
identifiers refer to the same <spanx style="verb">CERTIFICATE_REQUEST</spanx>.</t>
<t>The <spanx style="verb">CERTIFICATE_REQUIRED</spanx> frame MUST NOT be sent by clients. A
<spanx style="verb">CERTIFICATE_REQUIRED</spanx> frame received by a server SHOULD be rejected
with a stream error of type PROTOCOL_ERROR.</t>
<t>The server MUST NOT send a <spanx style="verb">CERTIFICATE_REQUIRED</spanx> frame on stream zero, a
server-initiated stream or a stream that does not have an outstanding request.
In other words, a server can only send in the “open” or “half-closed (remote)”
stream states.</t>
<t>A client that receives a <spanx style="verb">CERTIFICATE_REQUIRED</spanx> frame on a stream which is not in a
valid state (“open” or “half-closed (local)” for clients) SHOULD treat this as a
connection error of type <spanx style="verb">PROTOCOL_ERROR</spanx>.</t>
</section>
<section anchor="http-use-certificate" title="The USE_CERTIFICATE Frame">
<t>The <spanx style="verb">USE_CERTIFICATE</spanx> frame (0xFRAME-TBD5) is sent by clients in
response to a <spanx style="verb">CERTIFICATE_REQUIRED</spanx> frame to indicate that the
requested certificate has been provided (or will not be).</t>
<t>A <spanx style="verb">USE_CERTIFICATE</spanx> frame with no payload expresses the client’s refusal
to use the associated certificate (if any) with this stream. If the
request was originally issued for a different stream, servers MAY create
a new <spanx style="verb">CERTIFICATE_REQUEST</spanx> and permit the client to offer a different
certificate. Alternatively, servers MAY process the request as
unauthenticated, likely returning an authentication-related error at the
HTTP level (e.g. 403).</t>
<t>Otherwise, the <spanx style="verb">USE_CERTIFICATE</spanx> frame contains the <spanx style="verb">Request-ID</spanx> of the
now-completed certificate request. This MUST be an ID previously issued
by the server, and for which a matching certificate has previously been
presented along with a supporting certificate chain in one or more
<spanx style="verb">CERTIFICATE</spanx> frames, and for which proof of possession has been
presented in a <spanx style="verb">CERTIFICATE_PROOF</spanx> frame.</t>
<t>Use of the <spanx style="verb">USE_CERTIFICATE</spanx> frame by servers is not defined by this
document. A <spanx style="verb">USE_CERTIFICATE</spanx> frame received by a client MUST be
ignored.</t>
<t>The client MUST NOT send a <spanx style="verb">USE_CERTIFICATE</spanx> frame on stream zero, a
server-initiated stream or a stream that does not have an outstanding
request. In other words, a client can only send in the “open” or
“half-closed (local)” stream states. The client MUST NOT send a
<spanx style="verb">USE_CERTIFICATE</spanx> frame except in response to a <spanx style="verb">CERTIFICATE_REQUIRED</spanx>
frame from the server.</t>
<t>A server that receives a <spanx style="verb">USE_CERTIFICATE</spanx> frame on a stream which is
not in a valid state (“open” or “half-closed (remote)” for servers), on
which it has not sent a <spanx style="verb">CERTIFICATE_REQUIRED</spanx> frame, or referencing a
certificate it has not previously received SHOULD treat this as a connection
error of type <spanx style="verb">PROTOCOL_ERROR</spanx>.</t>
</section>
<section anchor="http-cert-request" title="The CERTIFICATE_REQUEST Frame">
<t>TLS 1.3 defines the <spanx style="verb">CertificateRequest</spanx> message, which prompts the client to
provide a certificate which conforms to certain properties specified by the
server. This draft defines the <spanx style="verb">CERTIFICATE_REQUEST</spanx> frame (0xFRAME-TBD1), which
contains the same contents as a TLS 1.3 <spanx style="verb">CertificateRequest</spanx> message, but can
be sent over any TLS version.</t>
<t>The <spanx style="verb">CERTIFICATE_REQUEST</spanx> frame MUST NOT be sent by clients. A <spanx style="verb">CERTIFICATE_REQUEST</spanx>
frame received by a server SHOULD be rejected with a stream error of type
<spanx style="verb">PROTOCOL_ERROR</spanx>.</t>
<t>The <spanx style="verb">CERTIFICATE_REQUEST</spanx> frame MUST be sent on stream zero. A <spanx style="verb">CERTIFICATE_REQUEST</spanx>
frame received on any other stream MUST be rejected with a stream error of type
<spanx style="verb">PROTOCOL_ERROR</spanx>.</t>
<figure title="CERTIFICATE_REQUEST frame payload" anchor="fig-cert-request"><artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| Request-ID (8)| Algorithm-Count (16) | Algorithms ...
+---------------------------------------------------------------+
| CA-Count (16) | Certificate-Authorities(?) ...
+---------------------------------------------------------------+
| Cert-Extension-Count (16) | Cert-Extensions(?) ...
+---------------------------------------------------------------+
]]></artwork></figure>
<t>The frame contains the following fields:</t>
<t><list style="hanging">
<t hangText='Request-ID:'>
<spanx style="verb">Request-ID</spanx> is an 8-bit opaque identifier used to correlate
subsequent certificate-related frames with this request. The identifier
MUST be unique in the session.</t>
<t hangText='Algorithm-Count and Algorithms:'>
A list of the hash/signature algorithm pairs that the server is able
to verify, listed in descending order of preference. Any certificates
provided by the client MUST be signed using a hash/signature algorithm
pair found in <spanx style="verb">Algorithms</spanx>. Each algorithm pair is encoded as a
<spanx style="verb">SignatureAndHashAlgorithm</spanx> (see <xref target="I-D.ietf-tls-tls13"></xref> section 6.3.2.1),
and the number of such structures is given by the 16-bit
<spanx style="verb">Algorithm-Count</spanx> field, which MUST NOT be zero.</t>
<t hangText='CA-Count and Certificate-Authorities:'>
<spanx style="verb">Certificate-Authorities</spanx> is a series of distinguished names of
acceptable certificate authorities, represented in DER-encoded <xref target="X690"></xref> format.
These distinguished names may specify a desired distinguished name for a root
CA or for a subordinate CA; thus, this message can be used to describe known
roots as well as a desired authorization space. The number of such structures
is given by the 16-bit <spanx style="verb">CA-Count</spanx> field, which MAY be zero. If the <spanx style="verb">CA-Count</spanx>
field is zero, then the client MAY send any certificate that meets the rest
of the selection criteria in the <spanx style="verb">CERTIFICATE_REQUEST</spanx>, unless there is some
external arrangement to the contrary.</t>
<t hangText='Cert-Extension-Count and Cert-Extensions:'>
A list of certificate extension OIDs <xref target="RFC5280"></xref> with their allowed
values, represented in a series of <spanx style="verb">CertificateExtension</spanx> structures
(see <xref target="I-D.ietf-tls-tls13"></xref> section 6.3.5). The list of OIDs MUST be used
in certificate selection as described in <xref target="I-D.ietf-tls-tls13"/>. The
number of Cert-Extension structures is given by the 16-bit
<spanx style="verb">Cert-Extension-Count</spanx> field, which MAY be zero.</t>
</list></t>
<t>Some certificate extension OIDs allow multiple values (e.g. Extended Key
Usage). If the sender has included a non-empty certificate_extensions
list, the certificate MUST contain all of the specified extension OIDs
that the recipient recognizes. For each extension OID recognized by the
recipient, all of the specified values MUST be present in the
certificate (but the certificate MAY have other values as well).
However, the recipient MUST ignore and skip any unrecognized certificate
extension OIDs.</t>
<t>PKIX RFCs define a variety of certificate extension OIDs and their
corresponding value types. Depending on the type, matching certificate
extension values are not necessarily bitwise-equal. It is expected that
implementations will rely on their PKI libraries to perform certificate
selection using these certificate extension OIDs.</t>
</section>
<section anchor="http-certificate" title="The CERTIFICATE frame">
<t>The <spanx style="verb">CERTIFICATE</spanx> frame (0xFRAME-TBD3) allows the sender to provide elements of a
certificate chain which can be used as authentication for previous or subsequent
requests.</t>
<t>The <spanx style="verb">CERTIFICATE</spanx> frame defines no flags.</t>
<t>The payload of a <spanx style="verb">CERTIFICATE</spanx> frame contains elements of a certificate
chain, terminating in an end certificate. Multiple <spanx style="verb">CERTIFICATE</spanx> frames
MAY be sent with the same Request-ID, to accomodate certificate
chains which are too large to fit in a single HTTP/2 frame (see
<xref target="RFC7540"></xref> section 4.2).</t>
<t>Particularly when a certificate contains a large number of Subject
Alternative Names, it might not fit into a single <spanx style="verb">CERTIFICATE</spanx> frame
even as the only provided certificate. Senders unable to transfer a
requested certificate due to the recipient’s <spanx style="verb">SETTINGS_MAX_FRAME_SIZE</spanx>
value SHOULD increase their own <spanx style="verb">SETTINGS_MAX_FRAME_SIZE</spanx> to a size
that would accomodate their certificate, then terminate affected
streams with <spanx style="verb">CERTIFICATE_TOO_LARGE</spanx>.</t>
<t>Use of the <spanx style="verb">CERTIFICATE</spanx> frame by servers is not defined by this
document. A <spanx style="verb">CERTIFICATE</spanx> frame received by a client MUST be ignored.</t>
<t>The <spanx style="verb">CERTIFICATE</spanx> frame MUST be sent on stream zero. A <spanx style="verb">CERTIFICATE</spanx> frame received
on any other stream MUST be rejected with a stream error of type <spanx style="verb">PROTOCOL_ERROR</spanx>.</t>
<figure title="CERTIFICATE frame payload" anchor="fig-cert-frame"><artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| Request-ID (8)| Cert-Count(8) | Cert-List (*) ...
+---------------------------------------------------------------+
]]></artwork></figure>
<t>The fields defined by the <spanx style="verb">CERTIFICATE</spanx> frame are:</t>
<t><list style="hanging">
<t hangText='Request-ID:'>
The ID of the <spanx style="verb">CERTIFICATE_REQUEST</spanx> to which this frame responds.</t>
<t hangText='Cert-Count and Cert-List:'>
A sequence of Certificate objects (see <xref target="cert-cert"/>), each
representing one certificate in the sender’s certificate chain. For the
first or only <spanx style="verb">CERTIFICATE</spanx> frame with a given Request-ID and Cert-ID,
the sender’s certificate MUST be the first in the list. Each subsequent
certificate SHOULD directly certify the certificate immediately
preceding it. A certificate which specifies a trust anchor MAY be
omitted, provided that the recipient is known to already possess the
relevant certificate. (For example, because it was included in a
<spanx style="verb">CERTIFICATE_REQUEST</spanx>’s Certificate-Authorities list.) <spanx style="verb">Cert-Count</spanx>
describes the number of certificates provided.</t>
</list></t>
<t>The <spanx style="verb">Request-ID</spanx> field MUST contain the same value as the corresponding
<spanx style="verb">CERTIFICATE_REQUEST</spanx> frame, and the provided certificate chain MUST
conform to the requirements expressed in the <spanx style="verb">CERTIFICATE_REQUEST</spanx> to
the best of the client’s ability. Specifically:</t>
<t><list style="symbols">
<t>If the <spanx style="verb">CERTIFICATE_REQUEST</spanx> contained a non-empty <spanx style="verb">Certificate-Authorities</spanx>
element, one of the certificates in the chain SHOULD be signed by one of the
listed CAs.</t>
<t>If the <spanx style="verb">CERTIFICATE_REQUEST</spanx> contained a non-empty <spanx style="verb">Cert-Extensions</spanx> element,
the first certificate MUST match with regard to the extension OIDs recognized
by the client.</t>
<t>Each certificate that is not self-signed MUST be signed using a hash/signature
algorithm listed in the <spanx style="verb">Algorithms</spanx> element.</t>
</list></t>
<t>If these requirements are not satisfied, the server MAY at its discretion either
process the request without client authentication, or respond with a stream error
<xref target="RFC7540"/> on any stream where the certificate is used. <xref target="errors"/> defines
certificate-related error codes which might be applicable.</t>
<t>A client cannot provide different certificates in response to the same
<spanx style="verb">CERTIFICATE_REQUEST</spanx> for use on different streams. A client that has
already sent and proven a certificate, but does not wish to use it on
a particular stream SHOULD send an empty <spanx style="verb">USE_CERTIFICATE</spanx> frame,
refusing to use that certificate on that stream.</t>
<section anchor="cert-cert" title="The Certificate structure">
<figure title="Certificate structure" anchor="fig-cert-cert"><artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| Cert-Length (24) | Cert (*) ...
+---------------------------------------------------------------+
]]></artwork></figure>
<t>The Certificate structure is a length-prefixed X.509v3 <xref target="RFC5280"></xref>
certificate. The certificate MUST be signed with an acceptable
hash/signature algorithm pair, if the recipient’s list of acceptable
pairs is known.</t>
</section>
</section>
<section anchor="cert-proof" title="The CERTIFICATE_PROOF Frame">
<t>The <spanx style="verb">CERTIFICATE_PROOF</spanx> frame proves possession of the private key corresponding
to an end certificate previously shown in a <spanx style="verb">CERTIFICATE</spanx> frame, along with
its certificate chain in the same or other <spanx style="verb">CERTIFICATE</spanx> frames.</t>
<t>The <spanx style="verb">CERTIFICATE_PROOF</spanx> frame defines one flag:</t>
<t><list style="hanging">
<t hangText='AUTOMATIC_USE (0x01):'>
Indicates that the certificate can be used automatically on future
requests.</t>
</list></t>
<figure title="CERTIFICATE_PROOF frame payload" anchor="fig-proof-frame"><artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| Request-ID (8)| Algorithm (16) | Signature(*)...
+---------------------------------------------------------------+
]]></artwork></figure>
<t>The <spanx style="verb">CERTIFICATE_PROOF</spanx> frame (0xFRAME-TBD4) contains an <spanx style="verb">Algorithm</spanx> field (a
<spanx style="verb">SignatureAndHashAlgorithm</spanx>, from <xref target="I-D.ietf-tls-tls13"></xref> section 6.3.2.1),
describing the hash/signature algorithm pair being used. The signature
is performed as described in <xref target="I-D.ietf-tls-tls13"></xref>, with the following
values being used:</t>
<t><list style="symbols">
<t>The context string for the signature is “HTTP/2 CERTIFICATE”</t>
<t>The “specified content” is an <xref target="RFC5705"></xref> exported value, with the following parameters:
<list style="symbols">
<t>Disambiguating label string: “EXPORTER HTTP/2 CERTIFICATE”</t>
<t>Length: 1024 bytes</t>
</list></t>
</list></t>
<t>Because the exported value can be independently calculated by both sides of the
TLS connection, the value to be signed is not sent on the wire at any time.
The same signed value is used for all <spanx style="verb">CERTIFICATE_PROOF</spanx> frames in a single
HTTP/2 connection.</t>
<t>A <spanx style="verb">CERTIFICATE_PROOF</spanx> frame MUST be sent only after all <spanx style="verb">CERTIFICATE</spanx>
frames with the same Request-ID and Cert-ID have been sent, and MUST correspond
to the first certificate presented in the first <spanx style="verb">CERTIFICATE</spanx> frame with
that Request-ID and Cert-ID. Receipt of multiple <spanx style="verb">CERTIFICATE_PROOF</spanx> frames for
the same Request-ID and Cert-ID, receipt of a <spanx style="verb">CERTIFICATE_PROOF</spanx> frame
without a corresponding <spanx style="verb">CERTIFICATE</spanx> frame, or receipt of a <spanx style="verb">CERTIFICATE</spanx>
frame after a corresponding <spanx style="verb">CERTIFICATE_PROOF</spanx> MUST be treated as a session
error of type <spanx style="verb">PROTOCOL_ERROR</spanx>.</t>
<t>If the <spanx style="verb">AUTOMATIC_USE</spanx> flag is set, the server MAY omit sending
<spanx style="verb">CERTIFICATE_REQUIRED</spanx> frames on future streams associated with this
request and use the referenced certificate for authentication without
further notice to the client. This behavior is optional, and receipt of
a <spanx style="verb">CERTIFICATE_REQUIRED</spanx> frame does not imply that previously-presented
certificates were unacceptable to the server.</t>
<t>Use of the <spanx style="verb">CERTIFICATE_PROOF</spanx> frame by servers is not defined by this
document. A <spanx style="verb">CERTIFICATE_PROOF</spanx> frame received by a client MUST be ignored.</t>
</section>
</section>
<section anchor="errors" title="Indicating failures during HTTP-Layer Certificate Authentication">
<t>Because this draft permits client certificates to be exchanged at the
HTTP framing layer instead of the TLS layer, several certificate-related
errors which are defined at the TLS layer might now occur at the HTTP
framing layer. In this section, those errors are restated and added to
the HTTP/2 error code registry.</t>
<t><list style="hanging">
<t hangText='BAD_CERTIFICATE (0xERROR-TBD1):'>
A certificate was corrupt, contained signatures
that did not verify correctly, etc.</t>
<t hangText='UNSUPPORTED_CERTIFICATE (0xERROR-TBD2):'>
A certificate was of an unsupported type or did not contain required
extensions</t>
<t hangText='CERTIFICATE_REVOKED (0xERROR-TBD3):'>
A certificate was revoked by its signer</t>
<t hangText='CERTIFICATE_EXPIRED (0xERROR-TBD4):'>
A certificate has expired or is not currently valid</t>
<t hangText='BAD_SIGNATURE (0xERROR-TBD5):'>
The digital signature provided did not match</t>
<t hangText='CERTIFICATE_TOO_LARGE (0xERROR-TBD6):'>
The certificate cannot be transferred due to the recipient’s
<spanx style="verb">SETTINGS_MAX_FRAME_SIZE</spanx></t>
<t hangText='CERTIFICATE_GENERAL (0xERROR-TBD7):'>
Any other certificate-related error</t>
</list></t>
<t>As described in <xref target="RFC7540"></xref>, implementations MAY choose to treat a stream error as
a connection error at any time. Of particular note, a stream error cannot occur
on stream 0, which means that implementations cannot send non-session errors in
response to <spanx style="verb">CERTIFICATE_REQUEST</spanx> and <spanx style="verb">CERTIFICATE</spanx> frames. Implementations which do
not wish to terminate the connection MAY either send relevant errors on any stream
which references the failing certificate in question or process the requests as
unauthenticated and provide error information at the HTTP semantic layer.</t>
</section>
<section anchor="setting" title="Indicating Support for HTTP-Layer Certificate Authentication">
<t>Clients that support HTTP-layer certificate authentication indicate
this using the HTTP/2 <spanx style="verb">SETTINGS_HTTP_CERT_AUTH</spanx> (0xSETTING-TBD) setting.</t>
<t>The initial value for the <spanx style="verb">SETTINGS_HTTP_CERT_AUTH</spanx> setting is 0, indicating that
the client does not support reactive certificate authentication. A client sets the
<spanx style="verb">SETTINGS_HTTP_CERT_AUTH</spanx> setting to a value of 1 to indicate support for
HTTP-layer certificate authentication as defined in this document. Any value
other than 0 or 1 MUST be treated as a connection error (Section 5.4.1 of
<xref target="RFC7540"></xref>) of type <spanx style="verb">PROTOCOL_ERROR</spanx>.</t>
</section>
<section anchor="security" title="Security Considerations">
<t>Failure to provide a certificate on a stream after receiving
<spanx style="verb">CERTIFICATE_REQUIRED</spanx> blocks server processing, and SHOULD be subject
to standard timeouts used to guard against unresponsive peers.</t>
<t>Implementations need to be aware of the potential for confusion about
the state of a connection. The presence or absence of a validated client
certificate can change during the processing of a request, potentially
multiple times, as <spanx style="verb">USE_CERTIFICATE</spanx> frames are received. A server that
uses certificate authentication needs to be prepared to reevaluate the
authorization state of a request as the set of certificates changes.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>The HTTP/2 <spanx style="verb">SETTINGS_HTTP_CERT_AUTH</spanx> setting is registered in <xref target="iana-setting"/>.
Five frame types are registered in <xref target="iana-frame"/>. Five error codes are registered
in <xref target="iana-errors"/>.</t>
<section anchor="iana-setting" title="HTTP/2 SETTINGS_HTTP_CERT_AUTH Setting">
<t>The SETTINGS_HTTP_CERT_AUTH setting is registered in the “HTTP/2 Settings”
registry established in <xref target="RFC7540"></xref>.</t>
<t><list style="hanging">
<t hangText='Name:'>
SETTINGS_HTTP_CERT_AUTH</t>
<t hangText='Code:'>
0xSETTING-TBD</t>
<t hangText='Initial Value:'>
0</t>
<t hangText='Specification:'>
This document.</t>
</list></t>
</section>
<section anchor="iana-frame" title="New HTTP/2 Frames">
<t>Four new frame types are registered in the “HTTP/2 Frame Types”
registry established in <xref target="RFC7540"></xref>.</t>
<section anchor="certificaterequired" title="CERTIFICATE_REQUIRED">
<t><list style="hanging">
<t hangText='Frame Type:'>
CERTIFICATE_REQUIRED</t>
<t hangText='Code:'>
0xFRAME-TBD1</t>
<t hangText='Specification:'>
This document.</t>
</list></t>
</section>
<section anchor="certificaterequest" title="CERTIFICATE_REQUEST">
<t><list style="hanging">
<t hangText='Frame Type:'>
CERTIFICATE_REQUEST</t>
<t hangText='Code:'>
0xFRAME-TBD2</t>
<t hangText='Specification:'>
This document.</t>
</list></t>
</section>
<section anchor="certificate" title="CERTIFICATE">
<t><list style="hanging">
<t hangText='Frame Type:'>
CERTIFICATE</t>
<t hangText='Code:'>
0xFRAME-TBD3</t>
<t hangText='Specification:'>
This document.</t>
</list></t>
</section>
<section anchor="certificateproof" title="CERTIFICATE_PROOF">
<t><list style="hanging">
<t hangText='Frame Type:'>
CERTIFICATE_PROOF</t>
<t hangText='Code:'>
0xFRAME-TBD4</t>
<t hangText='Specification:'>
This document.</t>
</list></t>
</section>
<section anchor="usecertificate" title="USE_CERTIFICATE">
<t><list style="hanging">
<t hangText='Frame Type:'>
USE_CERTIFICATE</t>
<t hangText='Code:'>
0xFRAME-TBD5</t>
<t hangText='Specification:'>
This document.</t>
</list></t>
</section>
</section>
<section anchor="iana-errors" title="New HTTP/2 Error Codes">
<t>Five new error codes are registered in the “HTTP/2 Error Code”
registry established in <xref target="RFC7540"></xref>.</t>
<section anchor="badcertificate" title="BAD_CERTIFICATE">
<t><list style="hanging">
<t hangText='Name:'>
BAD_CERTIFICATE</t>
<t hangText='Code:'>
0xERROR-TBD1</t>
<t hangText='Specification:'>
This document.</t>
</list></t>
</section>
<section anchor="unsupportedcertificate" title="UNSUPPORTED_CERTIFICATE">
<t><list style="hanging">
<t hangText='Name:'>
UNSUPPORTED_CERTIFICATE</t>
<t hangText='Code:'>
0xERROR-TBD2</t>
<t hangText='Specification:'>
This document.</t>
</list></t>
</section>
<section anchor="certificaterevoked" title="CERTIFICATE_REVOKED">
<t><list style="hanging">
<t hangText='Name:'>
CERTIFICATE_REVOKED</t>
<t hangText='Code:'>
0xERROR-TBD3</t>
<t hangText='Specification:'>
This document.</t>
</list></t>
</section>
<section anchor="certificateexpired" title="CERTIFICATE_EXPIRED">
<t><list style="hanging">
<t hangText='Name:'>
CERTIFICATE_EXPIRED</t>
<t hangText='Code:'>
0xERROR-TBD4</t>
<t hangText='Specification:'>
This document.</t>
</list></t>
</section>
<section anchor="badsignature" title="BAD_SIGNATURE">
<t><list style="hanging">
<t hangText='Name:'>
BAD_SIGNATURE</t>
<t hangText='Code:'>
0xERROR-TBD5</t>
<t hangText='Specification:'>
This document.</t>
</list></t>
</section>
<section anchor="certificategeneral" title="CERTIFICATE_GENERAL">
<t><list style="hanging">
<t hangText='Name:'>
CERTIFICATE_GENERAL</t>
<t hangText='Code:'>
0xERROR-TBD6</t>
<t hangText='Specification:'>
This document.</t>
</list></t>
</section>
</section>
</section>
<section anchor="ack" title="Acknowledgements">
<t>Eric Rescorla pointed out several failings in an earlier revision.
Andrei Popov contributed to the TLS considerations.</t>
</section>
</middle>
<back>
<references title='Normative References'>
<reference anchor='RFC2119' target='http://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>
<reference anchor='RFC5705' target='http://www.rfc-editor.org/info/rfc5705'>
<front>
<title>Keying Material Exporters for Transport Layer Security (TLS)</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<date year='2010' month='March' />
<abstract><t>A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes. This document describes a general mechanism for allowing that. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5705'/>
<seriesInfo name='DOI' value='10.17487/RFC5705'/>
</reference>
<reference anchor='RFC5246' target='http://www.rfc-editor.org/info/rfc5246'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
<author initials='T.' surname='Dierks' fullname='T. Dierks'><organization /></author>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<date year='2008' month='August' />
<abstract><t>This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5246'/>
<seriesInfo name='DOI' value='10.17487/RFC5246'/>
</reference>
<reference anchor='RFC5280' target='http://www.rfc-editor.org/info/rfc5280'>
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
<author initials='D.' surname='Cooper' fullname='D. Cooper'><organization /></author>
<author initials='S.' surname='Santesson' fullname='S. Santesson'><organization /></author>
<author initials='S.' surname='Farrell' fullname='S. Farrell'><organization /></author>
<author initials='S.' surname='Boeyen' fullname='S. Boeyen'><organization /></author>
<author initials='R.' surname='Housley' fullname='R. Housley'><organization /></author>
<author initials='W.' surname='Polk' fullname='W. Polk'><organization /></author>
<date year='2008' month='May' />
<abstract><t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5280'/>
<seriesInfo name='DOI' value='10.17487/RFC5280'/>
</reference>
<reference anchor='RFC7230' target='http://www.rfc-editor.org/info/rfc7230'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.</t></abstract>
</front>
<seriesInfo name='RFC' value='7230'/>
<seriesInfo name='DOI' value='10.17487/RFC7230'/>
</reference>
<reference anchor='RFC7540' target='http://www.rfc-editor.org/info/rfc7540'>
<front>
<title>Hypertext Transfer Protocol Version 2 (HTTP/2)</title>
<author initials='M.' surname='Belshe' fullname='M. Belshe'><organization /></author>
<author initials='R.' surname='Peon' fullname='R. Peon'><organization /></author>
<author initials='M.' surname='Thomson' fullname='M. Thomson' role='editor'><organization /></author>
<date year='2015' month='May' />
<abstract><t>This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients.</t><t>This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.</t></abstract>
</front>
<seriesInfo name='RFC' value='7540'/>
<seriesInfo name='DOI' value='10.17487/RFC7540'/>
</reference>
<reference anchor="X690" target="http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf">
<front>
<title>Information technology - ASN.1 encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title>
<author >
<organization>ITU-T</organization>
</author>
<date year="2002"/>
</front>
<seriesInfo name="ISO" value="ISO/IEC 8825-1:2002"/>
</reference>
<reference anchor='I-D.ietf-tls-tls13'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
<organization />
</author>
<date month='December' day='28' year='2015' />
<abstract><t>This document specifies Version 1.3 of the Transport Layer Security (TLS) protocol. The TLS protocol allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-tls-tls13-11' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-tls-tls13-11.txt' />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:04:57 |