One document matched: draft-bishop-httpbis-http2-additional-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.36 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc ipr="trust200902" docName="draft-bishop-httpbis-http2-additional-certs-02" category="std">
<front>
<title abbrev="Secondary Cert Auth in HTTP/2">Secondary Certificate Authentication in HTTP/2</title>
<author initials="M." surname="Bishop" fullname="Mike Bishop">
<organization>Microsoft</organization>
<address>
<email>michael.bishop@microsoft.com</email>
</address>
</author>
<author initials="M." surname="Thomson" fullname="Martin Thomson">
<organization>Mozilla</organization>
<address>
<email>martin.thomson@gmail.com</email>
</address>
</author>
<date year="2016"/>
<area>General</area>
<workgroup>HTTP</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>TLS provides fundamental mutual authentication services for HTTP,
supporting up to one server certificate and up to one client certificate
associated to the session to prove client and server identities as
necessary. This draft provides mechanisms for providing additional such
certificates at the HTTP layer when these constraints are not
sufficient.</t>
<t>Many HTTP servers host content from several origins. HTTP/2 <xref target="RFC7540"></xref>
permits clients to reuse an existing HTTP connection to a server
provided that the secondary origin is also in the certificate provided
during the TLS <xref target="I-D.ietf-tls-tls13"></xref> handshake.</t>
<t>In many cases, servers will wish to maintain separate certificates for
different origins but still desire the benefits of a shared HTTP
connection. Similarly, servers may require clients to present
authentication, but have different requirements based on the content the
client is attempting to access.</t>
<t>This document describes a how TLS exported authenticators
[I-D.draft-sullivan-tls-exported-authenticator]
can be used to provide proof of ownership of additional certificates to
the HTTP layer to support both scenarios.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>HTTP clients need to know that the content they receive on a connection comes from
the origin that they intended to retrieve in from.
The traditional form of server authentication in HTTP has been in the form of
X.509 certificates provided during the TLS <xref target="I-D.ietf-tls-tls13">RFC5246</xref> handshake.</t>
<t>Many existing HTTP <xref target="RFC7230"></xref> servers also have authentication requirements
for the 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 layer.</t>
<t>TLS 1.2 <xref target="RFC5246"></xref> supports one server and one client certificate on a connection.
These certificates may contain multiple identities, but only one certificate may be
provided.</t>
<section anchor="server-certificate-authentication" title="Server Certificate Authentication">
<t>Section 9.1.1 of <xref target="RFC7540"></xref> describes how connections may be used to make
requests from multiple origins as long as the server is authoritative
for both. A server is considered authoritative for an origin if DNS
resolves the origin to the IP address of the server and (for TLS) if the
certificate presented by the server contains the origin in the Subject
Alternative Names field.</t>
<t><xref target="I-D.ietf-httpbis-alt-svc"></xref> enables a step of abstraction from the DNS
resolution. If both hosts have provided an Alternative Service at
hostnames which resolve to the IP address of the server, they are
considered authoritative just as if DNS resolved the origin itself to
that address. However, the server’s one TLS certificate is still
required to contain the name of each origin in question.</t>
<t>Servers which host many origins often would prefer to have separate
certificates for some sets of origins. This may be for ease of
certificate management (the ability to separately revoke or renew them),
due to different sources of certificates (a CDN acting on behalf of
multiple origins), or other factors which might drive this
administrative decision. Clients connecting to such origins cannot
currently reuse connections, even if both client and server would prefer
to do so.</t>
<t>Because the TLS SNI extension is exchanged in the clear, clients might
also prefer to retrieve certificates inside the encrypted context. When
this information is sensitive, it might be advantageous to request a
general-purpose certificate or anonymous ciphersuite at the TLS layer,
while acquiring the “real” certificate in HTTP after the connection is
established.</t>
</section>
<section anchor="client-certificate-authentication" title="Client Certificate Authentication">
<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,
possibly requiring user interaction, network traffic, or other
time-consuming activities. During this time, the connection is stalled
in many implementations. 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>
<section anchor="http11-using-tls-12-and-previous" title="HTTP/1.1 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="http11-using-tls-13" title="HTTP/1.1 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 anchor="http2" title="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. Since streams are used for individual
requests, correlation with a stream is sufficient.</t>
<t><xref target="RFC7540"></xref> prohibits renegotiation after any application data has been sent. This
completely blocks reactive certificate authentication in HTTP/2 using TLS 1.2.
If this restriction were relaxed by an extension or update to HTTP/2,
such an identifier could be added to TLS 1.2 by means of an extension to TLS.
Unfortunately, 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.</t>
</section>
</section>
<section anchor="http-layer-certificate-authentication" title="HTTP-Layer Certificate Authentication">
<t>This draft proposes bringing a request/response mechanism that is equivalent
to the the TLS 1.3 CertificateRequest, Certificate, CertificateVerify and
Finished messages into HTTP/2 frames, enabling certificate-based authentication
of both clients and servers independent of TLS version. This mechanism can be
implemented at the HTTP layer without breaking the existing interface between
HTTP and applications above it.</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>Certificate chains, with proof-of-possession of the corresponding
private key, can be supplied into a collection of available
certificates. Likewise, descriptions of desired certificates can be
supplied into these collections. These pre-supplied elements are then
available for automatic use (in some situations) or for reference by
individual streams.</t>
<t><xref target="discovery"/> describes how the feature is employed, defining means to
detect support in peers (<xref target="setting"/>), make certificates and requests
available (<xref target="cert-available"/>), and indicate when streams are blocked
waiting on an appropriate certificate (<xref target="cert-challenge"/>).
<xref target="certs-http2"/> defines the required frame types, which parallel the TLS
1.3 message exchange. Finally, <xref target="errors"/> defines new error types which
can be used to notify peers when the exchange has not been successful.</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="discovery" title="Discovering Additional Certificates at the HTTP/2 Layer">
<t>A certificate chain with proof of possesion of the private key corresponding
to the end-entity certificate is sent as a single of <spanx style="verb">CERTIFICATE_PROOF</spanx> frame (see
<xref target="http-cert-proof"/>) on stream zero. Once the holder of a certificate
has sent the chain and proof, this certificate chain is cached by the
recipient and available for future use. If the certificate is marked as
<spanx style="verb">AUTOMATIC_USE</spanx>, the certificate may be used by the recipient to
authorize any current or future request. Otherwise, the recipient
requests the required certificate on each stream, but the
previously-supplied certificates are available for reference without
having to resend them.</t>
<t>Likewise, the details of a request are sent on stream zero and stored by
the recipient. These details will be referenced by subsequent
<spanx style="verb">CERTIFICATE_NEEDED</spanx> frames.</t>
<t>Data sent by each peer is correlated by the ID given in each frame. This
ID is unrelated to values used by the other peer, even if each uses the
same ID in certain cases.</t>
<section anchor="setting" title="Indicating support for HTTP-layer certificate authentication">
<t>Clients and servers that will accept requests for 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 peer does not support HTTP-layer certificate authentication.
If a peer does support HTTP-layer certificate authentication, the value
is 1.</t>
</section>
<section anchor="cert-available" title="Making certificates or requests available">
<t>When a peer has advertised support for HTTP-layer certificates as in
<xref target="setting"/>, either party can supply additional certificates into the
connection at any time. These certificates then become available for the
peer to consider when deciding whether a connection is suitable to
transport a particular request.</t>
<t>Available certificates which have the <spanx style="verb">AUTOMATIC_USE</spanx> flag set MAY be
used by the recipient without further notice. This means that clients or
servers which predict a certificate will be required could pre-supply
the certificate without being asked. Regardless of whether
<spanx style="verb">AUTOMATIC_USE</spanx> is set, these certificates are available for reference
by future <spanx style="verb">USE_CERTIFICATE</spanx> frames.</t>
<figure title="Proactive Server Certificate" anchor="ex-http2-server-proactive"><artwork><![CDATA[
Client Server
<-- (stream 0) CERTIFICATE_PROOF (AU flag) --
...
-- (stream N) GET /from-new-origin --------->
<----------------------- (stream N) 200 OK --
]]></artwork></figure>
<figure title="Proactive Client Certificate" anchor="ex-http2-client-proactive"><artwork><![CDATA[
Client Server
-- (stream 0) CERTIFICATE_PROOF (AU flag) -->
-- (streams 1,3) GET /protected ------------>
<-------------------- (streams 1,3) 200 OK --
]]></artwork></figure>
<t>Likewise, either party can supply a <spanx style="verb">CERTIFICATE_REQUEST</spanx> that outlines
parameters of a certificate they might request in the future. It
is important to note that this does not currently request such a
certificate, but makes the contents of the request available for
reference by a future <spanx style="verb">CERTIFICATE_NEEDED</spanx> frame.</t>
<t>Because certificates can be large and each <spanx style="verb">CERTIFICATE_PROOF</spanx> requires
a signing operation, the server MAY instead send an <spanx style="verb">ORIGIN</spanx> frame
including origins which are not in its TLS certificate. This represents
an explicit claim by the server to possess the appropriate certificate
– a claim the client MUST verify using the procedures in
<xref target="cert-challenge"/> before relying on the server’s authority for the
claimed origin.</t>
</section>
<section anchor="cert-challenge" title="Requiring certificate authentication">
<t>As defined in <xref target="RFC7540"></xref>, when a client finds that a https:// origin (or
Alternative Service <xref target="I-D.ietf-httpbis-alt-svc"></xref>) to which it needs to
make a request has the same IP address as a server to which it is
already connected, it MAY check whether the TLS certificate provided
contains the new origin as well, and if so, reuse the connection.</t>
<t>If the TLS certificate does not contain the new origin, but the server
has advertised support for HTTP-layer certificates (see <xref target="setting"/>), it
MAY send a <spanx style="verb">CERTIFICATE_NEEDED</spanx> frame on the stream it will use to
make the request. (If the request parameters have not already been made
available using a <spanx style="verb">CERTIFICATE_REQUEST</spanx> frame, the client will need to
send the <spanx style="verb">CERTIFICATE_REQUEST</spanx> in order to generate the
<spanx style="verb">CERTIFICATE_NEEDED</spanx> frame.) The stream represents a pending request
to that origin which is blocked until a valid certificate is processed.</t>
<t>The request is blocked until the server has responded with a
<spanx style="verb">USE_CERTIFICATE</spanx> frame pointing to a certificate for that origin. If
the certificate is already available, the server SHOULD immediately
respond with the appropriate <spanx style="verb">USE_CERTIFICATE</spanx> frame. (If the
certificate has not already been transmitted, the server will need to
make the certificate available as described in <xref target="cert-available"/> before
completing the exchange.)</t>
<t>If the server does not have the desired certificate or cannot produce a
signature compatible with the client’s advertised settings, it MUST
respond with an empty <spanx style="verb">USE_CERTIFICATE</spanx> frame. In this case, or if the
server has not advertised support for HTTP-layer certificates, the
client MUST NOT send any requests for resources in that origin on the
current connection.</t>
<figure title="Client-Requested Certificate" anchor="ex-http2-server-requested"><artwork><![CDATA[
Client Server
<----------------------- (stream 0) ORIGIN --
-- (stream 0) CERTIFICATE_REQUEST ---------->
...
-- (stream N) CERTIFICATE_NEEDED --------->
<------------ (stream 0) CERTIFICATE_PROOF --
<-------------- (stream N) USE_CERTIFICATE --
-- (stream N) GET /from-new-origin --------->
<----------------------- (stream N) 200 OK --
]]></artwork></figure>
<t>Likewise, on each stream where certificate authentication is required,
the server sends a <spanx style="verb">CERTIFICATE_NEEDED</spanx> frame, which the client
answers with a <spanx style="verb">USE_CERTIFICATE</spanx> frame indicating the certificate to
use. If the request parameters or the responding certificate are not
already available, they will need to be sent as described in
<xref target="cert-available"/> as part of this exchange.</t>
<figure title="Reactive Certificate Authentication" anchor="ex-http2-client-requested"><artwork><![CDATA[
Client Server
<---------- (stream 0) CERTIFICATE_REQUEST --
...
-- (stream N) GET /protected --------------->
<--------- (stream N) CERTIFICATE_NEEDED --
-- (stream 0) CERTIFICATE_PROOF ------------>
-- (stream N) USE_CERTIFICATE -------------->
<----------------------- (stream N) 200 OK --
]]></artwork></figure>
<t>A server SHOULD provide certificates for an origin before pushing
resources from it. If a client receives a <spanx style="verb">PUSH_PROMISE</spanx> referencing an
origin for which it has not yet received the server’s certificate, the
client MUST verify the server’s possession of an appropriate certificate
by sending a <spanx style="verb">CERTIFICATE_NEEDED</spanx> frame on the pushed stream to inform
the server that progress is blocked until the request is satisfied. The
client MUST NOT use the pushed resource until an appropriate certificate
has been received and validated.</t>
</section>
</section>
<section anchor="certs-http2" title="Certificates Frames for HTTP/2">
<t>The <spanx style="verb">CERTIFICATE_REQUEST</spanx> and <spanx style="verb">CERTIFICATE_NEEDED</spanx> frames are
correlated by their <spanx style="verb">Request-ID</spanx> field. Subsequent
<spanx style="verb">CERTIFICATE_NEEDED</spanx> frames with the same <spanx style="verb">Request-ID</spanx> value MAY be
sent on other streams where the sender is expecting a certificate with
the same parameters.</t>
<t>The <spanx style="verb">CERTIFICATE_PROOF</spanx>, and <spanx style="verb">USE_CERTIFICATE</spanx> frames are
correlated by their <spanx style="verb">Cert-ID</spanx> field. Subsequent <spanx style="verb">USE_CERTIFICATE</spanx> frames
with the same <spanx style="verb">Cert-ID</spanx> MAY be sent in response to other
<spanx style="verb">CERTIFICATE_NEEDED</spanx> frames and refer to the same certificate.</t>
<t><spanx style="verb">Request-ID</spanx> and <spanx style="verb">Cert-ID</spanx> are sender-local, and the use of the same
value by the other peer does not imply any correlation between their frames.</t>
<section anchor="http-cert-needed" title="The CERTIFICATE_NEEDED frame">
<t>The <spanx style="verb">CERTIFICATE_NEEDED</spanx> frame (0xFRAME-TBD2) is sent to indicate that
the HTTP request on the current stream 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
sent on stream zero. The <spanx style="verb">CERTIFICATE_REQUEST</spanx> describes the certificate
the sender requires to make progress on the stream in question.</t>
<t>The <spanx style="verb">CERTIFICATE_NEEDED</spanx> frame contains 1 octet, which is the
authentication request identifier, <spanx style="verb">Request-ID</spanx>. A peer that receives a
<spanx style="verb">CERTIFICATE_NEEDED</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>A server MAY send multiple <spanx style="verb">CERTIFICATE_NEEDED</spanx> frames on the same
stream. If a server requires that a client provide multiple certificates
before authorizing a single request, each required certificate MUST be
indicated with a separate <spanx style="verb">CERTIFICATE_NEEDED</spanx> frame, each of which
MUST have a different request identifier (referencing different
<spanx style="verb">CERTIFICATE_REQUEST</spanx> frames describing each required certificate). To
reduce the risk of client confusion, servers SHOULD NOT have multiple
outstanding <spanx style="verb">CERTIFICATE_NEEDED</spanx> frames on the same stream at any
given time.</t>
<t>Clients MUST NOT send multiple <spanx style="verb">CERTIFICATE_NEEDED</spanx> frames
on the same stream.</t>
<t>The <spanx style="verb">CERTIFICATE_NEEDED</spanx> frame MUST NOT be sent to a peer which has
not advertised support for HTTP-layer certificate authentication.</t>
<t>The <spanx style="verb">CERTIFICATE_NEEDED</spanx> frame MUST NOT be sent on stream zero, and MUST
NOT be sent on a stream in the “half-closed (local)” state <xref target="RFC7540"></xref>. A
client that receives a <spanx style="verb">CERTIFICATE_NEEDED</spanx> frame on a stream which is
not in a valid state SHOULD treat this as a stream 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 in response to a
<spanx style="verb">CERTIFICATE_NEEDED</spanx> frame to indicate which certificate is being used
to satisfy the requirement.</t>
<t>A <spanx style="verb">USE_CERTIFICATE</spanx> frame with no payload refers to the certificate
provided at the TLS layer, if any. If no certificate was provided at the
TLS layer, the stream should be processed with no authentication, likely
returning an authentication-related error at the HTTP level (e.g. 403)
for servers or routing the request to a new connection for clients.</t>
<t>Otherwise, the <spanx style="verb">USE_CERTIFICATE</spanx> frame contains the <spanx style="verb">Cert-ID</spanx> of the
certificate the sender wishes to use. This MUST be the ID of a
certificate for which proof of possession has been presented in a
<spanx style="verb">CERTIFICATE_PROOF</spanx> frame. Recipients of a <spanx style="verb">USE_CERTIFICATE</spanx> frame of
any other length MUST treat this as a stream error of type
<spanx style="verb">PROTOCOL_ERROR</spanx>. Frames with identical certificate identifiers refer to
the same certificate chain.</t>
<t>The <spanx style="verb">USE_CERTIFICATE</spanx> frame MUST NOT be sent on stream zero or a stream
on which a <spanx style="verb">CERTIFICATE_NEEDED</spanx> frame has not been received. Receipt of
a <spanx style="verb">USE_CERTIFICATE</spanx> frame in these circmustances SHOULD be treated as
a stream error of type <spanx style="verb">PROTOCOL_ERROR</spanx>. Each <spanx style="verb">USE_CERTIFICATE</spanx> frame
should reference a preceding <spanx style="verb">CERTIFICATE_PROOF</spanx> frame. Receipt of a
<spanx style="verb">USE_CERTIFICATE</spanx> frame before the necessary frames have been received
on stream zero MUST also result in a stream error of type <spanx style="verb">PROTOCOL_ERROR</spanx>.</t>
<t>The referenced certificate chain MUST conform to the requirements
expressed in the <spanx style="verb">CERTIFICATE_REQUEST</spanx> to the best of the sender’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 sender.</t>
</list></t>
<t>If these requirements are not satisfied, the recipient MAY at its
discretion either return an error at the HTTP semantic layer, 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>
</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 SHOULD NOT be sent to a peer which has
not advertised support for HTTP-layer certificate authentication.</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)| 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 for the sender.</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 recipient 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 Cert-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>Servers MUST be able to recognize the “subjectAltName” extension
(<xref target="RFC2459"></xref> section 4.2.1.7) at a minimum. Clients MUST always
specify the desired origin using this extension, though other
extensions MAY also be included.</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-cert-proof" title="The CERTIFICATE_PROOF Frame">
<t>The <spanx style="verb">CERTIFICATE_PROOF</spanx> frame provides a exported authenticator message
from the TLS layer that provides a chain of certificates, associated
extensions and proves possession of the private key corresponding
to the end-entity certificate.</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
+-------------------------------+-------------------------------+
| Cert-ID (8) | Exported Authenticator(*)...
+---------------------------------------------------------------+
]]></artwork></figure>
<t>The <spanx style="verb">CERTIFICATE_PROOF</spanx> frame (0xFRAME-TBD4) contains an
<spanx style="verb">Exported Authenticator</spanx> field which corresponds to the value returned
from the TLS connection exported authenticator API when provided with
a certificate, a valid certificate chain for the connection and
associated extensions (OCSP, SCT, etc.), and a connection-unique 8-byte
certificate_request_context value.</t>
<t>If the <spanx style="verb">AUTOMATIC_USE</spanx> flag is set, the recipient MAY omit sending
<spanx style="verb">CERTIFICATE_NEEDED</spanx> frames on future streams which would require a
similar certificate and use the referenced certificate for
authentication without further notice to the holder. This behavior is
optional, and receipt of a <spanx style="verb">CERTIFICATE_NEEDED</spanx> frame does not imply
that previously-presented certificates were unacceptable, even if
<spanx style="verb">AUTOMATIC_USE</spanx> was set. Servers MUST set the <spanx style="verb">AUTOMATIC_USE</spanx> flag when
sending a <spanx style="verb">CERTIFICATE_PROOF</spanx> frame. A server MUST NOT send certificates
for origins which it is not prepared to service on the current
connection.</t>
<t>Upon recieving a CERTIFICATE_PROOF frame, the reciever may validate
the Exported Authenticator value by using the exported authenticator API.
This return either an error indicating that the message was invalid,
or the certificate chain and extensions used to create the message.</t>
</section>
</section>
<section anchor="errors" title="Indicating failures during HTTP-Layer Certificate Authentication">
<t>Because this draft permits 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='CERTIFICATE_TOO_LARGE (0xERROR-TBD5):'>
The certificate cannot be transferred due to the recipient’s
<spanx style="verb">SETTINGS_MAX_FRAME_SIZE</spanx></t>
<t hangText='CERTIFICATE_GENERAL (0xERROR-TBD6):'>
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_PROOF</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="security" title="Security Considerations">
<t>This mechanism defines an alternate way to obtain server and client
certificates other than in the initial TLS handshake. While the signature of
exported authenticator values is expected to be equally secure, it is
important to recognize that a vulnerability in this code path is at least
equal to a vulnerability in the TLS handshake.</t>
<t>This could also increase the impact of a key compromise. Rather than
needing to subvert DNS or IP routing in order to use a compromised
certificate, a malicious server now only needs a client to connect to
<spanx style="emph">some</spanx> HTTPS site under its control. Clients SHOULD continue to validate
that destination IP addresses are valid for the origin either by direct
DNS resolution or resolution of a validated Alternative Service. (Future
work could include a mechanism for a server to offer proofs.)</t>
<t>This draft defines a mechanism which could be used to probe servers for
origins they support, but opens no new attack versus making repeat TLS
connections with different SNI values. Servers SHOULD impose similar
denial-of-service mitigations (e.g. request rate limits) to
<spanx style="verb">CERTIFICATE_REQUEST</spanx> frames as to new TLS connections.</t>
<t>While the <spanx style="verb">CERTIFICATE_REQUEST</spanx> frame permits the sender to enumerate
the acceptable Certificate Authorities for the requested certificate, it
might not be prudent (either for security or data consumption) to
include the full list of trusted Certificate Authorities in every
request. Senders, particularly clients, are advised to send an empty
<spanx style="verb">Certificate-Authorities</spanx> element unless they are expecting a
certificate to be signed by a particular CA or small set of CAs.</t>
<t>Failure to provide a certificate on a stream after receiving
<spanx style="verb">CERTIFICATE_NEEDED</spanx> blocks processing, and SHOULD be subject
to standard timeouts used to guard against unresponsive peers.</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 are not willing 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
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>
<t>Finally, validating a multitude of signatures can be computationally
expensive, while generating an invalid signature is computationally
cheap. Implementations will require checks against attacks from this
direction. Signature proofs SHOULD NOT be validated until a stream
requires the certificate to make progress. A signature which is not
valid based on the asserted public key SHOULD be treated as a session
error, to avoid further attacks from the peer, though an implementation
MAY instead disable HTTP-layer certificates for the current connection
instead.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This draft adds entries in three registries.</t>
<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>. The entries in the following table are
registered by this document.</t>
<figure anchor="fig-frame-table"><artwork><![CDATA[
+---------------------+--------------+-------------------------+
| Frame Type | Code | Specification |
+---------------------+--------------+-------------------------+
| CERTIFICATE_NEEDED | 0xFRAME-TBD1 | {{http-cert-needed}} |
| CERTIFICATE_REQUEST | 0xFRAME-TBD2 | {{http-cert-request}} |
| CERTIFICATE_PROOF | 0xFRAME-TBD3 | {{http-cert-proof}} |
| USE_CERTIFICATE | 0xFRAME-TBD4 | {{http-use-certificate}}|
+---------------------+--------------+-------------------------+
]]></artwork></figure>
</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>. The entries in the following table are
registered by this document.</t>
<figure anchor="fig-error-table"><artwork><![CDATA[
+-------------------------+--------------+-------------------------+
| Name | Code | Specification |
+-------------------------+--------------+-------------------------+
| BAD_CERTIFICATE | 0xERROR-TBD1 | {{errors}} |
| UNSUPPORTED_CERTIFICATE | 0xERROR-TBD2 | {{errors}} |
| CERTIFICATE_REVOKED | 0xERROR-TBD3 | {{errors}} |
| CERTIFICATE_EXPIRED | 0xERROR-TBD4 | {{errors}} |
| CERTIFICATE_GENERAL | 0xERROR-TBD5 | {{errors}} |
+-------------------------+--------------+-------------------------+
]]></artwork></figure>
</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='RFC2459' target='http://www.rfc-editor.org/info/rfc2459'>
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and CRL Profile</title>
<author initials='R.' surname='Housley' fullname='R. Housley'><organization /></author>
<author initials='W.' surname='Ford' fullname='W. Ford'><organization /></author>
<author initials='W.' surname='Polk' fullname='W. Polk'><organization /></author>
<author initials='D.' surname='Solo' fullname='D. Solo'><organization /></author>
<date year='1999' month='January' />
<abstract><t>This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use in the Internet. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='2459'/>
<seriesInfo name='DOI' value='10.17487/RFC2459'/>
</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='October' day='25' year='2016' />
<abstract><t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS 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-18' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-tls-tls13-18.txt' />
</reference>
</references>
<references title='Informative References'>
<reference anchor='I-D.nottingham-httpbis-origin-frame'>
<front>
<title>The ORIGIN HTTP/2 Frame</title>
<author initials='M' surname='Nottingham' fullname='Mark Nottingham'>
<organization />
</author>
<author initials='E' surname='Nygren' fullname='Erik Nygren'>
<organization />
</author>
<date month='January' day='30' year='2016' />
<abstract><t>This document specifies the ORIGIN frame for HTTP/2, to indicate what origins are available on a given connection.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-nottingham-httpbis-origin-frame-01' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-nottingham-httpbis-origin-frame-01.txt' />
</reference>
<reference anchor='I-D.ietf-httpbis-alt-svc'>
<front>
<title>HTTP Alternative Services</title>
<author initials='M' surname='Nottingham' fullname='Mark Nottingham'>
<organization />
</author>
<author initials='P' surname='McManus' fullname='Patrick McManus'>
<organization />
</author>
<author initials='J' surname='Reschke' fullname='Julian Reschke'>
<organization />
</author>
<date month='March' day='8' year='2016' />
<abstract><t>This document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-httpbis-alt-svc-14' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-httpbis-alt-svc-14.txt' />
</reference>
<reference anchor='RFC2560' target='http://www.rfc-editor.org/info/rfc2560'>
<front>
<title>X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP</title>
<author initials='M.' surname='Myers' fullname='M. Myers'><organization /></author>
<author initials='R.' surname='Ankney' fullname='R. Ankney'><organization /></author>
<author initials='A.' surname='Malpani' fullname='A. Malpani'><organization /></author>
<author initials='S.' surname='Galperin' fullname='S. Galperin'><organization /></author>
<author initials='C.' surname='Adams' fullname='C. Adams'><organization /></author>
<date year='1999' month='June' />
<abstract><t>This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='2560'/>
<seriesInfo name='DOI' value='10.17487/RFC2560'/>
</reference>
<reference anchor='RFC6962' target='http://www.rfc-editor.org/info/rfc6962'>
<front>
<title>Certificate Transparency</title>
<author initials='B.' surname='Laurie' fullname='B. Laurie'><organization /></author>
<author initials='A.' surname='Langley' fullname='A. Langley'><organization /></author>
<author initials='E.' surname='Kasper' fullname='E. Kasper'><organization /></author>
<date year='2013' month='June' />
<abstract><t>This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs.</t><t>Logs are network services that implement the protocol operations for submissions and queries that are defined in this document.</t></abstract>
</front>
<seriesInfo name='RFC' value='6962'/>
<seriesInfo name='DOI' value='10.17487/RFC6962'/>
</reference>
<reference anchor="FIPS-186-4" target="http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf">
<front>
<title>Digital Signature Standard (DSS)</title>
<author >
<organization>National Institute of Standards and Technology</organization>
</author>
<date year="2013" month="July"/>
</front>
<seriesInfo name="FIPS" value="186-4"/>
</reference>
<reference anchor='I-D.josefsson-eddsa-ed25519'>
<front>
<title>EdDSA and Ed25519</title>
<author initials='S' surname='Josefsson' fullname='Simon Josefsson'>
<organization />
</author>
<author initials='N' surname='Moller' fullname='Niels Moller'>
<organization />
</author>
<date month='May' day='12' year='2015' />
<abstract><t>The elliptic curve signature scheme EdDSA and one instance of it called Ed25519 is described. An example implementation and test vectors are provided.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-josefsson-eddsa-ed25519-03' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-josefsson-eddsa-ed25519-03.txt' />
</reference>
<reference anchor="PKCS.1.1991">
<front>
<title>RSA Encryption Standard, Version 1.1</title>
<author>
<organization>RSA Laboratories</organization>
</author>
<date month="June" year="1991" />
</front>
<seriesInfo name="PKCS" value="1" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 09:28:49 |