One document matched: draft-thomson-http2-client-certs-02.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.30 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc ipr="trust200902" docName="draft-thomson-http2-client-certs-02" 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="March"/>

    <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>A certificate chain is transferred as a series of <spanx style="verb">CERTIFICATE</spanx> frames 
(0xFRAME-TBD3) with the same Request-ID, each containing a single 
certificate in the chain. The end certificate of the chain can be used 
as authentication for previous or subsequent requests.</t>

<t>The <spanx style="verb">CERTIFICATE</spanx> frame defines no flags.</t>

<t>While unlikely, it is possible that an exceptionally large certificate 
might be too large to fit in a single HTTP/2 frame (see <xref target="RFC7540"></xref> 
section 4.2). Senders unable to transfer a requested certificate due to 
the recipient’s <spanx style="verb">SETTINGS_MAX_FRAME_SIZE</spanx> value SHOULD 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)|                Certificate (*)              ...
 +---------------------------------------------------------------+
 
]]></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='Certificate:'>
  An X.509v3 <xref target="RFC5280"></xref> certificate in the sender’s certificate chain.</t>
</list></t>

<t>The first or only <spanx style="verb">CERTIFICATE</spanx> frame with a given Request-ID MUST 
contain the sender’s certificate. 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.)</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>
<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.</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_PROOF”</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_PROOF”</t>
      <t>Length:  64 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 have been sent, and MUST correspond 
to the first certificate presented in the first <spanx style="verb">CERTIFICATE</spanx> frame with 
that Request-ID. Receipt of multiple <spanx style="verb">CERTIFICATE_PROOF</spanx> frames for 
the same Request-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>In order to protect the privacy of the connection against 
triple-handshake attacks, this feature of HTTP/2 MUST be used only over 
TLS 1.3 or greater, or over TLS 1.2 in combination with the Extended 
Master Secret extension defined in <xref target="RFC7627"></xref>. Because this feature is 
intended to operate with equivalent security to the TLS connection, hash and 
signature algorithms not permitted by the version of TLS in use MUST NOT 
be used. Additionally, the following algorithms MUST NOT be used, even 
if permitted by the underlying TLS version:</t>

<t><list style="symbols">
  <t>MD5</t>
  <t>SHA1</t>
  <t>SHA224</t>
  <t>DSA</t>
  <t>ECDSA with curves on prime fields that are less than 240 bits wide</t>
  <t>RSA with a prime modulus less than 2048 bits</t>
</list></t>

<t>Client implementations need to carefully consider the impact of setting 
the <spanx style="verb">AUTOMATIC_USE</spanx> flag. This flag is a performance optimization, 
permitting the client to avoid a round-trip on each request where the 
server checks for certificate authentication. However, once this flag 
has been sent, the client has zero knowledge about whether the server 
will use the referenced cert for any future request, or even for an 
existing request which has not yet completed. Clients MUST NOT set this 
flag on any certificate which is not appropriate for currently-in-flight 
requests, and MUST NOT make any future requests on the same connection 
which they do not intend to have associated with the provided 
certificate.</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"/>.  Six 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='RFC7627' target='http://www.rfc-editor.org/info/rfc7627'>
<front>
<title>Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension</title>
<author initials='K.' surname='Bhargavan' fullname='K. Bhargavan' role='editor'><organization /></author>
<author initials='A.' surname='Delignat-Lavaud' fullname='A. Delignat-Lavaud'><organization /></author>
<author initials='A.' surname='Pironti' fullname='A. Pironti'><organization /></author>
<author initials='A.' surname='Langley' fullname='A. Langley'><organization /></author>
<author initials='M.' surname='Ray' fullname='M. Ray'><organization /></author>
<date year='2015' month='September' />
<abstract><t>The Transport Layer Security (TLS) master secret is not cryptographically bound to important session parameters such as the server certificate.  Consequently, it is possible for an active attacker to set up two sessions, one with a client and another with a server, such that the master secrets on the two sessions are the same.  Thereafter, any mechanism that relies on the master secret for authentication, including session resumption, becomes vulnerable to a man-in-the-middle attack, where the attacker can simply forward messages back and forth between the client and server.  This specification defines a TLS extension that contextually binds the master secret to a log of the full handshake that computes it, thus preventing such attacks.</t></abstract>
</front>
<seriesInfo name='RFC' value='7627'/>
<seriesInfo name='DOI' value='10.17487/RFC7627'/>
</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>