< draft-yasskin-http-origin-signed-responses-05.txt   draft-yasskin-http-origin-signed-responses-06.txt >
Network Working Group J. Yasskin Network Working Group J. Yasskin
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track January 23, 2019 Intended status: Standards Track July 08, 2019
Expires: July 27, 2019 Expires: January 9, 2020
Signed HTTP Exchanges Signed HTTP Exchanges
draft-yasskin-http-origin-signed-responses-05 draft-yasskin-http-origin-signed-responses-06
Abstract Abstract
This document specifies how a server can send an HTTP exchange--a This document specifies how a server can send an HTTP exchange--a
request URL, content negotiation information, and a response--with request URL, content negotiation information, and a response--with
signatures that vouch for that exchange's authenticity. These signatures that vouch for that exchange's authenticity. These
signatures can be verified against an origin's certificate to signatures can be verified against an origin's certificate to
establish that the exchange is authoritative for an origin even if it establish that the exchange is authoritative for an origin even if it
was transferred over a connection that isn't. The signatures can was transferred over a connection that isn't. The signatures can
also be used in other ways described in the appendices. also be used in other ways described in the appendices.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 July 27, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
skipping to change at page 2, line 27 skipping to change at page 2, line 27
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Signing an exchange . . . . . . . . . . . . . . . . . . . . . 5 3. Signing an exchange . . . . . . . . . . . . . . . . . . . . . 5
3.1. The Signature Header . . . . . . . . . . . . . . . . . . 6 3.1. The Signature Header . . . . . . . . . . . . . . . . . . 6
3.1.1. Examples . . . . . . . . . . . . . . . . . . . . . . 7 3.1.1. Examples . . . . . . . . . . . . . . . . . . . . . . 7
3.1.2. Open Questions . . . . . . . . . . . . . . . . . . . 8 3.1.2. Open Questions . . . . . . . . . . . . . . . . . . . 9
3.2. CBOR representation of exchange response headers . . . . 9 3.2. CBOR representation of exchange response headers . . . . 9
3.2.1. Example . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.1. Example . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Loading a certificate chain . . . . . . . . . . . . . . . 10 3.3. Loading a certificate chain . . . . . . . . . . . . . . . 10
3.4. Canonical CBOR serialization . . . . . . . . . . . . . . 11 3.4. Canonical CBOR serialization . . . . . . . . . . . . . . 11
3.5. Signature validity . . . . . . . . . . . . . . . . . . . 11 3.5. Signature validity . . . . . . . . . . . . . . . . . . . 12
3.5.1. Open Questions . . . . . . . . . . . . . . . . . . . 16 3.5.1. Open Questions . . . . . . . . . . . . . . . . . . . 16
3.6. Updating signature validity . . . . . . . . . . . . . . . 16 3.6. Updating signature validity . . . . . . . . . . . . . . . 16
3.6.1. Examples . . . . . . . . . . . . . . . . . . . . . . 17 3.6.1. Examples . . . . . . . . . . . . . . . . . . . . . . 17
3.7. The Accept-Signature header . . . . . . . . . . . . . . . 18 3.7. The Accept-Signature header . . . . . . . . . . . . . . . 19
3.7.1. Integrity identifiers . . . . . . . . . . . . . . . . 19 3.7.1. Integrity identifiers . . . . . . . . . . . . . . . . 20
3.7.2. Key type identifiers . . . . . . . . . . . . . . . . 19 3.7.2. Key type identifiers . . . . . . . . . . . . . . . . 20
3.7.3. Key value identifiers . . . . . . . . . . . . . . . . 20 3.7.3. Key value identifiers . . . . . . . . . . . . . . . . 20
3.7.4. Examples . . . . . . . . . . . . . . . . . . . . . . 20 3.7.4. Examples . . . . . . . . . . . . . . . . . . . . . . 21
3.7.5. Open Questions . . . . . . . . . . . . . . . . . . . 21 3.7.5. Open Questions . . . . . . . . . . . . . . . . . . . 21
4. Cross-origin trust . . . . . . . . . . . . . . . . . . . . . 21 4. Cross-origin trust . . . . . . . . . . . . . . . . . . . . . 22
4.1. Uncached header fields . . . . . . . . . . . . . . . . . 23 4.1. Uncached header fields . . . . . . . . . . . . . . . . . 23
4.1.1. Stateful header fields . . . . . . . . . . . . . . . 23 4.1.1. Stateful header fields . . . . . . . . . . . . . . . 24
4.2. Certificate Requirements . . . . . . . . . . . . . . . . 24 4.2. Certificate Requirements . . . . . . . . . . . . . . . . 25
5. Transferring a signed exchange . . . . . . . . . . . . . . . 25 4.2.1. Extensions to the CAA Record: cansignhttpexchanges
5.1. Same-origin response . . . . . . . . . . . . . . . . . . 25 Parameter . . . . . . . . . . . . . . . . . . . . . . 26
5.1.1. Serialized headers for a same-origin response . . . . 26 5. Transferring a signed exchange . . . . . . . . . . . . . . . 26
5.1.2. The Signed-Headers Header . . . . . . . . . . . . . . 26 5.1. Same-origin response . . . . . . . . . . . . . . . . . . 26
5.2. HTTP/2 extension for cross-origin Server Push . . . . . . 27 5.1.1. Serialized headers for a same-origin response . . . . 27
5.2.1. Indicating support for cross-origin Server Push . . . 27 5.1.2. The Signed-Headers Header . . . . . . . . . . . . . . 27
5.2.2. NO_TRUSTED_EXCHANGE_SIGNATURE error code . . . . . . 27 5.2. HTTP/2 extension for cross-origin Server Push . . . . . . 28
5.2.3. Validating a cross-origin Push . . . . . . . . . . . 28 5.2.1. Indicating support for cross-origin Server Push . . . 28
5.3. application/signed-exchange format . . . . . . . . . . . 29 5.2.2. NO_TRUSTED_EXCHANGE_SIGNATURE error code . . . . . . 29
5.3.1. Cross-origin trust in application/signed-exchange . . 30 5.2.3. Validating a cross-origin Push . . . . . . . . . . . 29
5.3.2. Example . . . . . . . . . . . . . . . . . . . . . . . 30 5.3. application/signed-exchange format . . . . . . . . . . . 30
5.3.3. Open Questions . . . . . . . . . . . . . . . . . . . 30 5.3.1. Cross-origin trust in application/signed-exchange . . 31
6. Security considerations . . . . . . . . . . . . . . . . . . . 31 5.3.2. Example . . . . . . . . . . . . . . . . . . . . . . . 31
6.1. Over-signing . . . . . . . . . . . . . . . . . . . . . . 31 5.3.3. Open Questions . . . . . . . . . . . . . . . . . . . 32
6.1.1. Session fixation . . . . . . . . . . . . . . . . . . 31 6. Security considerations . . . . . . . . . . . . . . . . . . . 32
6.1.2. Misleading content . . . . . . . . . . . . . . . . . 31 6.1. Over-signing . . . . . . . . . . . . . . . . . . . . . . 32
6.2. Off-path attackers . . . . . . . . . . . . . . . . . . . 32 6.1.1. Session fixation . . . . . . . . . . . . . . . . . . 32
6.3. Downgrades . . . . . . . . . . . . . . . . . . . . . . . 32 6.1.2. Misleading content . . . . . . . . . . . . . . . . . 33
6.4. Signing oracles are permanent . . . . . . . . . . . . . . 32 6.2. Off-path attackers . . . . . . . . . . . . . . . . . . . 33
6.5. Unsigned headers . . . . . . . . . . . . . . . . . . . . 32 6.2.1. Mis-issued certificates . . . . . . . . . . . . . . . 33
6.6. application/signed-exchange . . . . . . . . . . . . . . . 33 6.2.2. Stolen private keys . . . . . . . . . . . . . . . . . 34
6.7. Key re-use with TLS . . . . . . . . . . . . . . . . . . . 33 6.3. Downgrades . . . . . . . . . . . . . . . . . . . . . . . 34
6.8. Content sniffing . . . . . . . . . . . . . . . . . . . . 34 6.4. Signing oracles are permanent . . . . . . . . . . . . . . 35
7. Privacy considerations . . . . . . . . . . . . . . . . . . . 35 6.5. Unsigned headers . . . . . . . . . . . . . . . . . . . . 35
8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 35 6.6. application/signed-exchange . . . . . . . . . . . . . . . 35
8.1. Signature Header Field Registration . . . . . . . . . . . 35 6.7. Key re-use with TLS . . . . . . . . . . . . . . . . . . . 36
8.2. Accept-Signature Header Field Registration . . . . . . . 36 6.8. Content sniffing . . . . . . . . . . . . . . . . . . . . 36
8.3. Signed-Headers Header Field Registration . . . . . . . . 36 7. Privacy considerations . . . . . . . . . . . . . . . . . . . 37
8.4. HTTP/2 Settings . . . . . . . . . . . . . . . . . . . . . 36 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 38
8.5. HTTP/2 Error code . . . . . . . . . . . . . . . . . . . . 37 8.1. Signature Header Field Registration . . . . . . . . . . . 38
8.6. Internet Media Type application/signed-exchange . . . . . 37 8.2. Accept-Signature Header Field Registration . . . . . . . 38
8.7. Internet Media Type application/cert-chain+cbor . . . . . 38 8.3. Signed-Headers Header Field Registration . . . . . . . . 39
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 8.4. HTTP/2 Settings . . . . . . . . . . . . . . . . . . . . . 39
9.1. Normative References . . . . . . . . . . . . . . . . . . 39 8.5. HTTP/2 Error code . . . . . . . . . . . . . . . . . . . . 39
9.2. Informative References . . . . . . . . . . . . . . . . . 41 8.6. Internet Media Type application/signed-exchange . . . . . 39
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 44 8.7. Internet Media Type application/cert-chain+cbor . . . . . 41
Appendix A. Use cases . . . . . . . . . . . . . . . . . . . . . 44 8.8. The cansignhttpexchanges CAA Parameter . . . . . . . . . 42
A.1. PUSHed subresources . . . . . . . . . . . . . . . . . . . 44 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
A.2. Explicit use of a content distributor for subresources . 45 9.1. Normative References . . . . . . . . . . . . . . . . . . 42
A.3. Subresource Integrity . . . . . . . . . . . . . . . . . . 46 9.2. Informative References . . . . . . . . . . . . . . . . . 44
A.4. Binary Transparency . . . . . . . . . . . . . . . . . . . 46 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 47
A.5. Static Analysis . . . . . . . . . . . . . . . . . . . . . 46 Appendix A. Use cases . . . . . . . . . . . . . . . . . . . . . 48
A.6. Offline websites . . . . . . . . . . . . . . . . . . . . 47 A.1. PUSHed subresources . . . . . . . . . . . . . . . . . . . 48
Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 47 A.2. Explicit use of a content distributor for subresources . 48
B.1. Proof of origin . . . . . . . . . . . . . . . . . . . . . 47 A.3. Subresource Integrity . . . . . . . . . . . . . . . . . . 49
B.1.1. Certificate constraints . . . . . . . . . . . . . . . 47 A.4. Binary Transparency . . . . . . . . . . . . . . . . . . . 49
B.1.2. Signature constraints . . . . . . . . . . . . . . . . 47 A.5. Static Analysis . . . . . . . . . . . . . . . . . . . . . 50
B.1.3. Retrieving the certificate . . . . . . . . . . . . . 48 A.6. Offline websites . . . . . . . . . . . . . . . . . . . . 50
B.2. How much to sign . . . . . . . . . . . . . . . . . . . . 48 Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 50
B.2.1. Conveying the signed headers . . . . . . . . . . . . 49 B.1. Proof of origin . . . . . . . . . . . . . . . . . . . . . 50
B.3. Response lifespan . . . . . . . . . . . . . . . . . . . . 49 B.1.1. Certificate constraints . . . . . . . . . . . . . . . 50
B.3.1. Certificate revocation . . . . . . . . . . . . . . . 50 B.1.2. Signature constraints . . . . . . . . . . . . . . . . 51
B.3.2. Response downgrade attacks . . . . . . . . . . . . . 50 B.1.3. Retrieving the certificate . . . . . . . . . . . . . 51
B.4. Low implementation complexity . . . . . . . . . . . . . . 51 B.2. How much to sign . . . . . . . . . . . . . . . . . . . . 52
B.4.1. Limited choices . . . . . . . . . . . . . . . . . . . 51 B.2.1. Conveying the signed headers . . . . . . . . . . . . 52
B.4.2. Bounded-buffering integrity checking . . . . . . . . 51
Appendix C. Determining validity using cache control . . . . . . 51 B.3. Response lifespan . . . . . . . . . . . . . . . . . . . . 53
C.1. Example of updating cache control . . . . . . . . . . . . 52 B.3.1. Certificate revocation . . . . . . . . . . . . . . . 53
C.2. Downsides of updating cache control . . . . . . . . . . . 53 B.3.2. Response downgrade attacks . . . . . . . . . . . . . 53
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 53 B.4. Low implementation complexity . . . . . . . . . . . . . . 54
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 55 B.4.1. Limited choices . . . . . . . . . . . . . . . . . . . 54
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 56 B.4.2. Bounded-buffering integrity checking . . . . . . . . 54
Appendix C. Determining validity using cache control . . . . . . 54
C.1. Example of updating cache control . . . . . . . . . . . . 55
C.2. Downsides of updating cache control . . . . . . . . . . . 56
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 56
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 59
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 59
1. Introduction 1. Introduction
Signed HTTP exchanges provide a way to prove the authenticity of a Signed HTTP exchanges provide a way to prove the authenticity of a
resource in cases where the transport layer isn't sufficient. This resource in cases where the transport layer isn't sufficient. This
can be used in several ways: can be used in several ways:
o When signed by a certificate ([RFC5280]) that's trusted for an o When signed by a certificate ([RFC5280]) that's trusted for an
origin, an exchange can be treated as authoritative for that origin, an exchange can be treated as authoritative for that
origin, even if it was transferred over a connection that isn't origin, even if it was transferred over a connection that isn't
skipping to change at page 6, line 28 skipping to change at page 6, line 32
parameterised list (Section 3.4 of parameterised list (Section 3.4 of
[I-D.ietf-httpbis-header-structure]). Its ABNF is: [I-D.ietf-httpbis-header-structure]). Its ABNF is:
Signature = sh-param-list Signature = sh-param-list
Each parameterised identifier in the list MUST have parameters named Each parameterised identifier in the list MUST have parameters named
"sig", "integrity", "validity-url", "date", and "expires". Each "sig", "integrity", "validity-url", "date", and "expires". Each
parameterised identifier MUST also have either "cert-url" and "cert- parameterised identifier MUST also have either "cert-url" and "cert-
sha256" parameters or an "ed25519key" parameter. This specification sha256" parameters or an "ed25519key" parameter. This specification
gives no meaning to the identifier itself, which can be used as a gives no meaning to the identifier itself, which can be used as a
human-readable identifier for the signature (see human-readable identifier for the signature (however, this is likely
Section 3.1.2, Paragraph 1). The present parameters MUST have the to change soon; see Section 3.1.2, Paragraph 1). The present
following values: parameters MUST have the following values:
"sig" Byte sequence (Section 3.10 of "sig" Byte sequence (Section 3.10 of
[I-D.ietf-httpbis-header-structure]) holding the signature of most [I-D.ietf-httpbis-header-structure]) holding the signature of most
of these parameters and the exchange's URL and response headers. of these parameters and the exchange's URL and response headers.
"integrity" A string (Section 3.8 of "integrity" A string (Section 3.8 of
[I-D.ietf-httpbis-header-structure]) containing a "/"-separated [I-D.ietf-httpbis-header-structure]) containing a "/"-separated
sequence of names starting with the lowercase name of the response sequence of names starting with the lowercase name of the response
header field that guards the response payload's integrity. The header field that guards the response payload's integrity. The
meaning of subsequent names depends on the response header field, meaning of subsequent names depends on the response header field,
skipping to change at page 8, line 38 skipping to change at page 9, line 19
they share a validity range: 7 days starting at 2017-11-19 21:53 UTC. they share a validity range: 7 days starting at 2017-11-19 21:53 UTC.
The publisher then requested an additional signature from The publisher then requested an additional signature from
"thirdparty.example.com", which did some validation or processing and "thirdparty.example.com", which did some validation or processing and
then signed the resource at 2017-11-19 23:11 UTC. then signed the resource at 2017-11-19 23:11 UTC.
"thirdparty.example.com" only grants 4-day signatures, so clients "thirdparty.example.com" only grants 4-day signatures, so clients
will need to re-validate more often. will need to re-validate more often.
3.1.2. Open Questions 3.1.2. Open Questions
[I-D.ietf-httpbis-header-structure] provides a way to parameterise The next revision of [I-D.ietf-httpbis-header-structure] will provide
identifiers but not other supported types like byte sequences. If a way to parameterise byte sequences, at which point the signature
the "Signature" header field is notionally a list of parameterised itself is likely to become the main list item.
signatures, maybe we should add a "parameterised byte sequence" type.
Should the cert-url and validity-url be lists so that intermediates Should the cert-url and validity-url be lists so that intermediates
can offer a cache without losing the original URLs? Putting lists in can offer a cache without losing the original URLs? Putting lists in
dictionary fields is more complex than dictionary fields is more complex than
[I-D.ietf-httpbis-header-structure] allows, so they're single items [I-D.ietf-httpbis-header-structure] allows, so they're single items
for now. for now.
3.2. CBOR representation of exchange response headers 3.2. CBOR representation of exchange response headers
To sign an exchange's response headers, they need to be serialized To sign an exchange's response headers, they need to be serialized
skipping to change at page 9, line 42 skipping to change at page 10, line 23
HTTP/1.1 200 HTTP/1.1 200
Content-Type: text/html Content-Type: text/html
Digest: mi-sha256=dcRDgR2GM35DluAV13PzgnG6+pvQwPywfFvAu1UeFrs= Digest: mi-sha256=dcRDgR2GM35DluAV13PzgnG6+pvQwPywfFvAu1UeFrs=
Signed-Headers: "content-type", "digest" Signed-Headers: "content-type", "digest"
<!doctype html> <!doctype html>
<html> <html>
... ...
The cbor representation consists of the following item, represented The cbor representation consists of the following item, represented
using the extended diagnostic notation from [I-D.ietf-cbor-cddl] using the extended diagnostic notation from [CDDL] appendix G:
appendix G:
{ {
'digest': 'mi-sha256=dcRDgR2GM35DluAV13PzgnG6+pvQwPywfFvAu1UeFrs=', 'digest': 'mi-sha256=dcRDgR2GM35DluAV13PzgnG6+pvQwPywfFvAu1UeFrs=',
':status': '200', ':status': '200',
'content-type': 'text/html' 'content-type': 'text/html'
} }
3.3. Loading a certificate chain 3.3. Loading a certificate chain
The resource at a signature's "cert-url" MUST have the "application/ The resource at a signature's "cert-url" MUST have the "application/
cert-chain+cbor" content type, MUST be canonically-encoded CBOR cert-chain+cbor" content type, MUST be canonically-encoded CBOR
(Section 3.4), and MUST match the following CDDL: (Section 3.4), and MUST match the following CDDL:
cert-chain = [ cert-chain = [
"&#128220;&#9939;", ; U+1F4DC U+26D3 "&#128220;&#9939;", ; U+1F4DC U+26D3
+ { + augmented-certificate
cert: bytes,
? ocsp: bytes,
? sct: bytes,
* tstr => any,
}
] ]
augmented-certificate = {
cert: bytes,
? ocsp: bytes,
? sct: bytes,
* tstr => any,
}
The first map (second item) in the CBOR array is treated as the end- The first map (second item) in the CBOR array is treated as the end-
entity certificate, and the client will attempt to build a path entity certificate, and the client will attempt to build a path
([RFC5280]) to it from a trusted root using the other certificates in ([RFC5280]) to it from a trusted root using the other certificates in
the chain. the chain.
1. Each "cert" value MUST be a DER-encoded X.509v3 certificate 1. Each "cert" value MUST be a DER-encoded X.509v3 certificate
([RFC5280]). Other key/value pairs in the same array item define ([RFC5280]). Other key/value pairs in the same array item define
properties of this certificate. properties of this certificate.
skipping to change at page 16, line 30 skipping to change at page 17, line 6
The "validity-url" parameter (Paragraph 6) of the signatures provides The "validity-url" parameter (Paragraph 6) of the signatures provides
a way to fetch new signatures or learn where to fetch a complete a way to fetch new signatures or learn where to fetch a complete
updated exchange. updated exchange.
Each version of a signed exchange SHOULD have its own validity URLs, Each version of a signed exchange SHOULD have its own validity URLs,
since each version needs different signatures and becomes obsolete at since each version needs different signatures and becomes obsolete at
different times. different times.
The resource at a "validity-url" is "validity data", a CBOR map The resource at a "validity-url" is "validity data", a CBOR map
matching the following CDDL ([I-D.ietf-cbor-cddl]): matching the following CDDL ([CDDL]):
validity = { validity = {
? signatures: [ + bytes ] ? signatures: [ + bytes ]
? update: { ? update: {
? size: uint, ? size: uint,
} }
] ]
The elements of the "signatures" array are parameterised identifiers The elements of the "signatures" array are parameterised identifiers
(Section 4.2.6 of [I-D.ietf-httpbis-header-structure]) meant to (Section 4.2.6 of [I-D.ietf-httpbis-header-structure]) meant to
skipping to change at page 19, line 36 skipping to change at page 20, line 16
indicates that a feature of the "Signature" header field indicates that a feature of the "Signature" header field
(Section 3.1) is supported. If the identifier begins with a "-" (Section 3.1) is supported. If the identifier begins with a "-"
character, it instead indicates that the feature named by the rest of character, it instead indicates that the feature named by the rest of
the identifier is not supported. Unknown identifiers and parameters the identifier is not supported. Unknown identifiers and parameters
MUST be ignored because new identifiers and new parameters on MUST be ignored because new identifiers and new parameters on
existing identifiers may be defined by future specifications. existing identifiers may be defined by future specifications.
3.7.1. Integrity identifiers 3.7.1. Integrity identifiers
Identifiers starting with "digest/" indicate that the client supports Identifiers starting with "digest/" indicate that the client supports
the "Digest" header field ({{!RFC3230) with the parameter from the the "Digest" header field ([RFC3230]) with the parameter from the
HTTP Digest Algorithm Values Registry [6] registry named in lower- HTTP Digest Algorithm Values Registry [6] registry named in lower-
case by the rest of the identifier. For example, "digest/mi-blake2" case by the rest of the identifier. For example, "digest/mi-blake2"
indicates support for Merkle integrity with the as-yet-unspecified indicates support for Merkle integrity with the as-yet-unspecified
mi-blake2 parameter, and "-digest/mi-sha256" indicates non-support mi-blake2 parameter, and "-digest/mi-sha256" indicates non-support
for Merkle integrity with the mi-sha256 content encoding. for Merkle integrity with the mi-sha256 content encoding.
If the "Accept-Signature" header field is present, servers SHOULD If the "Accept-Signature" header field is present, servers SHOULD
assume support for "digest/mi-sha256" unless the header field states assume support for "digest/mi-sha256" unless the header field states
otherwise. otherwise.
skipping to change at page 24, line 50 skipping to change at page 25, line 33
private key is exposed to an unauthorized entity, but they generally private key is exposed to an unauthorized entity, but they generally
don't need to be revoked if a signing oracle is exposed and then don't need to be revoked if a signing oracle is exposed and then
removed. removed.
CA certificates, by contrast, need to be revoked if an unauthorized CA certificates, by contrast, need to be revoked if an unauthorized
entity is able to make even one unauthorized signature. entity is able to make even one unauthorized signature.
Certificates with this extension MUST be revoked if an unauthorized Certificates with this extension MUST be revoked if an unauthorized
entity is able to make even one unauthorized signature. entity is able to make even one unauthorized signature.
Certificates with this extension MUST have a Validity Period no
greater than 90 days.
Conforming CAs MUST NOT mark this extension as critical. Conforming CAs MUST NOT mark this extension as critical.
A conforming CA MUST NOT issue certificates with this extension
unless, for each dNSName in the subjectAltName extension of the
certificate to be issued:
1. An "issue" or "issuewild" CAA property ([RFC6844]) exists that
authorizes the CA to issue the certificate; and
2. The "cansignhttpexchanges" parameter (Section 4.2.1) is present
on the property and is equal to "yes"
Clients MUST NOT accept certificates with this extension in TLS Clients MUST NOT accept certificates with this extension in TLS
connections (Section 4.4.2.2 of [RFC8446]). connections (Section 4.4.2.2 of [RFC8446]).
RFC EDITOR PLEASE DELETE THE REST OF THE PARAGRAPHS IN THIS SECTION RFC EDITOR PLEASE DELETE THE REST OF THE PARAGRAPHS IN THIS SECTION
id-ce-google OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 11129 } id-ce-google OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 11129 }
id-ce-canSignHttpExchangesDraft OBJECT IDENTIFIER ::= { id-ce-google 2 1 22 } id-ce-canSignHttpExchangesDraft OBJECT IDENTIFIER ::= { id-ce-google 2 1 22 }
Implementations of drafts of this specification MAY recognize the Implementations of drafts of this specification MAY recognize the
"id-ce-canSignHttpExchangesDraft" OID as identifying the "id-ce-canSignHttpExchangesDraft" OID as identifying the
CanSignHttpExchanges extension. This OID might or might not be used CanSignHttpExchanges extension. This OID might or might not be used
as the final OID for the extension, so certificates including it as the final OID for the extension, so certificates including it
might need to be reissued once the final RFC is published. might need to be reissued once the final RFC is published.
Some certificates have already been issued with this extension and
with validity periods longer than 90 days. These certificates will
not immediately be treated as invalid. Instead:
o Clients MUST reject certificates with this extension that were
issued after 2019-05-01 and have a Validity Period longer than 90
days.
o After 2019-08-01, clients MUST reject all certificates with this
extension that have a Validity Period longer than 90 days.
The above requirements on CAs to limit the Validity Period and check
for a CAA parameter are effective starting 2019-05-01.
4.2.1. Extensions to the CAA Record: cansignhttpexchanges Parameter
A CAA parameter "cansignhttpexchanges" is defined for the "issue" and
"issuewild" properties defined by [RFC6844]. The value of this
parameter, if specified, MUST be "yes".
5. Transferring a signed exchange 5. Transferring a signed exchange
A signed exchange can be transferred in several ways, of which three A signed exchange can be transferred in several ways, of which three
are described here. are described here.
5.1. Same-origin response 5.1. Same-origin response
The signature for a signed exchange can be included in a normal HTTP The signature for a signed exchange can be included in a normal HTTP
response. Because different clients send different request header response. Because different clients send different request header
fields, clients don't know how the server's content negotiation fields, clients don't know how the server's content negotiation
skipping to change at page 29, line 35 skipping to change at page 30, line 48
the MIME type, and recipients that receive both MUST check that the MIME type, and recipients that receive both MUST check that
they match and stop parsing if they don't. they match and stop parsing if they don't.
Note: RFC EDITOR PLEASE DELETE THIS NOTE; The implementation of Note: RFC EDITOR PLEASE DELETE THIS NOTE; The implementation of
the final RFC MUST use this file signature, but implementations the final RFC MUST use this file signature, but implementations
of drafts MUST NOT use it and MUST use another implementation- of drafts MUST NOT use it and MUST use another implementation-
specific 8-byte string beginning with "sxg1-". specific 8-byte string beginning with "sxg1-".
2. 2 bytes storing a big-endian integer "fallbackUrlLength". 2. 2 bytes storing a big-endian integer "fallbackUrlLength".
3. "fallbackUrlLength" bytes holding a "fallbackUrl", which MUST be 3. "fallbackUrlLength" bytes holding a "fallbackUrl", which MUST
an absolute URL with a scheme of "https". UTF-8 decode to an absolute URL with a scheme of "https".
Note: The byte location of the fallback URL is intended to remain Note: The byte location of the fallback URL is intended to remain
invariant across versions of the "application/signed-exchange" invariant across versions of the "application/signed-exchange"
format so that parsers encountering unknown versions can always format so that parsers encountering unknown versions can always
find a URL to redirect to. find a URL to redirect to.
Issue: Should this fallback information also include the method? Issue: Should this fallback information also include the method?
4. 3 bytes storing a big-endian integer "sigLength". If this is 4. 3 bytes storing a big-endian integer "sigLength". If this is
larger than 16384 (16*1024), parsing MUST fail. larger than 16384 (16*1024), parsing MUST fail.
skipping to change at page 30, line 32 skipping to change at page 31, line 45
To determine whether to trust a cross-origin exchange stored in an To determine whether to trust a cross-origin exchange stored in an
"application/signed-exchange" resource, pass the "Signature" header "application/signed-exchange" resource, pass the "Signature" header
field's value, "fallbackUrl" as the effective request URI, field's value, "fallbackUrl" as the effective request URI,
"signedHeaders", and the payload body to the algorithm in Section 4. "signedHeaders", and the payload body to the algorithm in Section 4.
5.3.2. Example 5.3.2. Example
An example "application/signed-exchange" file representing a possible An example "application/signed-exchange" file representing a possible
signed exchange with https://example.com/ [8] follows, with lengths signed exchange with https://example.com/ [8] follows, with lengths
represented by descriptions in "<>"s, CBOR represented in the represented by descriptions in "<>"s, CBOR represented in the
extended diagnostic format defined in Appendix G of extended diagnostic format defined in Appendix G of [CDDL], and most
[I-D.ietf-cbor-cddl], and most of the "Signature" header field and of the "Signature" header field and payload elided with a ...:
payload elided with a ...:
sxg1\0\0\0\0<2-byte length of the following url string> sxg1\0\0\0\0<2-byte length of the following url string>
https://example.com/<3-byte length of the following header https://example.com/<3-byte length of the following header
value><3-byte length of the encoding of the value><3-byte length of the encoding of the
following map>sig1; sig=*...; integrity="digest/mi-sha256"; ...{ following map>sig1; sig=*...; integrity="digest/mi-sha256"; ...{
':status': '200', ':status': '200',
'content-type': 'text/html' 'content-type': 'text/html'
}<!doctype html>\r\n<html>... }<!doctype html>\r\n<html>...
5.3.3. Open Questions 5.3.3. Open Questions
skipping to change at page 32, line 12 skipping to change at page 33, line 28
attacker-specific information in the signed response. It does not attacker-specific information in the signed response. It does not
prevent the attacker from showing their victim a signed-out page when prevent the attacker from showing their victim a signed-out page when
the victim is actually signed in, but while this is still misleading, the victim is actually signed in, but while this is still misleading,
it seems less likely to be useful to the attacker. it seems less likely to be useful to the attacker.
6.2. Off-path attackers 6.2. Off-path attackers
Relaxing the requirement to consult DNS when determining authority Relaxing the requirement to consult DNS when determining authority
for an origin means that an attacker who possesses a valid for an origin means that an attacker who possesses a valid
certificate no longer needs to be on-path to redirect traffic to certificate no longer needs to be on-path to redirect traffic to
them; instead of modifying DNS, they need only convince the user to them; instead of modifying DNS or IP routing, they need only convince
visit another Web site in order to serve responses signed as the the user to visit another Web site in order to serve responses signed
target. This consideration and mitigations for it are shared by the as the target. This consideration and mitigations for it are shared
combination of [RFC8336] and by the combination of [RFC8336] and
[I-D.ietf-httpbis-http2-secondary-certs]. [I-D.ietf-httpbis-http2-secondary-certs], and are discussed further
in [I-D.bishop-httpbis-origin-fed-up].
6.2.1. Mis-issued certificates
If a CA mis-issues a certificate for a domain, this specification
provides a way to detect the mis-issuance and mitigate harm within
approximately two weeks. Specifically, because all signed exchanges
must include a "SignedCertificateTimestampList" ([RFC6962], a CT log
has promised to publish the mis-issued certificate within that log's
Maximum Merge Delay, 1 day for many logs. The domain owner can then
detect the mis-issued certificate and notify the CA to revoke it,
which the [BRs], section 4.9.1.1, say they must do within another 5
days.
Once the mis-issued certificate is revoked, existing OCSP responses
begin to expire. The [BRs], section 4.9.10, require that OCSP
responses have a maximum expiration time of 10 days, after which they
can't be used to validate a certificate chain (Section 3.3). This
leads to a total compromised time of 16 days after a mis-issuance.
However, CAs might future-date their OCSP responses, in which case
the mitigation doesn't work.
CAs are forbidden from future-dating their OCSP responses by the
[BRs] section 4.9.9, "OCSP responses MUST conform to RFC6960 and/or
RFC5019." [RFC6960] includes, "The time at which the status was
known to be correct SHALL be reflected in the thisUpdate field of the
response.", and [RFC5019] includes, "When pre-producing OCSPResponse
messages, the responder MUST set the thisUpdate, nextUpdate, and
producedAt times as follows: thisUpdate: The time at which the status
being indicated is known to be correct."
However, if a CA violates the [BRs] to sign future-dated OCSP
responses, attempts to keep the nonconformant OCSP responses private,
but then leaks them, it could cause clients to trust a hostile signed
exchange long after its certificate has been revoked.
Clients could use systems like [CRLSets] and [OneCrl] to revoke the
intermediate certificate that signed the future-dated OCSP responses.
6.2.2. Stolen private keys
If the private key for a CanSignHttpExchanges certificate is stolen,
it can be used at scale until the certificate expires or is revoked,
and unlike for a stolen key for a normal TLS-terminating certificate,
the rightful owner can't detect the problem by watching for attacks
on the DNS or routing infrastructure.
This specification does not currently propose a way for the rightful
owner to detect that their keys are being used by an attacker, after
they've opted into the risk by requesting a CanSignHttpExchanges
certificate in the first place. Clients can fetch a signature's
"validity-url" (Section 3.1) to help owners detect key compromise,
but that compromises some of the privacy properties of this
specification.
6.3. Downgrades 6.3. Downgrades
Signing a bad response can affect more users than simply serving a Signing a bad response can affect more users than simply serving a
bad response, since a served response will only affect users who make bad response, since a served response will only affect users who make
a request while the bad version is live, while an attacker can a request while the bad version is live, while an attacker can
forward a signed response until its signature expires. Publishers forward a signed response until its signature expires. Publishers
should consider shorter signature expiration times than they use for should consider shorter signature expiration times than they use for
cache expiration times. cache expiration times.
skipping to change at page 39, line 24 skipping to change at page 42, line 5
Authors' Addresses section. Authors' Addresses section.
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: N/A Restrictions on usage: N/A
Author: See Authors' Addresses section. Author: See Authors' Addresses section.
Change controller: IESG Change controller: IESG
8.8. The cansignhttpexchanges CAA Parameter
There are no IANA considerations for this parameter.
9. References 9. References
9.1. Normative References 9.1. Normative References
[FETCH] WHATWG, "Fetch", January 2019, [CDDL] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
<https://fetch.spec.whatwg.org/>. Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[I-D.ietf-cbor-cddl] [FETCH] WHATWG, "Fetch", July 2019,
Birkholz, H., Vigano, C., and C. Bormann, "Concise data <https://fetch.spec.whatwg.org/>.
definition language (CDDL): a notational convention to
express CBOR and JSON data structures", draft-ietf-cbor-
cddl-06 (work in progress), November 2018.
[I-D.ietf-httpbis-header-structure] [I-D.ietf-httpbis-header-structure]
Nottingham, M. and P. Kamp, "Structured Headers for HTTP", Nottingham, M. and P. Kamp, "Structured Headers for HTTP",
draft-ietf-httpbis-header-structure-09 (work in progress), draft-ietf-httpbis-header-structure-10 (work in progress),
December 2018. April 2019.
[I-D.ietf-httpbis-variants] [I-D.ietf-httpbis-variants]
Nottingham, M., "HTTP Representation Variants", draft- Nottingham, M., "HTTP Representation Variants", draft-
ietf-httpbis-variants-04 (work in progress), October 2018. ietf-httpbis-variants-05 (work in progress), March 2019.
[I-D.thomson-http-mice] [I-D.thomson-http-mice]
Thomson, M. and J. Yasskin, "Merkle Integrity Content Thomson, M. and J. Yasskin, "Merkle Integrity Content
Encoding", draft-thomson-http-mice-03 (work in progress), Encoding", draft-thomson-http-mice-03 (work in progress),
August 2018. August 2018.
[POSIX] IEEE and The Open Group, "The Open Group Base [POSIX] IEEE and The Open Group, "The Open Group Base
Specifications Issue 7", name IEEE, value 1003.1-2008, Specifications Issue 7", name IEEE, value 1003.1-2008,
2016 Edition, 2016, 2016 Edition, 2016,
<http://pubs.opengroup.org/onlinepubs/9699919799/ <http://pubs.opengroup.org/onlinepubs/9699919799/
skipping to change at page 40, line 36 skipping to change at page 43, line 21
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[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>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP", Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013, RFC 6960, DOI 10.17487/RFC6960, June 2013,
<https://www.rfc-editor.org/info/rfc6960>. <https://www.rfc-editor.org/info/rfc6960>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
<https://www.rfc-editor.org/info/rfc6962>. <https://www.rfc-editor.org/info/rfc6962>.
skipping to change at page 41, line 38 skipping to change at page 44, line 28
<https://www.rfc-editor.org/info/rfc8032>. <https://www.rfc-editor.org/info/rfc8032>.
[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>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[URL] WHATWG, "URL", January 2019, [URL] WHATWG, "URL", July 2019, <https://url.spec.whatwg.org/>.
<https://url.spec.whatwg.org/>.
9.2. Informative References 9.2. Informative References
[BRs] CA/Browser Forum, "Baseline Requirements for the Issuance
and Management of Publicly-Trusted Certificates", December
2018,
<https://cabforum.org/baseline-requirements-documents/>.
[CRLSets] Langley, A., "Revocation checking and Chrome's CRL",
February 2012,
<https://www.imperialviolet.org/2012/02/05/crlsets.html>.
[I-D.bishop-httpbis-origin-fed-up]
Bishop, M. and E. Nygren, "DNS Security with HTTP/2
ORIGIN", draft-bishop-httpbis-origin-fed-up-00 (work in
progress), January 2019.
[I-D.burke-content-signature] [I-D.burke-content-signature]
Burke, B., "HTTP Header for digital signatures", draft- Burke, B., "HTTP Header for digital signatures", draft-
burke-content-signature-00 (work in progress), March 2011. burke-content-signature-00 (work in progress), March 2011.
[I-D.cavage-http-signatures] [I-D.cavage-http-signatures]
Cavage, M. and M. Sporny, "Signing HTTP Messages", draft- Cavage, M. and M. Sporny, "Signing HTTP Messages", draft-
cavage-http-signatures-10 (work in progress), May 2018. cavage-http-signatures-11 (work in progress), April 2019.
[I-D.ietf-httpbis-cache] [I-D.ietf-httpbis-cache]
Fielding, R., Nottingham, M., and J. Reschke, "HTTP Fielding, R., Nottingham, M., and J. Reschke, "HTTP
Caching", draft-ietf-httpbis-cache-03 (work in progress), Caching", draft-ietf-httpbis-cache-04 (work in progress),
October 2018. March 2019.
[I-D.ietf-httpbis-http2-secondary-certs] [I-D.ietf-httpbis-http2-secondary-certs]
Bishop, M., Sullivan, N., and M. Thomson, "Secondary Bishop, M., Sullivan, N., and M. Thomson, "Secondary
Certificate Authentication in HTTP/2", draft-ietf-httpbis- Certificate Authentication in HTTP/2", draft-ietf-httpbis-
http2-secondary-certs-03 (work in progress), October 2018. http2-secondary-certs-04 (work in progress), April 2019.
[I-D.thomson-http-content-signature] [I-D.thomson-http-content-signature]
Thomson, M., "Content-Signature Header Field for HTTP", Thomson, M., "Content-Signature Header Field for HTTP",
draft-thomson-http-content-signature-00 (work in draft-thomson-http-content-signature-00 (work in
progress), July 2015. progress), July 2015.
[I-D.yasskin-httpbis-origin-signed-exchanges-impl] [I-D.yasskin-httpbis-origin-signed-exchanges-impl]
Yasskin, J. and K. Ueno, "Signed HTTP Exchanges Yasskin, J. and K. Ueno, "Signed HTTP Exchanges
Implementation Checkpoints", draft-yasskin-httpbis-origin- Implementation Checkpoints", draft-yasskin-httpbis-origin-
signed-exchanges-impl-02 (work in progress), September signed-exchanges-impl-02 (work in progress), September
2018. 2018.
[I-D.yasskin-webpackage-use-cases] [I-D.yasskin-webpackage-use-cases]
Yasskin, J., "Use Cases and Requirements for Web Yasskin, J., "Use Cases and Requirements for Web
Packages", draft-yasskin-webpackage-use-cases-01 (work in Packages", draft-yasskin-webpackage-use-cases-01 (work in
progress), March 2018. progress), March 2018.
[OneCrl] Goodwin, M., "Revoking Intermediate Certificates:
Introducing OneCRL", March 2015,
<https://blog.mozilla.org/security/2015/03/03/
revoking-intermediate-certificates-introducing-onecrl/>.
[RFC2965] Kristol, D. and L. Montulli, "HTTP State Management [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2965, DOI 10.17487/RFC2965, October 2000, Mechanism", RFC 2965, DOI 10.17487/RFC2965, October 2000,
<https://www.rfc-editor.org/info/rfc2965>. <https://www.rfc-editor.org/info/rfc2965>.
[RFC5019] Deacon, A. and R. Hurst, "The Lightweight Online
Certificate Status Protocol (OCSP) Profile for High-Volume
Environments", RFC 5019, DOI 10.17487/RFC5019, September
2007, <https://www.rfc-editor.org/info/rfc5019>.
[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>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011, DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/info/rfc6265>. <https://www.rfc-editor.org/info/rfc6265>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
skipping to change at page 53, line 22 skipping to change at page 56, line 35
decide which set to use when actually parsing the resource itself. decide which set to use when actually parsing the resource itself.
This need to store and reconcile multiple sets of headers for a This need to store and reconcile multiple sets of headers for a
single signed exchange argues for embedding a signature's lifetime single signed exchange argues for embedding a signature's lifetime
into the signature. into the signature.
Appendix D. Change Log Appendix D. Change Log
RFC EDITOR PLEASE DELETE THIS SECTION. RFC EDITOR PLEASE DELETE THIS SECTION.
draft-06
o Add a security consideration for future-dated OCSP responses and
for stolen private keys.
o Define a CAA parameter to opt into certificate issuance.
o Limit certificate lifetimes to 90 days.
o UTF-8 decode the fallback URL.
draft-05 draft-05
o Define absolute URLs, and limit the schemes each instance can use. o Define absolute URLs, and limit the schemes each instance can use.
o Fill in TBD size limits. o Fill in TBD size limits.
o Update to mice-03 including the Digest header. o Update to mice-03 including the Digest header.
o Refer to draft-yasskin-httpbis-origin-signed-exchanges-impl for o Refer to draft-yasskin-httpbis-origin-signed-exchanges-impl for
draft version numbers. draft version numbers.
skipping to change at page 55, line 45 skipping to change at page 59, line 18
o Define an "Accept-Signature" header to negotiate whether to send o Define an "Accept-Signature" header to negotiate whether to send
Signatures and which ones. Signatures and which ones.
o Define an "application/http-exchange+cbor" format to fetch signed o Define an "application/http-exchange+cbor" format to fetch signed
exchanges without HTTP/2 Push. exchanges without HTTP/2 Push.
o 2 new use cases. o 2 new use cases.
Appendix E. Acknowledgements Appendix E. Acknowledgements
Thanks to Devin Mullins, Ilari Liusvaara, Justin Schuh, Mark Thanks to Andrew Ayer, Devin Mullins, Ilari Liusvaara, Justin Schuh,
Nottingham, Mike Bishop, Ryan Sleevi, and Yoav Weiss for comments Mark Nottingham, Mike Bishop, Ryan Sleevi, and Yoav Weiss for
that improved this draft. comments that improved this draft.
Author's Address Author's Address
Jeffrey Yasskin Jeffrey Yasskin
Google Google
Email: jyasskin@chromium.org Email: jyasskin@chromium.org
 End of changes. 39 change blocks. 
123 lines changed or deleted 257 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/