draft-ietf-httpbis-http2-secondary-certs-03.txt   draft-ietf-httpbis-http2-secondary-certs-04.txt 
HTTP M. Bishop HTTP M. Bishop
Internet-Draft Akamai Internet-Draft Akamai
Intended status: Standards Track N. Sullivan Intended status: Standards Track N. Sullivan
Expires: April 26, 2019 Cloudflare Expires: October 27, 2019 Cloudflare
M. Thomson M. Thomson
Mozilla Mozilla
October 23, 2018 April 25, 2019
Secondary Certificate Authentication in HTTP/2 Secondary Certificate Authentication in HTTP/2
draft-ietf-httpbis-http2-secondary-certs-03 draft-ietf-httpbis-http2-secondary-certs-04
Abstract Abstract
A use of TLS Exported Authenticators is described which enables A use of TLS Exported Authenticators is described which enables
HTTP/2 clients and servers to offer additional certificate-based HTTP/2 clients and servers to offer additional certificate-based
credentials after the connection is established. The means by which credentials after the connection is established. The means by which
these credentials are used with requests is defined. these credentials are used with requests is defined.
Note to Readers Note to Readers
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 26, 2019. This Internet-Draft will expire on October 27, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 38 skipping to change at page 2, line 38
1.3. HTTP-Layer Certificate Authentication . . . . . . . . . . 7 1.3. HTTP-Layer Certificate Authentication . . . . . . . . . . 7
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8
2. Discovering Additional Certificates at the HTTP/2 Layer . . . 8 2. Discovering Additional Certificates at the HTTP/2 Layer . . . 8
2.1. Indicating Support for HTTP-Layer Certificate 2.1. Indicating Support for HTTP-Layer Certificate
Authentication . . . . . . . . . . . . . . . . . . . . . 8 Authentication . . . . . . . . . . . . . . . . . . . . . 8
2.2. Making Certificates or Requests Available . . . . . . . . 9 2.2. Making Certificates or Requests Available . . . . . . . . 9
2.3. Requiring Certificate Authentication . . . . . . . . . . 10 2.3. Requiring Certificate Authentication . . . . . . . . . . 10
2.3.1. Requiring Additional Server Certificates . . . . . . 10 2.3.1. Requiring Additional Server Certificates . . . . . . 10
2.3.2. Requiring Additional Client Certificates . . . . . . 11 2.3.2. Requiring Additional Client Certificates . . . . . . 11
3. Certificates Frames for HTTP/2 . . . . . . . . . . . . . . . 12 3. Certificates Frames for HTTP/2 . . . . . . . . . . . . . . . 12
3.1. The CERTIFICATE_NEEDED Frame . . . . . . . . . . . . . . 12 3.1. The CERTIFICATE_NEEDED Frame . . . . . . . . . . . . . . 13
3.2. The USE_CERTIFICATE Frame . . . . . . . . . . . . . . . . 14 3.2. The USE_CERTIFICATE Frame . . . . . . . . . . . . . . . . 14
3.3. The CERTIFICATE_REQUEST Frame . . . . . . . . . . . . . . 15 3.3. The CERTIFICATE_REQUEST Frame . . . . . . . . . . . . . . 15
3.3.1. Exported Authenticator Request Characteristics . . . 16 3.3.1. Exported Authenticator Request Characteristics . . . 16
3.4. The CERTIFICATE Frame . . . . . . . . . . . . . . . . . . 16 3.4. The CERTIFICATE Frame . . . . . . . . . . . . . . . . . . 16
3.4.1. Exported Authenticator Characteristics . . . . . . . 17 3.4.1. Exported Authenticator Characteristics . . . . . . . 18
4. Indicating Failures During HTTP-Layer Certificate 4. Indicating Failures During HTTP-Layer Certificate
Authentication . . . . . . . . . . . . . . . . . . . . . . . 18 Authentication . . . . . . . . . . . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 5. Required Domain Certificate Extension . . . . . . . . . . . . 19
5.1. Impersonation . . . . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
5.2. Fingerprinting . . . . . . . . . . . . . . . . . . . . . 19 6.1. Impersonation . . . . . . . . . . . . . . . . . . . . . . 20
5.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 19 6.2. Fingerprinting . . . . . . . . . . . . . . . . . . . . . 21
5.4. Confusion About State . . . . . . . . . . . . . . . . . . 20 6.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 21
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6.4. Persistence of Service . . . . . . . . . . . . . . . . . 21
6.1. HTTP/2 SETTINGS_HTTP_CERT_AUTH Setting . . . . . . . . . 20 6.5. Confusion About State . . . . . . . . . . . . . . . . . . 22
6.2. New HTTP/2 Frames . . . . . . . . . . . . . . . . . . . . 21
6.3. New HTTP/2 Error Codes . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.1. HTTP/2 SETTINGS_HTTP_CERT_AUTH Setting . . . . . . . . . 22
7.1. Normative References . . . . . . . . . . . . . . . . . . 21 7.2. New HTTP/2 Frames . . . . . . . . . . . . . . . . . . . . 22
7.2. Informative References . . . . . . . . . . . . . . . . . 22 7.3. New HTTP/2 Error Codes . . . . . . . . . . . . . . . . . 23
7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 23 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 23 8.1. Normative References . . . . . . . . . . . . . . . . . . 23
A.1. Since draft-ietf-httpbis-http2-secondary-certs-01: . . . 23 8.2. Informative References . . . . . . . . . . . . . . . . . 24
A.2. Since draft-ietf-httpbis-http2-secondary-certs-00: . . . 23 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25
A.3. Since draft-bishop-httpbis-http2-additional-certs-05: . . 23 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23 A.1. Since draft-ietf-httpbis-http2-secondary-certs-03: . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 A.2. Since draft-ietf-httpbis-http2-secondary-certs-02: . . . 25
A.3. Since draft-ietf-httpbis-http2-secondary-certs-01: . . . 25
A.4. Since draft-ietf-httpbis-http2-secondary-certs-00: . . . 25
A.5. Since draft-bishop-httpbis-http2-additional-certs-05: . . 26
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
HTTP clients need to know that the content they receive on a HTTP clients need to know that the content they receive on a
connection comes from the origin that they intended to retrieve in connection comes from the origin that they intended to retrieve it
from. The traditional form of server authentication in HTTP has been from. The traditional form of server authentication in HTTP has been
in the form of a single X.509 certificate provided during the TLS in the form of a single X.509 certificate provided during the TLS
([RFC5246], [I-D.ietf-tls-tls13]) handshake. ([RFC5246], [RFC8446]) handshake.
Many existing HTTP [RFC7230] servers also have authentication Many existing HTTP [RFC7230] servers also have authentication
requirements for the resources they serve. Of the bountiful requirements for the resources they serve. Of the bountiful
authentication options available for authenticating HTTP requests, authentication options available for authenticating HTTP requests,
client certificates present a unique challenge for resource-specific client certificates present a unique challenge for resource-specific
authentication requirements because of the interaction with the authentication requirements because of the interaction with the
underlying TLS layer. underlying TLS layer.
TLS 1.2 [RFC5246] supports one server and one client certificate on a TLS 1.2 [RFC5246] supports one server and one client certificate on a
connection. These certificates may contain multiple identities, but connection. These certificates may contain multiple identities, but
skipping to change at page 6, line 11 skipping to change at page 6, line 14
use information about the request or resource. The client then use information about the request or resource. The client then
provides a certificate and proof of possession of the private key in provides a certificate and proof of possession of the private key in
Certificate and CertificateVerify messages (*4). Certificate and CertificateVerify messages (*4).
When the handshake completes, the server performs any authorization When the handshake completes, the server performs any authorization
checks a second time. With the client certificate available, it then checks a second time. With the client certificate available, it then
authorizes the request and provides a response (*5). authorizes the request and provides a response (*5).
1.2.2. HTTP/1.1 Using TLS 1.3 1.2.2. HTTP/1.1 Using TLS 1.3
TLS 1.3 [I-D.ietf-tls-tls13] introduces a new client authentication TLS 1.3 [RFC8446] introduces a new client authentication mechanism
mechanism that allows for clients to authenticate after the handshake that allows for clients to authenticate after the handshake has been
has been completed. For the purposes of authenticating an HTTP completed. For the purposes of authenticating an HTTP request, this
request, this is functionally equivalent to renegotiation. Figure 2 is functionally equivalent to renegotiation. Figure 2 shows the
shows the simpler exchange this enables. simpler exchange this enables.
Client Server Client Server
-- (HTTP) GET /protected -------------------> -- (HTTP) GET /protected ------------------->
<---------------- (TLS) CertificateRequest -- <---------------- (TLS) CertificateRequest --
-- (TLS) Certificate, CertificateVerify, -- (TLS) Certificate, CertificateVerify,
Finished -----------------------> Finished ----------------------->
<--------------------------- (HTTP) 200 OK -- <--------------------------- (HTTP) 200 OK --
Figure 2: HTTP/1.1 reactive certificate authentication with TLS 1.3 Figure 2: HTTP/1.1 reactive certificate authentication with TLS 1.3
skipping to change at page 7, line 34 skipping to change at page 7, line 38
as needed. as needed.
TLS Exported Authenticators are structured messages that can be TLS Exported Authenticators are structured messages that can be
exported by either party of a TLS connection and validated by the exported by either party of a TLS connection and validated by the
other party. Given an established TLS connection, a request can be other party. Given an established TLS connection, a request can be
constructed which describes the desired certificate and an constructed which describes the desired certificate and an
authenticator message can be constructed proving possession of a authenticator message can be constructed proving possession of a
certificate and a corresponding private key. Both requests and certificate and a corresponding private key. Both requests and
authenticators can be generated by either the client or the server. authenticators can be generated by either the client or the server.
Exported Authenticators use the message structures from Sections Exported Authenticators use the message structures from Sections
4.3.2 and 4.4 of [I-D.ietf-tls-tls13], but different parameters. 4.3.2 and 4.4 of [RFC8446], but different parameters.
Each Authenticator is computed using a Handshake Context and Finished Each Authenticator is computed using a Handshake Context and Finished
MAC Key derived from the TLS session. The Handshake Context is MAC Key derived from the TLS session. The Handshake Context is
identical for both parties of the TLS connection, while the Finished identical for both parties of the TLS connection, while the Finished
MAC Key is dependent on whether the Authenticator is created by the MAC Key is dependent on whether the Authenticator is created by the
client or the server. client or the server.
Successfully verified Authenticators result in certificate chains, Successfully verified Authenticators result in certificate chains,
with verified possession of the corresponding private key, which can with verified possession of the corresponding private key, which can
be supplied into a collection of available certificates. Likewise, be supplied into a collection of available certificates. Likewise,
skipping to change at page 9, line 8 skipping to change at page 9, line 13
"SETTINGS_HTTP_CERT_AUTH" (0xSETTING-TBD) setting. "SETTINGS_HTTP_CERT_AUTH" (0xSETTING-TBD) setting.
The initial value for the "SETTINGS_HTTP_CERT_AUTH" setting is 0, The initial value for the "SETTINGS_HTTP_CERT_AUTH" setting is 0,
indicating that the peer does not support HTTP-layer certificate indicating that the peer does not support HTTP-layer certificate
authentication. If a peer does support HTTP-layer certificate authentication. If a peer does support HTTP-layer certificate
authentication, the value is non-zero. authentication, the value is non-zero.
In order to ensure that the TLS connection is direct to the server, In order to ensure that the TLS connection is direct to the server,
rather than via a TLS-terminating proxy, each side will separately rather than via a TLS-terminating proxy, each side will separately
compute and confirm the value of this setting. The setting is compute and confirm the value of this setting. The setting is
derived from a TLS exporter (see Section 7.5 of [I-D.ietf-tls-tls13] derived from a TLS exporter (see Section 7.5 of [RFC8446] and
and [RFC5705] for more details on exporters). Clients MUST NOT use [RFC5705] for more details on exporters). Clients MUST NOT use an
an early exporter during their 0-RTT flight, but MUST send an updated early exporter during their 0-RTT flight, but MUST send an updated
SETTINGS frame using a regular exporter after the TLS handshake SETTINGS frame using a regular exporter after the TLS handshake
completes. completes.
The exporter is constructed with the following input: The exporter is constructed with the following input:
o Label: o Label:
* "EXPORTER HTTP CERTIFICATE client" for clients * "EXPORTER HTTP CERTIFICATE client" for clients
* "EXPORTER HTTP CERTIFICATE server" for servers * "EXPORTER HTTP CERTIFICATE server" for servers
skipping to change at page 10, line 34 skipping to change at page 10, line 36
future. Upon receipt of a "CERTIFICATE_REQUEST", endpoints SHOULD future. Upon receipt of a "CERTIFICATE_REQUEST", endpoints SHOULD
provide a corresponding certificate in anticipation of a request provide a corresponding certificate in anticipation of a request
shortly being blocked. Clients MAY wait for a "CERTIFICATE_NEEDED" shortly being blocked. Clients MAY wait for a "CERTIFICATE_NEEDED"
frame to assist in associating the certificate request with a frame to assist in associating the certificate request with a
particular HTTP transaction. particular HTTP transaction.
2.3. Requiring Certificate Authentication 2.3. Requiring Certificate Authentication
2.3.1. Requiring Additional Server Certificates 2.3.1. Requiring Additional Server Certificates
As defined in [RFC7540], when a client finds that a https:// origin As defined in [RFC7540], when a client finds that an https:// origin
(or Alternative Service [RFC7838]) to which it needs to make a (or Alternative Service [RFC7838]) to which it needs to make a
request has the same IP address as a server to which it is already request has the same IP address as a server to which it is already
connected, it MAY check whether the TLS certificate provided contains connected, it MAY check whether the TLS certificate provided contains
the new origin as well, and if so, reuse the connection. the new origin as well, and if so, reuse the connection.
If the TLS certificate does not contain the new origin, but the If the TLS certificate does not contain the new origin, but the
server has claimed support for that origin (with an ORIGIN frame, see server has claimed support for that origin (with an ORIGIN frame, see
[RFC8336]) and advertised support for HTTP-layer certificates (see [RFC8336]) and advertised support for HTTP-layer certificates (see
Section 2.1), the client MAY send a "CERTIFICATE_REQUEST" frame Section 2.1), the client MAY send a "CERTIFICATE_REQUEST" frame
describing the desired origin. The client then sends a describing the desired origin. The client then sends a
skipping to change at page 15, line 28 skipping to change at page 15, line 31
ability, or the recipient is likely to reject it as unsuitable ability, or the recipient is likely to reject it as unsuitable
despite properly validating the authenticator. If the recipient despite properly validating the authenticator. If the recipient
considers the certificate unsuitable, it MAY at its discretion either considers the certificate unsuitable, it MAY at its discretion either
return an error at the HTTP semantic layer, or respond with a stream return an error at the HTTP semantic layer, or respond with a stream
error [RFC7540] on any stream where the certificate is used. error [RFC7540] on any stream where the certificate is used.
Section 4 defines certificate-related error codes which might be Section 4 defines certificate-related error codes which might be
applicable. applicable.
3.3. The CERTIFICATE_REQUEST Frame 3.3. The CERTIFICATE_REQUEST Frame
The "CERTIFICATE_REQUEST" frame (id=0xFRAME-TBD2) provides a exported The "CERTIFICATE_REQUEST" frame (id=0xFRAME-TBD2) provides an
authenticator request message from the TLS layer that specifies a exported authenticator request message from the TLS layer that
desired certificate. This describes the certificate the sender specifies a desired certificate. This describes the certificate the
wishes to have presented. sender wishes to have presented.
The "CERTIFICATE_REQUEST" frame SHOULD NOT be sent to a peer which The "CERTIFICATE_REQUEST" frame SHOULD NOT be sent to a peer which
has not advertised support for HTTP-layer certificate authentication. has not advertised support for HTTP-layer certificate authentication.
The "CERTIFICATE_REQUEST" frame MUST be sent on stream zero. A The "CERTIFICATE_REQUEST" frame MUST be sent on stream zero. A
"CERTIFICATE_REQUEST" frame received on any other stream MUST be "CERTIFICATE_REQUEST" frame received on any other stream MUST be
rejected with a stream error of type "PROTOCOL_ERROR". rejected with a stream error of type "PROTOCOL_ERROR".
0 1 2 3 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 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
skipping to change at page 16, line 23 skipping to change at page 16, line 23
3.3.1. Exported Authenticator Request Characteristics 3.3.1. Exported Authenticator Request Characteristics
The Exported Authenticator "request" API defined in The Exported Authenticator "request" API defined in
[I-D.ietf-tls-exported-authenticator] takes as input a set of desired [I-D.ietf-tls-exported-authenticator] takes as input a set of desired
certificate characteristics and a "certificate_request_context", certificate characteristics and a "certificate_request_context",
which needs to be unpredictable. When generating exported which needs to be unpredictable. When generating exported
authenticators for use with this extension, the authenticators for use with this extension, the
"certificate_request_context" MUST contain both the two-octet "certificate_request_context" MUST contain both the two-octet
Request-ID as well as at least 96 bits of additional entropy. Request-ID as well as at least 96 bits of additional entropy.
Upon receipt of a "CERTIFICATE_REQUEST" frame, the recipient MUST
verify that the first two octets of the authenticator's
"certificate_request_context" matches the Request-ID presented in the
frame.
The TLS library on the authenticating peer will provide mechanisms to The TLS library on the authenticating peer will provide mechanisms to
select an appropriate certificate to respond to the transported select an appropriate certificate to respond to the transported
request. TLS libraries on servers MUST be able to recognize the request. TLS libraries on servers MUST be able to recognize the
"server_name" extension ([RFC6066]) at a minimum. Clients MUST "server_name" extension ([RFC6066]) at a minimum. Clients MUST
always specify the desired origin using this extension, though other always specify the desired origin using this extension, though other
extensions MAY also be included. extensions MAY also be included.
3.4. The CERTIFICATE Frame 3.4. The CERTIFICATE Frame
The "CERTIFICATE" frame (id=0xFRAME-TBD3) provides a exported The "CERTIFICATE" frame (id=0xFRAME-TBD3) provides an exported
authenticator message from the TLS layer that provides a chain of authenticator message from the TLS layer that provides a chain of
certificates, associated extensions and proves possession of the certificates, associated extensions and proves possession of the
private key corresponding to the end-entity certificate. private key corresponding to the end-entity certificate.
The "CERTIFICATE" frame defines two flags: The "CERTIFICATE" frame defines two flags:
TO_BE_CONTINUED (0x01): Indicates that the exported authenticator TO_BE_CONTINUED (0x01): Indicates that the exported authenticator
spans more than one frame. spans more than one frame.
UNSOLICITED (0x02): Indicates that the exported authenticator does
not contain a Request-ID.
0 1 2 3 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 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 (16) | Authenticator Fragment (*)... | Cert-ID (16) | Request-ID (16) |
+-------------------------------+-------------------------------+
| Authenticator Fragment (*) ...
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 11: CERTIFICATE frame payload Figure 11: CERTIFICATE frame payload
The frame contains the following fields: The frame contains the following fields:
Cert-ID: "Cert-ID" is a 16-bit opaque identifier used to correlate Cert-ID: "Cert-ID" is a 16-bit opaque identifier used to correlate
other certificate- related frames with this exported authenticator other certificate- related frames with this exported authenticator
fragment. fragment.
Request-ID: "Request-ID" is an optional 16-bit opaque identifier
used to correlate this exported authenticator with the request
which triggered it, if any. This field is present only if the
"UNSOLICITED" flag is not set.
Authenticator Fragment: A portion of the opaque data returned from Authenticator Fragment: A portion of the opaque data returned from
the TLS connection exported authenticator "authenticate" API. See the TLS connection exported authenticator "authenticate" API. See
Section 3.4.1 for more details on the input to this API. Section 3.4.1 for more details on the input to this API.
An exported authenticator is transported in zero or more An exported authenticator is transported in zero or more
"CERTIFICATE" frames with the "TO_BE_CONTINUED" flag set, followed by "CERTIFICATE" frames with the "TO_BE_CONTINUED" flag set, followed by
one "CERTIFICATE" frame with the "TO_BE_CONTINUED" flag unset. Each one "CERTIFICATE" frame with the "TO_BE_CONTINUED" flag unset. Each
of these frames contains the same "Cert-ID" field, permitting them to of these frames contains the same "Cert-ID" field, permitting them to
be associated with each other. Receipt of any "CERTIFICATE" frame be associated with each other. Receipt of any "CERTIFICATE" frame
with the same "Cert-ID" following the receipt of a "CERTIFICATE" with the same "Cert-ID" following the receipt of a "CERTIFICATE"
frame with "TO_BE_CONTINUED" unset MUST be treated as a connection frame with "TO_BE_CONTINUED" unset MUST be treated as a connection
error of type "PROTOCOL_ERROR". error of type "PROTOCOL_ERROR".
If the "UNSOLICITED" flag is not set, the "CERTIFICATE" frame also
contains a Request-ID indicating the certificate request which caused
this exported authenticator to be generated. The value of this flag
and the contents of the Request-ID field MUST NOT differ between
frames with the same Cert-ID.
Upon receiving a complete series of "CERTIFICATE" frames, the Upon receiving a complete series of "CERTIFICATE" frames, the
receiver may validate the Exported Authenticator value by using the receiver may validate the Exported Authenticator value by using the
exported authenticator API. This returns either an error indicating exported authenticator API. This returns either an error indicating
that the message was invalid, or the certificate chain and extensions that the message was invalid, or the certificate chain and extensions
used to create the message. used to create the message.
The "CERTIFICATE" frame MUST be sent on stream zero. A "CERTIFICATE" The "CERTIFICATE" frame MUST be sent on stream zero. A "CERTIFICATE"
frame received on any other stream MUST be rejected with a stream frame received on any other stream MUST be rejected with a stream
error of type "PROTOCOL_ERROR". error of type "PROTOCOL_ERROR".
skipping to change at page 17, line 43 skipping to change at page 18, line 20
The Exported Authenticator API defined in The Exported Authenticator API defined in
[I-D.ietf-tls-exported-authenticator] takes as input a request, a set [I-D.ietf-tls-exported-authenticator] takes as input a request, a set
of certificates, and supporting information about the certificate of certificates, and supporting information about the certificate
(OCSP, SCT, etc.). The result is an opaque token which is used when (OCSP, SCT, etc.). The result is an opaque token which is used when
generating the "CERTIFICATE" frame. generating the "CERTIFICATE" frame.
Upon receipt of a "CERTIFICATE" frame, an endpoint MUST perform the Upon receipt of a "CERTIFICATE" frame, an endpoint MUST perform the
following steps to validate the token it contains: following steps to validate the token it contains:
o Verify that either the "UNSOLICITED" flag is set (clients only) or
that the Request-ID field contains the Request-ID of a previously-
sent "CERTIFICATE_REQUEST" frame.
o Using the "get context" API, retrieve the o Using the "get context" API, retrieve the
"certificate_request_context" used to generate the authenticator, "certificate_request_context" used to generate the authenticator,
if any. if any. Verify that the "certificate_request_context" begins with
the supplied Request-ID, if any.
o Verify that the "certificate_request_context" is either empty
(clients only) or contains the Request-ID of a previously-sent
"CERTIFICATE_REQUEST" frame.
o Use the "validate" API to confirm the validity of the o Use the "validate" API to confirm the validity of the
authenticator with regard to the generated request (if any). authenticator with regard to the generated request (if any).
Once the authenticator is accepted, the endpoint can perform any Once the authenticator is accepted, the endpoint can perform any
other checks for the acceptability of the certificate itself. other checks for the acceptability of the certificate itself.
Clients MUST NOT accept any end-entity certificate from an exported
authenticator which does not contain the Required Domain extension;
see Section 5 and Section 6.1.
4. Indicating Failures During HTTP-Layer Certificate Authentication 4. Indicating Failures During HTTP-Layer Certificate Authentication
Because this draft permits certificates to be exchanged at the HTTP Because this draft permits certificates to be exchanged at the HTTP
framing layer instead of the TLS layer, several certificate-related framing layer instead of the TLS layer, several certificate-related
errors which are defined at the TLS layer might now occur at the HTTP 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 framing layer. In this section, those errors are restated and added
to the HTTP/2 error code registry. to the HTTP/2 error code registry.
BAD_CERTIFICATE (0xERROR-TBD1): A certificate was corrupt, contained BAD_CERTIFICATE (0xERROR-TBD1): A certificate was corrupt, contained
skipping to change at page 18, line 44 skipping to change at page 19, line 27
As described in [RFC7540], implementations MAY choose to treat a As described in [RFC7540], implementations MAY choose to treat a
stream error as a connection error at any time. Of particular note, stream error as a connection error at any time. Of particular note,
a stream error cannot occur on stream 0, which means that a stream error cannot occur on stream 0, which means that
implementations cannot send non-session errors in response to implementations cannot send non-session errors in response to
"CERTIFICATE_REQUEST", and "CERTIFICATE" frames. Implementations "CERTIFICATE_REQUEST", and "CERTIFICATE" frames. Implementations
which do not wish to terminate the connection MAY either send which do not wish to terminate the connection MAY either send
relevant errors on any stream which references the failing relevant errors on any stream which references the failing
certificate in question or process the requests as unauthenticated certificate in question or process the requests as unauthenticated
and provide error information at the HTTP semantic layer. and provide error information at the HTTP semantic layer.
5. Security Considerations 5. Required Domain Certificate Extension
The Required Domain extension allows certificates to limit their use
with Secondary Certificate Authentication. A client MUST verify that
the server has proven ownership of the indicated identity before
accepting the limited certificate over Secondary Certificate
Authentication.
The identity in this extension is a restriction asserted by the
requester of the certificate and is not verified by the CA.
Conforming CAs SHOULD mark the requiredDomain extension as non-
critical. Conforming CAs MUST require the presence of a CAA record
[RFC6844] prior to issuing a certificate with this extension.
Because a Required Domain value of "*" has a much higher risk of
reuse if compromised, conforming Certificate Authorities are
encouraged to require more extensive verification prior to issuing
such a certificate.
The required domain is represented as a GeneralName, as specified in
Section 4.2.1.6 of [RFC5280]. Unlike the subject field, conforming
CAs MUST NOT issue certificates with a requiredDomain extension
containing empty GeneralName fields. Clients that encounter such a
certificate when processing a certification path MUST consider the
certificate invalid.
The wildcard character "_" MAY be used to represent that any
previously authenticated identity is acceptable. This character MUST
be the entirety of the name if used and MUST have a type of
"dNSName". (That is, "_" is acceptable, but "_.com" and
"w_.example.com" are not).
id-ce-requiredDomain OBJECT IDENTIFIER ::= { id-ce TBD1 }
RequiredDomain ::= GeneralName
6. Security Considerations
This mechanism defines an alternate way to obtain server and client This mechanism defines an alternate way to obtain server and client
certificates other than in the initial TLS handshake. While the certificates other than in the initial TLS handshake. While the
signature of exported authenticator values is expected to be equally signature of exported authenticator values is expected to be equally
secure, it is important to recognize that a vulnerability in this secure, it is important to recognize that a vulnerability in this
code path is at least equal to a vulnerability in the TLS handshake. code path is at least equal to a vulnerability in the TLS handshake.
5.1. Impersonation 6.1. Impersonation
This mechanism could increase the impact of a key compromise. Rather This mechanism could increase the impact of a key compromise. Rather
than needing to subvert DNS or IP routing in order to use a than needing to subvert DNS or IP routing in order to use a
compromised certificate, a malicious server now only needs a client compromised certificate, a malicious server now only needs a client
to connect to _some_ HTTPS site under its control in order to present to connect to _some_ HTTPS site under its control in order to present
the compromised certificate. As recommended in [RFC8336], clients the compromised certificate. As recommended in [RFC8336], clients
opting not to consult DNS ought to employ some alternative means to opting not to consult DNS ought to employ some alternative means to
increase confidence that the certificate is legitimate. increase confidence that the certificate is legitimate.
One such means is the Required Domain certificate extension defined
in {extension}. Clients MUST require that server certificates
presented via this mechanism contain the Required Domain extension
and require that a certificate previously accepted on the connection
(including the certificate presented in TLS) lists the Required
Domain in the Subject field or the Subject Alternative Name
extension.
As noted in the Security Considerations of As noted in the Security Considerations of
[I-D.ietf-tls-exported-authenticator], it difficult to formally prove [I-D.ietf-tls-exported-authenticator], it is difficult to formally
that an endpoint is jointly authoritative over multiple certificates, prove that an endpoint is jointly authoritative over multiple
rather than individually authoritative on each certificate. As a certificates, rather than individually authoritative on each
result, clients MUST NOT assume that because one origin was certificate. As a result, clients MUST NOT assume that because one
previously collocated with another, those origins will be reachable origin was previously colocated with another, those origins will be
via the same endpoints in the future. Clients MUST NOT consider reachable via the same endpoints in the future. Clients MUST NOT
previous secondary certificates to be validated after TLS session consider previous secondary certificates to be validated after TLS
resumption. However, clients MAY proactively query for previously- session resumption. However, clients MAY proactively query for
presented secondary certificates. previously-presented secondary certificates.
5.2. Fingerprinting 6.2. Fingerprinting
This draft defines a mechanism which could be used to probe servers This draft defines a mechanism which could be used to probe servers
for origins they support, but opens no new attack versus making for origins they support, but opens no new attack versus making
repeat TLS connections with different SNI values. Servers SHOULD repeat TLS connections with different SNI values. Servers SHOULD
impose similar denial-of-service mitigations (e.g. request rate impose similar denial-of-service mitigations (e.g. request rate
limits) to "CERTIFICATE_REQUEST" frames as to new TLS connections. limits) to "CERTIFICATE_REQUEST" frames as to new TLS connections.
While the extensions in the "CERTIFICATE_REQUEST" frame permit the While the extensions in the "CERTIFICATE_REQUEST" frame permit the
sender to enumerate the acceptable Certificate Authorities for the sender to enumerate the acceptable Certificate Authorities for the
requested certificate, it might not be prudent (either for security requested certificate, it might not be prudent (either for security
or data consumption) to include the full list of trusted Certificate or data consumption) to include the full list of trusted Certificate
Authorities in every request. Senders, particularly clients, SHOULD Authorities in every request. Senders, particularly clients, SHOULD
send only the extensions that narrowly specify which certificates send only the extensions that narrowly specify which certificates
would be acceptable. would be acceptable.
5.3. Denial of Service 6.3. Denial of Service
Failure to provide a certificate on a stream after receiving Failure to provide a certificate on a stream after receiving
"CERTIFICATE_NEEDED" blocks processing, and SHOULD be subject to "CERTIFICATE_NEEDED" blocks processing, and SHOULD be subject to
standard timeouts used to guard against unresponsive peers. standard timeouts used to guard against unresponsive peers.
Validating a multitude of signatures can be computationally Validating a multitude of signatures can be computationally
expensive, while generating an invalid signature is computationally expensive, while generating an invalid signature is computationally
cheap. Implementations will require checks for attacks from this cheap. Implementations will require checks for attacks from this
direction. Invalid exported authenticators SHOULD be treated as a direction. Invalid exported authenticators SHOULD be treated as a
session error, to avoid further attacks from the peer, though an session error, to avoid further attacks from the peer, though an
implementation MAY instead disable HTTP-layer certificates for the implementation MAY instead disable HTTP-layer certificates for the
current connection instead. current connection instead.
5.4. Confusion About State 6.4. Persistence of Service
CNAME records in the DNS are frequently used to delegate authority
for an origin to a third-party provider. This delegation can be
changed without notice, even to the third-party provider, simply by
modifying the CNAME record in question.
After the owner of the domain has redirected traffic elsewhere by
changing the CNAME, new connections will not arrive for that origin,
but connections which are properly directed to this provider for
other origins would continue to claim control of this origin (via
ORIGIN frame and Secondary Certificates). This is proper behavior
based on the third-party provider's configuration, but would likely
not be what is intended by the owner of the origin.
This is not an issue which can be mitigated by the protocol, but
something about which third-party providers SHOULD educate their
customers before using the features described in this document.
6.5. Confusion About State
Implementations need to be aware of the potential for confusion about Implementations need to be aware of the potential for confusion about
the state of a connection. The presence or absence of a validated the state of a connection. The presence or absence of a validated
certificate can change during the processing of a request, certificate can change during the processing of a request,
potentially multiple times, as "USE_CERTIFICATE" frames are received. potentially multiple times, as "USE_CERTIFICATE" frames are received.
A server that uses certificate authentication needs to be prepared to A server that uses certificate authentication needs to be prepared to
reevaluate the authorization state of a request as the set of reevaluate the authorization state of a request as the set of
certificates changes. certificates changes.
Client implementations need to carefully consider the impact of Client implementations need to carefully consider the impact of
skipping to change at page 20, line 29 skipping to change at page 22, line 27
optimization, permitting the client to avoid a round-trip on each optimization, permitting the client to avoid a round-trip on each
request where the server checks for certificate authentication. request where the server checks for certificate authentication.
However, once this flag has been sent, the client has zero knowledge However, once this flag has been sent, the client has zero knowledge
about whether the server will use the referenced cert for any future about whether the server will use the referenced cert for any future
request, or even for an existing request which has not yet completed. request, or even for an existing request which has not yet completed.
Clients MUST NOT set this flag on any certificate which is not Clients MUST NOT set this flag on any certificate which is not
appropriate for currently-in-flight requests, and MUST NOT make any appropriate for currently-in-flight requests, and MUST NOT make any
future requests on the same connection which they are not willing to future requests on the same connection which they are not willing to
have associated with the provided certificate. have associated with the provided certificate.
6. IANA Considerations 7. IANA Considerations
This draft adds entries in three registries. This draft adds entries in three registries.
The HTTP/2 "SETTINGS_HTTP_CERT_AUTH" setting is registered in The HTTP/2 "SETTINGS_HTTP_CERT_AUTH" setting is registered in
Section 6.1. Four frame types are registered in Section 6.2. Six Section 7.1. Four frame types are registered in Section 7.2. Six
error codes are registered in Section 6.3. error codes are registered in Section 7.3.
6.1. HTTP/2 SETTINGS_HTTP_CERT_AUTH Setting 7.1. HTTP/2 SETTINGS_HTTP_CERT_AUTH Setting
The SETTINGS_HTTP_CERT_AUTH setting is registered in the "HTTP/2 The SETTINGS_HTTP_CERT_AUTH setting is registered in the "HTTP/2
Settings" registry established in [RFC7540]. Settings" registry established in [RFC7540].
Name: SETTINGS_HTTP_CERT_AUTH Name: SETTINGS_HTTP_CERT_AUTH
Code: 0xSETTING-TBD Code: 0xSETTING-TBD
Initial Value: 0 Initial Value: 0
Specification: This document. Specification: This document.
6.2. New HTTP/2 Frames 7.2. New HTTP/2 Frames
Four new frame types are registered in the "HTTP/2 Frame Types" Four new frame types are registered in the "HTTP/2 Frame Types"
registry established in [RFC7540]. The entries in the following registry established in [RFC7540]. The entries in the following
table are registered by this document. table are registered by this document.
+---------------------+--------------+---------------+ +---------------------+--------------+---------------+
| Frame Type | Code | Specification | | Frame Type | Code | Specification |
+---------------------+--------------+---------------+ +---------------------+--------------+---------------+
| CERTIFICATE_NEEDED | 0xFRAME-TBD1 | Section 3.1 | | CERTIFICATE_NEEDED | 0xFRAME-TBD1 | Section 3.1 |
| | | | | | | |
| CERTIFICATE_REQUEST | 0xFRAME-TBD2 | Section 3.3 | | CERTIFICATE_REQUEST | 0xFRAME-TBD2 | Section 3.3 |
| | | | | | | |
| CERTIFICATE | 0xFRAME-TBD3 | Section 3.4 | | CERTIFICATE | 0xFRAME-TBD3 | Section 3.4 |
| | | | | | | |
| USE_CERTIFICATE | 0xFRAME-TBD4 | Section 3.2 | | USE_CERTIFICATE | 0xFRAME-TBD4 | Section 3.2 |
+---------------------+--------------+---------------+ +---------------------+--------------+---------------+
6.3. New HTTP/2 Error Codes 7.3. New HTTP/2 Error Codes
Six new error codes are registered in the "HTTP/2 Error Code" Six new error codes are registered in the "HTTP/2 Error Code"
registry established in [RFC7540]. The entries in the following registry established in [RFC7540]. The entries in the following
table are registered by this document. table are registered by this document.
+-------------------------+--------------+---------------+ +-------------------------+--------------+---------------+
| Name | Code | Specification | | Name | Code | Specification |
+-------------------------+--------------+---------------+ +-------------------------+--------------+---------------+
| BAD_CERTIFICATE | 0xERROR-TBD1 | Section 4 | | BAD_CERTIFICATE | 0xERROR-TBD1 | Section 4 |
| | | | | | | |
skipping to change at page 21, line 45 skipping to change at page 23, line 39
| | | | | | | |
| CERTIFICATE_REVOKED | 0xERROR-TBD3 | Section 4 | | CERTIFICATE_REVOKED | 0xERROR-TBD3 | Section 4 |
| | | | | | | |
| CERTIFICATE_EXPIRED | 0xERROR-TBD4 | Section 4 | | CERTIFICATE_EXPIRED | 0xERROR-TBD4 | Section 4 |
| | | | | | | |
| CERTIFICATE_GENERAL | 0xERROR-TBD5 | Section 4 | | CERTIFICATE_GENERAL | 0xERROR-TBD5 | Section 4 |
| | | | | | | |
| CERTIFICATE_OVERUSED | 0xERROR-TBD6 | Section 4 | | CERTIFICATE_OVERUSED | 0xERROR-TBD6 | Section 4 |
+-------------------------+--------------+---------------+ +-------------------------+--------------+---------------+
7. References 8. References
7.1. Normative References 8.1. Normative References
[I-D.ietf-tls-exported-authenticator] [I-D.ietf-tls-exported-authenticator]
Sullivan, N., "Exported Authenticators in TLS", draft- Sullivan, N., "Exported Authenticators in TLS", draft-
ietf-tls-exported-authenticator-07 (work in progress), ietf-tls-exported-authenticator-08 (work in progress),
June 2018. October 2018.
[I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-28 (work in progress),
March 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066, Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011, DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>. <https://www.rfc-editor.org/info/rfc6066>.
[RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification
Authority Authorization (CAA) Resource Record", RFC 6844,
DOI 10.17487/RFC6844, January 2013,
<https://www.rfc-editor.org/info/rfc6844>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>. <https://www.rfc-editor.org/info/rfc7230>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>. <https://www.rfc-editor.org/info/rfc7540>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7.2. Informative References [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
8.2. Informative References
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport [RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
March 2010, <https://www.rfc-editor.org/info/rfc5705>. March 2010, <https://www.rfc-editor.org/info/rfc5705>.
[RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, DOI 10.17487/RFC7838, Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
April 2016, <https://www.rfc-editor.org/info/rfc7838>. April 2016, <https://www.rfc-editor.org/info/rfc7838>.
[RFC8336] Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame", [RFC8336] Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame",
RFC 8336, DOI 10.17487/RFC8336, March 2018, RFC 8336, DOI 10.17487/RFC8336, March 2018,
<https://www.rfc-editor.org/info/rfc8336>. <https://www.rfc-editor.org/info/rfc8336>.
7.3. URIs 8.3. URIs
[1] https://lists.w3.org/Archives/Public/ietf-http-wg/ [1] https://lists.w3.org/Archives/Public/ietf-http-wg/
[2] http://httpwg.github.io/ [2] http://httpwg.github.io/
[3] https://github.com/httpwg/http-extensions/labels/secondary-certs [3] https://github.com/httpwg/http-extensions/labels/secondary-certs
Appendix A. Change Log Appendix A. Change Log
*RFC Editor's Note:* Please remove this section prior to *RFC Editor's Note:* Please remove this section prior to
publication of a final version of this document. publication of a final version of this document.
A.1. Since draft-ietf-httpbis-http2-secondary-certs-01: A.1. Since draft-ietf-httpbis-http2-secondary-certs-03:
o "CERTIFICATE_REQUEST" frames contain the Request-ID, which MUST be
checked against the "certificate_request_context" of the Exported
Authenticator Request
o "CERTIFICATE" frames contain the Request-ID to which they respond,
unless the UNSOLICITED flag is set
o The Required Domain extension is defined for certificates, which
must be present for certificates presented by servers
A.2. Since draft-ietf-httpbis-http2-secondary-certs-02:
Editorial updates only.
A.3. Since draft-ietf-httpbis-http2-secondary-certs-01:
o Clients can send "CERTIFICATE_NEEDED" for stream 0 rather than o Clients can send "CERTIFICATE_NEEDED" for stream 0 rather than
speculatively reserving a stream for an origin. speculatively reserving a stream for an origin.
o Use SETTINGS to disable when a TLS-terminating proxy is present o Use SETTINGS to disable when a TLS-terminating proxy is present
(#617,#651) (#617,#651)
A.2. Since draft-ietf-httpbis-http2-secondary-certs-00: A.4. Since draft-ietf-httpbis-http2-secondary-certs-00:
o All frames sent on stream zero; replaced "AUTOMATIC_USE" on o All frames sent on stream zero; replaced "AUTOMATIC_USE" on
"CERTIFICATE" with "UNSOLICITED" on "USE_CERTIFICATE". (#482,#566) "CERTIFICATE" with "UNSOLICITED" on "USE_CERTIFICATE". (#482,#566)
o Use Exported Requests from the TLS Exported Authenticators draft; o Use Exported Requests from the TLS Exported Authenticators draft;
eliminate facilities for expressing certificate requirements in eliminate facilities for expressing certificate requirements in
"CERTIFICATE_REQUEST" frame. (#481) "CERTIFICATE_REQUEST" frame. (#481)
A.3. Since draft-bishop-httpbis-http2-additional-certs-05: A.5. Since draft-bishop-httpbis-http2-additional-certs-05:
o Adopted as draft-ietf-httpbis-http2-secondary-certs o Adopted as draft-ietf-httpbis-http2-secondary-certs
Acknowledgements Acknowledgements
Eric Rescorla pointed out several failings in an earlier revision. Eric Rescorla pointed out several failings in an earlier revision.
Andrei Popov contributed to the TLS considerations. Andrei Popov contributed to the TLS considerations.
A substantial portion of Mike's work on this draft was supported by A substantial portion of Mike's work on this draft was supported by
Microsoft during his employment there. Microsoft during his employment there.
 End of changes. 46 change blocks. 
83 lines changed or deleted 201 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/