idnits 2.17.1 

draft-yasskin-http-origin-signed-responses-03.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** There are 11 instances of too long lines in the document, the longest
     one being 35 characters in excess of 72.

  ** The abstract seems to contain references ([2], [1]), which it shouldn't.
      Please replace those with straight textual mentions of the documents in
     question.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust and authors Copyright Line does not
     match the current year

  -- The document date (March 05, 2018) is 2234 days in the past.  Is this
     intentional?

  -- Found something which looks like a code comment -- if you have code
     sections in the document, please surround them with '<CODE BEGINS>' and
     '<CODE ENDS>' lines.


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  -- Looks like a reference, but probably isn't: '1' on line 1786

  -- Looks like a reference, but probably isn't: '2' on line 1788

  -- Looks like a reference, but probably isn't: '3' on line 1790

  -- Looks like a reference, but probably isn't: '4' on line 1793

  -- Looks like a reference, but probably isn't: '5' on line 1795

  -- Looks like a reference, but probably isn't: '100' on line 494

  == Missing Reference: '-1' is mentioned on line 496, but not defined

  -- Looks like a reference, but probably isn't: '6' on line 1797

  -- Looks like a reference, but probably isn't: '7' on line 1799

  -- Looks like a reference, but probably isn't: '8' on line 1801

  -- Looks like a reference, but probably isn't: '9' on line 1803

  -- Looks like a reference, but probably isn't: '10' on line 1865

  -- Looks like a reference, but probably isn't: '11' on line 1879

  -- Looks like a reference, but probably isn't: '12' on line 1894

  -- Looks like a reference, but probably isn't: '13' on line 1916

  -- Looks like a reference, but probably isn't: '14' on line 1917

  -- Looks like a reference, but probably isn't: '15' on line 1933

  -- Looks like a reference, but probably isn't: '16' on line 2040

  -- Looks like a reference, but probably isn't: '17' on line 2084

  -- Looks like a reference, but probably isn't: '18' on line 2092

  == Unused Reference: 'HTML' is defined on line 1594, but no explicit
     reference was found in the text

  -- Possible downref: Non-RFC (?) normative reference: ref. 'FETCH'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'HTML'

  == Outdated reference: A later version (-08) exists of
     draft-ietf-cbor-cddl-02

  == Outdated reference: A later version (-19) exists of
     draft-ietf-httpbis-header-structure-04

  == Outdated reference: A later version (-28) exists of
     draft-ietf-tls-tls13-26

  == Outdated reference: A later version (-03) exists of
     draft-thomson-http-mice-02

  -- Possible downref: Non-RFC (?) normative reference: ref. 'POSIX'

  ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960)

  ** Obsolete normative reference: RFC 3230 (Obsoleted by RFC 9530)

  ** Obsolete normative reference: RFC 6962 (Obsoleted by RFC 9162)

  ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949)

  ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112)

  ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110)

  ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111)

  ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113)

  ** Downref: Normative reference to an Informational RFC: RFC 8017

  ** Downref: Normative reference to an Informational RFC: RFC 8032

  == Outdated reference: A later version (-12) exists of
     draft-cavage-http-signatures-09

  == Outdated reference: A later version (-06) exists of
     draft-ietf-httpbis-http2-secondary-certs-00

  == Outdated reference: A later version (-02) exists of
     draft-yasskin-webpackage-use-cases-00

  -- Obsolete informational reference (is this intentional?): RFC 2965
     (Obsoleted by RFC 6265)

  -- Obsolete informational reference (is this intentional?): RFC 7235
     (Obsoleted by RFC 9110)

  -- Obsolete informational reference (is this intentional?): RFC 7615
     (Obsoleted by RFC 9110)


     Summary: 12 errors (**), 0 flaws (~~), 10 warnings (==), 27 comments
     (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

--------------------------------------------------------------------------------


2	Network Working Group                                         J. Yasskin
3	Internet-Draft                                                    Google
4	Intended status: Standards Track                          March 05, 2018
5	Expires: September 6, 2018

7	                         Signed HTTP Exchanges
8	             draft-yasskin-http-origin-signed-responses-03

10	Abstract

12	   This document specifies how a server can send an HTTP request/
13	   response pair, known as an exchange, with signatures that vouch for
14	   that exchange's authenticity.  These signatures can be verified
15	   against an origin's certificate to establish that the exchange is
16	   authoritative for an origin even if it was transferred over a
17	   connection that isn't.  The signatures can also be used in other ways
18	   described in the appendices.

20	   These signatures contain countermeasures against downgrade and
21	   protocol-confusion attacks.

23	Note to Readers

25	   Discussion of this draft takes place on the HTTP working group
26	   mailing list (ietf-http-wg@w3.org), which is archived at
27	   https://lists.w3.org/Archives/Public/ietf-http-wg/ [1].

29	   The source code and issues list for this draft can be found in
30	   https://github.com/WICG/webpackage [2].

32	Status of This Memo

34	   This Internet-Draft is submitted in full conformance with the
35	   provisions of BCP 78 and BCP 79.

37	   Internet-Drafts are working documents of the Internet Engineering
38	   Task Force (IETF).  Note that other groups may also distribute
39	   working documents as Internet-Drafts.  The list of current Internet-
40	   Drafts is at https://datatracker.ietf.org/drafts/current/.

42	   Internet-Drafts are draft documents valid for a maximum of six months
43	   and may be updated, replaced, or obsoleted by other documents at any
44	   time.  It is inappropriate to use Internet-Drafts as reference
45	   material or to cite them other than as "work in progress."

47	   This Internet-Draft will expire on September 6, 2018.

49	Copyright Notice

51	   Copyright (c) 2018 IETF Trust and the persons identified as the
52	   document authors.  All rights reserved.

54	   This document is subject to BCP 78 and the IETF Trust's Legal
55	   Provisions Relating to IETF Documents
56	   (https://trustee.ietf.org/license-info) in effect on the date of
57	   publication of this document.  Please review these documents
58	   carefully, as they describe your rights and restrictions with respect
59	   to this document.  Code Components extracted from this document must
60	   include Simplified BSD License text as described in Section 4.e of
61	   the Trust Legal Provisions and are provided without warranty as
62	   described in the Simplified BSD License.

64	Table of Contents

66	   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
67	   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
68	   3.  Signing an exchange . . . . . . . . . . . . . . . . . . . . .   5
69	     3.1.  The Signature Header  . . . . . . . . . . . . . . . . . .   5
70	       3.1.1.  Examples  . . . . . . . . . . . . . . . . . . . . . .   6
71	       3.1.2.  Open Questions  . . . . . . . . . . . . . . . . . . .   8
72	     3.2.  CBOR representation of exchange headers . . . . . . . . .   8
73	       3.2.1.  Example . . . . . . . . . . . . . . . . . . . . . . .   9
74	     3.3.  Loading a certificate chain . . . . . . . . . . . . . . .  10
75	     3.4.  Canonical CBOR serialization  . . . . . . . . . . . . . .  11
76	     3.5.  Signature validity  . . . . . . . . . . . . . . . . . . .  11
77	       3.5.1.  Open Questions  . . . . . . . . . . . . . . . . . . .  15
78	     3.6.  Updating signature validity . . . . . . . . . . . . . . .  15
79	       3.6.1.  Examples  . . . . . . . . . . . . . . . . . . . . . .  16
80	     3.7.  The Accept-Signature header . . . . . . . . . . . . . . .  18
81	       3.7.1.  Integrity labels  . . . . . . . . . . . . . . . . . .  18
82	       3.7.2.  Key type labels . . . . . . . . . . . . . . . . . . .  19
83	       3.7.3.  Key value labels  . . . . . . . . . . . . . . . . . .  19
84	       3.7.4.  Examples  . . . . . . . . . . . . . . . . . . . . . .  20
85	       3.7.5.  Open Questions  . . . . . . . . . . . . . . . . . . .  20
86	   4.  Cross-origin trust  . . . . . . . . . . . . . . . . . . . . .  20
87	     4.1.  Stateful header fields  . . . . . . . . . . . . . . . . .  21
88	     4.2.  Certificate Requirements  . . . . . . . . . . . . . . . .  22
89	   5.  Transferring a signed exchange  . . . . . . . . . . . . . . .  23
90	     5.1.  Same-origin response  . . . . . . . . . . . . . . . . . .  23
91	       5.1.1.  Significant headers for a same-origin response  . . .  24
92	       5.1.2.  The Signed-Headers Header . . . . . . . . . . . . . .  24
93	     5.2.  HTTP/2 extension for cross-origin Server Push . . . . . .  25
94	       5.2.1.  Indicating support for cross-origin Server Push . . .  25
95	       5.2.2.  NO_TRUSTED_EXCHANGE_SIGNATURE error code  . . . . . .  25
96	       5.2.3.  Validating a cross-origin Push  . . . . . . . . . . .  26

98	     5.3.  application/http-exchange+cbor format for HTTP/1
99	           compatibility . . . . . . . . . . . . . . . . . . . . . .  26
100	       5.3.1.  Example . . . . . . . . . . . . . . . . . . . . . . .  28
101	       5.3.2.  Open Questions  . . . . . . . . . . . . . . . . . . .  28
102	   6.  Security considerations . . . . . . . . . . . . . . . . . . .  28
103	     6.1.  Over-signing  . . . . . . . . . . . . . . . . . . . . . .  29
104	       6.1.1.  Session fixation  . . . . . . . . . . . . . . . . . .  29
105	       6.1.2.  Misleading content  . . . . . . . . . . . . . . . . .  29
106	     6.2.  Off-path attackers  . . . . . . . . . . . . . . . . . . .  30
107	     6.3.  Downgrades  . . . . . . . . . . . . . . . . . . . . . . .  30
108	     6.4.  Signing oracles are permanent . . . . . . . . . . . . . .  30
109	     6.5.  Unsigned headers  . . . . . . . . . . . . . . . . . . . .  30
110	     6.6.  application/http-exchange+cbor  . . . . . . . . . . . . .  31
111	   7.  Privacy considerations  . . . . . . . . . . . . . . . . . . .  31
112	   8.  IANA considerations . . . . . . . . . . . . . . . . . . . . .  32
113	     8.1.  Signature Header Field Registration . . . . . . . . . . .  32
114	     8.2.  HTTP/2 Settings . . . . . . . . . . . . . . . . . . . . .  32
115	     8.3.  HTTP/2 Error code . . . . . . . . . . . . . . . . . . . .  32
116	     8.4.  Internet Media Type application/http-exchange+cbor  . . .  33
117	     8.5.  Internet Media Type application/cert-chain+cbor . . . . .  33
118	   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  34
119	     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  34
120	     9.2.  Informative References  . . . . . . . . . . . . . . . . .  37
121	     9.3.  URIs  . . . . . . . . . . . . . . . . . . . . . . . . . .  39
122	   Appendix A.  Use cases  . . . . . . . . . . . . . . . . . . . . .  39
123	     A.1.  PUSHed subresources . . . . . . . . . . . . . . . . . . .  39
124	     A.2.  Explicit use of a content distributor for subresources  .  40
125	     A.3.  Subresource Integrity . . . . . . . . . . . . . . . . . .  41
126	     A.4.  Binary Transparency . . . . . . . . . . . . . . . . . . .  41
127	     A.5.  Static Analysis . . . . . . . . . . . . . . . . . . . . .  41
128	     A.6.  Offline websites  . . . . . . . . . . . . . . . . . . . .  42
129	   Appendix B.  Requirements . . . . . . . . . . . . . . . . . . . .  42
130	     B.1.  Proof of origin . . . . . . . . . . . . . . . . . . . . .  42
131	       B.1.1.  Certificate constraints . . . . . . . . . . . . . . .  42
132	       B.1.2.  Signature constraints . . . . . . . . . . . . . . . .  42
133	       B.1.3.  Retrieving the certificate  . . . . . . . . . . . . .  43
134	     B.2.  How much to sign  . . . . . . . . . . . . . . . . . . . .  43
135	       B.2.1.  Conveying the signed headers  . . . . . . . . . . . .  44
136	     B.3.  Response lifespan . . . . . . . . . . . . . . . . . . . .  45
137	       B.3.1.  Certificate revocation  . . . . . . . . . . . . . . .  45
138	       B.3.2.  Response downgrade attacks  . . . . . . . . . . . . .  45
139	   Appendix C.  Determining validity using cache control . . . . . .  46
140	     C.1.  Example of updating cache control . . . . . . . . . . . .  46
141	     C.2.  Downsides of updating cache control . . . . . . . . . . .  47
142	   Appendix D.  Change Log . . . . . . . . . . . . . . . . . . . . .  48
143	   Appendix E.  Acknowledgements . . . . . . . . . . . . . . . . . .  49
144	   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  49

146	1.  Introduction

148	   Signed HTTP exchanges provide a way to prove the authenticity of a
149	   resource in cases where the transport layer isn't sufficient.  This
150	   can be used in several ways:

152	   o  When signed by a certificate ([RFC5280]) that's trusted for an
153	      origin, an exchange can be treated as authoritative for that
154	      origin, even if it was transferred over a connection that isn't
155	      authoritative (Section 9.1 of [RFC7230]) for that origin.  See
156	      Appendix A.1 and Appendix A.2.

158	   o  A top-level resource can use a public key to identify an expected
159	      author for particular subresources, a system known as Subresource
160	      Integrity ([SRI]).  An exchange's signature provides the matching
161	      proof of authorship.  See Appendix A.3.

163	   o  A signature can vouch for the exchange in some way, for example
164	      that it appears in a transparency log or that static analysis
165	      indicates that it omits certain attacks.  See Appendix A.4 and
166	      Appendix A.5.

168	   Subsequent work toward the use cases in
169	   [I-D.yasskin-webpackage-use-cases] will provide a way to group signed
170	   exchanges into bundles that can be transmitted and stored together,
171	   but single signed exchanges are useful enough to standardize on their
172	   own.

174	2.  Terminology

176	   Author  The entity that controls the server for a particular origin
177	      [RFC6454].  The author can get a CA to issue certificates for
178	      their private keys and can run a TLS server for their origin.

180	   Exchange (noun)  An HTTP request/response pair.  This can either be a
181	      request from a client and the matching response from a server or
182	      the request in a PUSH_PROMISE and its matching response stream.
183	      Defined by Section 8 of [RFC7540].

185	   Intermediate  An entity that fetches signed HTTP exchanges from an
186	      author or another intermediate and forwards them to another
187	      intermediate or a client.

189	   Client  An entity that uses a signed HTTP exchange and needs to be
190	      able to prove that the author vouched for it as coming from its
191	      claimed origin.

193	   Unix time  Defined by [POSIX] section 4.16 [3].

195	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
196	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
197	   "OPTIONAL" in this document are to be interpreted as described in BCP
198	   14 [RFC2119] [RFC8174] when, and only when, they appear in all
199	   capitals, as shown here.

201	3.  Signing an exchange

203	   In the response of an HTTP exchange the server MAY include a
204	   "Signature" header field (Section 3.1) holding a list of one or more
205	   parameterised signatures that vouch for the content of the exchange.
206	   Exactly which content the signature vouches for can depend on how the
207	   exchange is transferred (Section 5).

209	   The client categorizes each signature as "valid" or "invalid" by
210	   validating that signature with its certificate or public key and
211	   other metadata against the exchange's headers and content
212	   (Section 3.5).  This validity then informs higher-level protocols.

214	   Each signature is parameterised with information to let a client
215	   fetch assurance that a signed exchange is still valid, in the face of
216	   revoked certificates and newly-discovered vulnerabilities.  This
217	   assurance can be bundled back into the signed exchange and forwarded
218	   to another client, which won't have to re-fetch this validity
219	   information for some period of time.

221	3.1.  The Signature Header

223	   The "Signature" header field conveys a list of signatures for an
224	   exchange, each one accompanied by information about how to determine
225	   the authority of and refresh that signature.  Each signature directly
226	   signs the exchange's headers and identifies one of those headers that
227	   enforces the integrity of the exchange's payload.

229	   The "Signature" header is a Structured Header as defined by
230	   [I-D.ietf-httpbis-header-structure].  Its value MUST be a list
231	   (Section 4.8 of [I-D.ietf-httpbis-header-structure]) of parameterised
232	   labels (Section 4.4 of [I-D.ietf-httpbis-header-structure]).

234	   Each parameterised label MUST have parameters named "sig",
235	   "integrity", "validityUrl", "date", and "expires".  Each
236	   parameterised label MUST also have either "certUrl" and "certSha256"
237	   parameters or an "ed25519Key" parameter.  This specification gives no
238	   meaning to the label itself, which can be used as a human-readable
239	   identifier for the signature (see Section 3.1.2, Paragraph 1).  The
240	   present parameters MUST have the following values:

242	   "sig"  Binary content (Section 4.5 of
243	      [I-D.ietf-httpbis-header-structure]) holding the signature of most
244	      of these parameters and the exchange's headers.

246	   "integrity"  A string (Section 4.2 of
247	      [I-D.ietf-httpbis-header-structure]) containing the lowercase name
248	      of the response header field that guards the response payload's
249	      integrity.

251	   "certUrl"  A string (Section 4.2 of
252	      [I-D.ietf-httpbis-header-structure]) containing a valid URL string
253	      [4].

255	   "certSha256"  Binary content (Section 4.5 of
256	      [I-D.ietf-httpbis-header-structure]) holding the SHA-256 hash of
257	      the first certificate found at "certUrl".

259	   "ed25519Key"  Binary content (Section 4.5 of
260	      [I-D.ietf-httpbis-header-structure]) holding an Ed25519 public key
261	      ([RFC8032]).

263	   "validityUrl"  A string (Section 4.2 of
264	      [I-D.ietf-httpbis-header-structure]) containing a valid URL string
265	      [5].

267	   "date" and "expires"  An unsigned integer (Section 4.1 of
268	      [I-D.ietf-httpbis-header-structure]) representing a Unix time.

270	   The "certUrl" parameter is _not_ signed, so intermediates can update
271	   it with a pointer to a cached version.

273	3.1.1.  Examples

275	   The following header is included in the response for an exchange with
276	   effective request URI "https://example.com/resource.html".  Newlines
277	   are added for readability.

279	Signature:
280	 sig1;
281	  sig=*MEUCIQDXlI2gN3RNBlgFiuRNFpZXcDIaUpX6HIEwcZEc0cZYLAIga9DsVOMM+g5YpwEBdGW3sS+bvnmAJJiSMwhuBdqp5UY;
282	  integrity="mi";
283	  validityUrl="https://example.com/resource.validity.1511128380";
284	  certUrl="https://example.com/oldcerts";
285	  certSha256=*W7uB969dFW3Mb5ZefPS9Tq5ZbH5iSmOILpjv2qEArmI;
286	  date=1511128380; expires=1511733180,
287	 sig2;
288	  sig=*MEQCIGjZRqTRf9iKNkGFyzRMTFgwf/BrY2ZNIP/dykhUV0aYAiBTXg+8wujoT4n/W+cNgb7pGqQvIUGYZ8u8HZJ5YH26Qg;
289	  integrity="mi";
290	  validityUrl="https://example.com/resource.validity.1511128380";
291	  certUrl="https://example.com/newcerts";
292	  certSha256=*J/lEm9kNRODdCmINbvitpvdYKNQ+YgBj99DlYp4fEXw;
293	  date=1511128380; expires=1511733180,
294	 srisig;
295	  sig=*lGZVaJJM5f2oGczFlLmBdKTDL+QADza4BgeO494ggACYJOvrof6uh5OJCcwKrk7DK+LBch0jssDYPp5CLc1SDA
296	  integrity="mi";
297	  validityUrl="https://example.com/resource.validity.1511128380";
298	  ed25519Key=*zsSevyFsxyZHiUluVBDd4eypdRLTqyWRVOJuuKUz+A8
299	  date=1511128380; expires=1511733180,
300	 thirdpartysig;
301	  sig=*MEYCIQCNxJzn6Rh2fNxsobktir8TkiaJYQFhWTuWI1i4PewQaQIhAMs2TVjc4rTshDtXbgQEOwgj2mRXALhfXPztXgPupii+;
302	  integrity="mi";
303	  validityUrl="https://thirdparty.example.com/resource.validity.1511161860";
304	  certUrl="https://thirdparty.example.com/certs";
305	  certSha256=*UeOwUPkvxlGRTyvHcsMUN0A2oNsZbU8EUvg8A9ZAnNc;
306	  date=1511133060; expires=1511478660,

308	   There are 4 signatures: 2 from different secp256r1 certificates
309	   within "https://example.com/", one using a raw ed25519 public key
310	   that's also controlled by "example.com", and a fourth using a
311	   secp256r1 certificate owned by "thirdparty.example.com".

313	   All 4 signatures rely on the "MI" response header to guard the
314	   integrity of the response payload.  This isn't strictly required--
315	   some signatures could use "MI" while others use "Digest"--but there's
316	   not much benefit to mixing them.

318	   The signatures include a "validityUrl" that includes the first time
319	   the resource was seen.  This allows multiple versions of a resource
320	   at the same URL to be updated with new signatures, which allows
321	   clients to avoid transferring extra data while the old versions don't
322	   have known security bugs.

324	   The certificates at "https://example.com/oldcerts" and
325	   "https://example.com/newcerts" have "subjectAltName"s of
326	   "example.com", meaning that if they and their signatures validate,
327	   the exchange can be trusted as having an origin of
328	   "https://example.com/".  The author might be using two certificates
329	   because their readers have disjoint sets of roots in their trust
330	   stores.

332	   The author signed with all three certificates at the same time, so
333	   they share a validity range: 7 days starting at 2017-11-19 21:53 UTC.

335	   The author then requested an additional signature from
336	   "thirdparty.example.com", which did some validation or processing and
337	   then signed the resource at 2017-11-19 23:11 UTC.
338	   "thirdparty.example.com" only grants 4-day signatures, so clients
339	   will need to re-validate more often.

341	3.1.2.  Open Questions

343	   [I-D.ietf-httpbis-header-structure] provides a way to parameterise
344	   labels but not other supported types like binary content.  If the
345	   "Signature" header field is notionally a list of parameterised
346	   signatures, maybe we should add a "parameterised binary content"
347	   type.

349	   Should the certUrl and validityUrl be lists so that intermediates can
350	   offer a cache without losing the original URLs?  Putting lists in
351	   dictionary fields is more complex than
352	   [I-D.ietf-httpbis-header-structure] allows, so they're single items
353	   for now.

355	3.2.  CBOR representation of exchange headers

357	   To sign an exchange's headers, they need to be serialized into a byte
358	   string.  Since intermediaries and distributors (Appendix A.2) might
359	   rearrange, add, or just reserialize headers, we can't use the literal
360	   bytes of the headers as this serialization.  Instead, this section
361	   defines a CBOR representation that can be embedded into other CBOR,
362	   canonically serialized (Section 3.4), and then signed.

364	   The CBOR representation of an exchange "exchange"'s headers is the
365	   CBOR ([RFC7049]) array with the following content:

367	   1.  The map mapping:

369	       *  The byte string ':method' to the byte string containing
370	          "exchange"'s request's method.

372	       *  The byte string ':url' to the byte string containing
373	          "exchange"'s request's effective request URI.

375	       *  For each request header field in "exchange", the header
376	          field's name as a byte string to the header field's value as a
377	          byte string.

379	   2.  The map mapping:

381	       *  the byte string ':status' to the byte string containing
382	          "exchange"'s response's 3-digit status code, and

384	       *  for each response header field in "exchange", the header
385	          field's name as a byte string to the header field's value as a
386	          byte string.

388	3.2.1.  Example

390	   Given the HTTP exchange:

392	GET https://example.com/ HTTP/1.1
393	Accept: */*

395	HTTP/1.1 200
396	Content-Type: text/html
397	Digest: SHA-256=20addcf7368837f616d549f035bf6784ea6d4bf4817a3736cd2fc7a763897fe3
398	Signed-Headers: "content-type", "digest"

400	<!doctype html>
401	<html>
402	...

404	   The cbor representation consists of the following item, represented
405	   using the extended diagnostic notation from [I-D.ietf-cbor-cddl]
406	   appendix G:

408	[
409	  {
410	    ':url': 'https://example.com/'
411	    ':method': 'GET',
412	  },
413	  {
414	    'digest': 'SHA-256=20addcf7368837f616d549f035bf6784ea6d4bf4817a3736cd2fc7a763897fe3',
415	    ':status': '200',
416	    'content-type': 'text/html'
417	  }
418	]
419	3.3.  Loading a certificate chain

421	   The resource at a signature's "certUrl" MUST have the "application/
422	   cert-chain+cbor" content type, MUST be canonically-encoded CBOR
423	   (Section 3.4), and MUST match the following CDDL:

425	   cert-chain = [
426	     "&#128220;&#9939;", ; U+1F4DC U+26D3
427	     + {
428	       cert: bytes,
429	       ? ocsp: bytes,
430	       ? sct: bytes,
431	       * tstr => any,
432	     }
433	   ]

435	   The first item in the CBOR array is treated as the end-entity
436	   certificate, and the client will attempt to build a path ([RFC5280])
437	   to it from a trusted root using the other certificates in the chain.

439	   1.  Each "cert" value MUST be a DER-encoded X.509v3 certificate
440	       ([RFC5280]).  Other key/value pairs in the same array item define
441	       properties of this certificate.

443	   2.  The first certificate's "ocsp" value if any MUST be a complete,
444	       DER-encoded OCSP response for that certificate (using the ASN.1
445	       type "OCSPResponse" defined in [RFC2560]).  Subsequent
446	       certificates MUST NOT have an "ocsp" value.

448	   3.  Each certificate's "sct" value MUST be a
449	       "SignedCertificateTimestampList" for that certificate as defined
450	       by Section 3.3 of [RFC6962].

452	   Loading a "certUrl" takes a "forceFetch" flag.  The client MUST:

454	   1.  Let "raw-chain" be the result of fetching ([FETCH]) "certUrl".
455	       If "forceFetch" is _not_ set, the fetch can be fulfilled from a
456	       cache using normal HTTP semantics [RFC7234].  If this fetch
457	       fails, return "invalid".

459	   2.  Let "certificate-chain" be the array of certificates and
460	       properties produced by parsing "raw-chain" using the CDDL above.
461	       If any of the requirements above aren't satisfied, return
462	       "invalid".  Note that this validation requirement might be
463	       impractical to completely achieve due to certificate validation
464	       implementations that don't enforce DER encoding or other standard
465	       constraints.

467	   3.  Return "certificate-chain".

469	3.4.  Canonical CBOR serialization

471	   Within this specification, the canonical serialization of a CBOR item
472	   uses the following rules derived from Section 3.9 of [RFC7049] with
473	   erratum 4964 applied:

475	   o  Integers and the lengths of arrays, maps, and strings MUST use the
476	      smallest possible encoding.

478	   o  Items MUST NOT be encoded with indefinite length.

480	   o  The keys in every map MUST be sorted in the bytewise lexicographic
481	      order of their canonical encodings.  For example, the following
482	      keys are correctly sorted:

484	      1.  10, encoded as 0A.

486	      2.  100, encoded as 18 64.

488	      3.  -1, encoded as 20.

490	      4.  "z", encoded as 61 7A.

492	      5.  "aa", encoded as 62 61 61.

494	      6.  [100], encoded as 81 18 64.

496	      7.  [-1], encoded as 81 20.

498	      8.  false, encoded as F4.

500	   Note: this specification does not use floating point, tags, or other
501	   more complex data types, so it doesn't need rules to canonicalize
502	   those.

504	3.5.  Signature validity

506	   The client MUST parse the "Signature" header field as the list of
507	   parameterised values (Section 4.8.1 of
508	   [I-D.ietf-httpbis-header-structure]) described in Section 3.1.  If an
509	   error is thrown during this parsing or any of the requirements
510	   described there aren't satisfied, the exchange has no valid
511	   signatures.  Otherwise, each member of this list represents a
512	   signature with parameters.

514	   The client MUST use the following algorithm to determine whether each
515	   signature with parameters is invalid or potentially-valid for an
516	   "exchange".  Potentially-valid results include:

518	   o  The signed headers of the exchange so that higher-level protocols
519	      can avoid relying on unsigned headers, and

521	   o  Either a certificate chain or a public key so that a higher-level
522	      protocol can determine whether it's actually valid.

524	   This algorithm accepts a "forceFetch" flag that avoids the cache when
525	   fetching URLs.  A client that determines that a potentially-valid
526	   certificate chain is actually invalid due to an expired OCSP response
527	   MAY retry with "forceFetch" set to retrieve an updated OCSP from the
528	   original server.

530	   1.   Let "payload" be the payload body (Section 3.3 of [RFC7230]) of
531	        "exchange".  Note that the payload body is the message body with
532	        any transfer encodings removed.

534	   2.   Let:

536	        *  "signature" be the signature (binary content in the
537	           parameterised label's "sig" parameter).

539	        *  "integrity" be the signature's "integrity" parameter.

541	        *  "validityUrl" be the signature's "validityUrl" parameter.

543	        *  "certUrl" be the signature's "certUrl" parameter, if any.

545	        *  "certSha256" be the signature's "certSha256" parameter, if
546	           any.

548	        *  "ed25519Key" be the signature's "ed25519Key" parameter, if
549	           any.

551	        *  "date" be the signature's "date" parameter, interpreted as a
552	           Unix time.

554	        *  "expires" be the signature's "expires" parameter, interpreted
555	           as a Unix time.

557	   3.   If "integrity" names a header field that is not present in
558	        "exchange"'s response headers or which the client cannot use to
559	        check the integrity of "payload" (for example, the header field
560	        is new and hasn't been implemented yet), then return "invalid".

562	        Clients MUST implement at least the "Digest" ([RFC3230]) and
563	        "MI" ([I-D.thomson-http-mice]) header fields.

565	   4.   If "integrity" is "digest", and the "Digest" header field in
566	        "exchange"'s response headers contains no digest-algorithms
567	        (https://www.iana.org/assignments/http-dig-alg/http-dig-
568	        alg.xhtml [6]) stronger than "SHA", then return "invalid".

570	   5.   Set "publicKey" and "signing-alg" depending on which key fields
571	        are present:

573	        1.  If "certUrl" is present:

575	            1.  Let "certificate-chain" be the result of loading the
576	                certificate chain at "certUrl" passing the "forceFetch"
577	                flag (Section 3.3).  If this returns "invalid", return
578	                "invalid".

580	            2.  Let "main-certificate" be the first certificate in
581	                "certificate-chain".

583	            3.  Set "publicKey" to "main-certificate"'s public key.

585	            4.  The client MUST define a partial function from public
586	                key types to signing algorithms, and this function must
587	                at the minimum include the following mappings:

589	                RSA, 2048 bits:  rsa_pss_rsae_sha256 or
590	                   rsa_pss_pss_sha256, as defined in Section 4.2.3 of
591	                   [I-D.ietf-tls-tls13], depending on which of the
592	                   rsaEncryption OID or RSASSA-PSS OID [RFC8017] is
593	                   used.

595	                EC, with the secp256r1 curve:  ecdsa_secp256r1_sha256 as
596	                   defined in Section 4.2.3 of [I-D.ietf-tls-tls13].

598	                EC, with the secp384r1 curve:  ecdsa_secp384r1_sha384 as
599	                   defined in Section 4.2.3 of [I-D.ietf-tls-tls13].

601	                Set "signing-alg" to the result of applying this
602	                function to the type of "main-certificate"'s public key.
603	                If the function is undefined on this input, return
604	                "invalid".

606	        2.  If "ed25519Key" is present, set "publicKey" to "ed25519Key"
607	            and "signing-alg" to ed25519, as defined by [RFC8032]

609	   6.   If "expires" is more than 7 days (604800 seconds) after "date",
610	        return "invalid".

612	   7.   If the current time is before "date" or after "expires", return
613	        "invalid".

615	   8.   Let "message" be the concatenation of the following byte
616	        strings:

618	        1.  A context string: the ASCII encoding of "HTTP Exchange".

620	        2.  A single 0 byte which serves as a separator.

622	        3.  The bytes of the canonical CBOR serialization (Section 3.4)
623	            of a CBOR map mapping:

625	            1.  If "certSha256" is set:

627	                1.  The text string "certSha256" to the byte string
628	                    value of "certSha256".

630	            2.  The text string "validityUrl" to the byte string value
631	                of "validityUrl".

633	            3.  The text string "date" to the integer value of "date".

635	            4.  The text string "expires" to the integer value of
636	                "expires".

638	            5.  The text string "headers" to the CBOR representation
639	                (Section 3.2) of "exchange"'s headers.

641	   9.   If "certUrl" is present and the SHA-256 hash of "main-
642	        certificate"'s "cert_data" is not equal to "certSha256" (whose
643	        presence was checked when the "Signature" header field was
644	        parsed), return "invalid".

646	        Note that this intentionally differs from TLS 1.3, which signs
647	        the entire certificate chain in its Certificate Verify
648	        (Section 4.4.3 of [I-D.ietf-tls-tls13]), in order to allow
649	        updating the stapled OCSP response without updating signatures
650	        at the same time.

652	   10.  If "signature" is a valid signature of "message" by "publicKey"
653	        using "signing-alg", return "potentially-valid" with whichever
654	        is present of "certificate-chain" or "ed25519Key".  Otherwise,
655	        return "invalid".

657	   Note that the above algorithm can determine that an exchange's
658	   headers are potentially-valid before the exchange's payload is
659	   received.  Similarly, if "integrity" identifies a header field like
660	   "MI" ([I-D.thomson-http-mice]) that can incrementally validate the
661	   payload, early parts of the payload can be determined to be
662	   potentially-valid before later parts of the payload.  Higher-level
663	   protocols MAY process parts of the exchange that have been determined
664	   to be potentially-valid as soon as that determination is made but
665	   MUST NOT process parts of the exchange that are not yet potentially-
666	   valid.  Similarly, as the higher-level protocol determines that parts
667	   of the exchange are actually valid, the client MAY process those
668	   parts of the exchange and MUST wait to process other parts of the
669	   exchange until they too are determined to be valid.

671	3.5.1.  Open Questions

673	   Should the signed message use the TLS format (with an initial 64
674	   spaces) even though these certificates can't be used in TLS servers?

676	3.6.  Updating signature validity

678	   Both OCSP responses and signatures are designed to expire a short
679	   time after they're signed, so that revoked certificates and signed
680	   exchanges with known vulnerabilities are distrusted promptly.

682	   This specification provides no way to update OCSP responses by
683	   themselves.  Instead, clients need to re-fetch the "certUrl"
684	   (Section 3.5, Paragraph 4) to get a chain including a newer OCSP
685	   response.

687	   The "validityUrl" parameter (Paragraph 6) of the signatures provides
688	   a way to fetch new signatures or learn where to fetch a complete
689	   updated exchange.

691	   Each version of a signed exchange SHOULD have its own validity URLs,
692	   since each version needs different signatures and becomes obsolete at
693	   different times.

695	   The resource at a "validityUrl" is "validity data", a CBOR map
696	   matching the following CDDL ([I-D.ietf-cbor-cddl]):

698	   validity = {
699	     ? signatures: [ + bytes ]
700	     ? update: {
701	       ? size: uint,
702	     }
703	   ]
704	   The elements of the "signatures" array are parameterised labels
705	   (Section 4.4 of [I-D.ietf-httpbis-header-structure]) meant to replace
706	   the signatures within the "Signature" header field pointing to this
707	   validity data.  If the signed exchange contains a bug severe enough
708	   that clients need to stop using the content, the "signatures" array
709	   MUST NOT be present.

711	   If the the "update" map is present, that indicates that a new version
712	   of the signed exchange is available at its effective request URI
713	   (Section 5.5 of [RFC7230]) and can give an estimate of the size of
714	   the updated exchange ("update.size").  If the signed exchange is
715	   currently the most recent version, the "update" SHOULD NOT be
716	   present.

718	   If both the "signatures" and "update" fields are present, clients can
719	   use the estimated size to decide whether to update the whole resource
720	   or just its signatures.

722	3.6.1.  Examples

724	   For example, say a signed exchange whose URL is "https://example.com/
725	   resource" has the following "Signature" header field (with line
726	   breaks included and irrelevant fields omitted for ease of reading).

728	Signature:
729	 sig1;
730	  sig=*MEUCIQ...;
731	  ...
732	  validityUrl="https://example.com/resource.validity.1511157180";
733	  certUrl="https://example.com/oldcerts";
734	  date=1511128380; expires=1511733180,
735	 sig2;
736	  sig=*MEQCIG...;
737	  ...
738	  validityUrl="https://example.com/resource.validity.1511157180";
739	  certUrl="https://example.com/newcerts";
740	  date=1511128380; expires=1511733180,
741	 thirdpartysig;
742	  sig=*MEYCIQ...;
743	  ...
744	  validityUrl="https://thirdparty.example.com/resource.validity.1511161860";
745	  certUrl="https://thirdparty.example.com/certs";
746	  date=1511478660; expires=1511824260

748	   At 2017-11-27 11:02 UTC, "sig1" and "sig2" have expired, but
749	   "thirdpartysig" doesn't exipire until 23:11 that night, so the client
750	   needs to fetch "https://example.com/resource.validity.1511157180"
751	   (the "validityUrl" of "sig1" and "sig2") to update those signatures.
752	   This URL might contain:

754	{
755	  "signatures": [
756	    'sig1; '
757	    'sig=*MEQCIC/I9Q+7BZFP6cSDsWx43pBAL0ujTbON/+7RwKVk+ba5AiB3FSFLZqpzmDJ0NumNwN04pqgJZE99fcK86UjkPbj4jw; '
758	    'validityUrl="https://example.com/resource.validity.1511157180"; '
759	    'integrity="mi"; '
760	    'certUrl="https://example.com/newcerts"; '
761	    'certSha256=*J/lEm9kNRODdCmINbvitpvdYKNQ+YgBj99DlYp4fEXw; '
762	    'date=1511733180; expires=1512337980'
763	  ],
764	  "update": {
765	    "size": 5557452
766	  }
767	}

769	   This indicates that the client could fetch a newer version at
770	   "https://example.com/resource" (the original URL of the exchange), or
771	   that the validity period of the old version can be extended by
772	   replacing the first two of the original signatures (the ones with a
773	   validityUrl of "https://example.com/resource.validity.1511157180")
774	   with the single new signature provided.  (This might happen at the
775	   end of a migration to a new root certificate.)  The signatures of the
776	   updated signed exchange would be:

778	Signature:
779	 sig1;
780	  sig=*MEQCIC...;
781	  ...
782	  validityUrl="https://example.com/resource.validity.1511157180";
783	  certUrl="https://example.com/newcerts";
784	  date=1511733180; expires=1512337980,
785	 thirdpartysig;
786	  sig=*MEYCIQ...;
787	  ...
788	  validityUrl="https://thirdparty.example.com/resource.validity.1511161860";
789	  certUrl="https://thirdparty.example.com/certs";
790	  date=1511478660; expires=1511824260

792	   "https://example.com/resource.validity.1511157180" could also expand
793	   the set of signatures if its "signatures" array contained more than 2
794	   elements.

796	3.7.  The Accept-Signature header

798	   "Signature" header fields cost on the order of 300 bytes for ECDSA
799	   signatures, so servers might prefer to avoid sending them to clients
800	   that don't intend to use them.  A client can send the "Accept-
801	   Signature" header field to indicate that it does intend to take
802	   advantage of any available signatures and to indicate what kinds of
803	   signatures it supports.

805	   When a server receives an "Accept-Signature" header field in a client
806	   request, it SHOULD reply with any available "Signature" header fields
807	   for its response that the "Accept-Signature" header field indicates
808	   the client supports.  However, if the "Accept-Signature" value
809	   violates a requirement in this section, the server MUST behave as if
810	   it hadn't received any "Accept-Signature" header at all.

812	   The "Accept-Signature" header field is a Structured Header as defined
813	   by [I-D.ietf-httpbis-header-structure].  Its value MUST be a list
814	   (Section 4.8 of [I-D.ietf-httpbis-header-structure]) of parameterised
815	   labels (Section 4.4 of [I-D.ietf-httpbis-header-structure]).  The
816	   order of labels in the "Accept-Signature" list is not significant.
817	   Labels, ignoring any initial "-" character, MUST NOT be duplicated.

819	   Each label in the "Accept-Signature" header field's value indicates
820	   that a feature of the "Signature" header field (Section 3.1) is
821	   supported.  If the label begins with a "-" character, it instead
822	   indicates that the feature named by the rest of the label is not
823	   supported.  Unknown labels and parameters MUST be ignored because new
824	   labels and new parameters on existing labels may be defined by future
825	   specifications.

827	3.7.1.  Integrity labels

829	   Labels starting with "digest/" indicate that the client supports the
830	   "Digest" header field ([RFC3230]) with the digest-algorithm from the
831	   https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml [7]
832	   registry named in lower-case by the rest of the label.  For example,
833	   "digest/sha-512" indicates support for the SHA-512 digest algorithm,
834	   and "-digest/sha-256" indicates non-support for the SHA-256 digest
835	   algorithm.

837	   Labels starting with "mi/" indicate that the client supports the "MI"
838	   header field ([I-D.thomson-http-mice]) with the parameter from the
839	   HTTP MI Parameter Registry registry named in lower-case by the rest
840	   of the label.  For example, "mi/mi-blake2" indicates support for
841	   Merkle integrity with the as-yet-unspecified mi-blake2 parameter, and
842	   "-digest/mi-sha256" indicates non-support for Merkle integrity with
843	   the mi-sha256 content encoding.

845	   If the "Accept-Signature" header field is present, servers SHOULD
846	   assume support for "digest/sha-256" and "mi/mi-sha256" unless the
847	   header field states otherwise.

849	3.7.2.  Key type labels

851	   Labels starting with "rsa/" indicate that the client supports
852	   certificates holding RSA public keys with a number of bits indicated
853	   by the digits after the "/".

855	   Labels starting with "ecdsa/" indicate that the client supports
856	   certificates holding ECDSA public keys on the curve named in lower-
857	   case by the rest of the label.

859	   If the "Accept-Signature" header field is present, servers SHOULD
860	   assume support for "rsa/2048", "ecdsa/secp256r1", and "ecdsa/
861	   secp384r1" unless the header field states otherwise.

863	3.7.3.  Key value labels

865	   The "ed25519key" label has parameters indicating the public keys that
866	   will be used to validate the returned signature.  Each parameter's
867	   name is re-interpreted as binary content (Section 4.5 of
868	   [I-D.ietf-httpbis-header-structure]) encoding a prefix of the public
869	   key.  For example, if the client will validate signatures using the
870	   public key whose base64 encoding is
871	   "11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo", valid "Accept-
872	   Signature" header fields include:

874	Accept-Signature: ..., ed25519key; *11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo
875	Accept-Signature: ..., ed25519key; *11qYAYKxCrfVS/7TyWQHOg
876	Accept-Signature: ..., ed25519key; *11qYAQ
877	Accept-Signature: ..., ed25519key; *

879	   but not

881	   Accept-Signature: ..., ed25519key; *11qYA

883	   because 5 bytes isn't a valid length for encoded base64, and not

885	   Accept-Signature: ..., ed25519key; 11qYAQ

887	   because it doesn't start with the "*" that indicates binary content.

889	   Note that "ed25519key; *" is an empty prefix, which matches all
890	   public keys, so it's useful in subresource integrity (Appendix A.3)
891	   cases like "<link rel=preload as=script href="...">" where the public
892	   key isn't known until the matching "<script src="..."
893	   integrity="...">" tag.

895	3.7.4.  Examples

897	   Accept-Signature: mi/mi-sha256

899	   states that the client will accept signatures with payload integrity
900	   assured by the "MI" header and "mi-sha256" content encoding and
901	   implies that the client will accept integrity assured by the "Digest:
902	   SHA-256" header and signatures from 2048-bit RSA keys and ECDSA keys
903	   on the secp256r1 and secp384r1 curves.

905	   Accept-Signature: -rsa/2048, rsa/4096

907	   states that the client will accept 4096-bit RSA keys but not 2048-bit
908	   RSA keys, and implies that the client will accept ECDSA keys on the
909	   secp256r1 and secp384r1 curves and payload integrity assured with the
910	   "MI: mi-sha256" and "Digest: SHA-256" header fields.

912	3.7.5.  Open Questions

914	   Is an "Accept-Signature" header useful enough to pay for itself?  If
915	   clients wind up sending it on most requests, that may cost more than
916	   the cost of sending "Signature"s unconditionally.  On the other hand,
917	   it gives servers an indication of which kinds of signatures are
918	   supported, which can help us upgrade the ecosystem in the future.

920	   Is "Accept-Signature" the right spelling, or do we want to imitate
921	   "Want-Digest" (Section 4.3.1 of [RFC3230]) instead?

923	   Do I have the right structure for the labels indicating feature
924	   support?

926	4.  Cross-origin trust

928	   To determine whether to trust a cross-origin exchange, the client
929	   takes a "Signature" header field (Section 3.1) and the "exchange".
930	   The client MUST parse the "Signature" header into a list of
931	   signatures according to the instructions in Section 3.5, and run the
932	   following algorithm for each signature, stopping at the first one
933	   that returns "valid".  If any signature returns "valid", return
934	   "valid".  Otherwise, return "invalid".

936	   1.  If the signature's "validityUrl" parameter (Paragraph 6) is not
937	       same-origin [8] with "exchange"'s effective request URI
938	       (Section 5.5 of [RFC7230]), return "invalid".

940	   2.  Use Section 3.5 to determine the signature's validity for
941	       "exchange", getting "certificate-chain" back.  If this returned
942	       "invalid" or didn't return a certificate chain, return "invalid".

944	   3.  If "exchange"'s request method is not safe (Section 4.2.1 of
945	       [RFC7231]) or not cacheable (Section 4.2.3 of [RFC7231]), return
946	       "invalid".

948	   4.  If "exchange"'s headers contain a stateful header field, as
949	       defined in Section 4.1, return "invalid".

951	   5.  Let "authority" be the host component of "exchange"'s effective
952	       request URI.

954	   6.  Validate the "certificate-chain" using the following substeps.
955	       If any of them fail, re-run Section 3.5 once over the signature
956	       with the "forceFetch" flag set, and restart from step 2.  If a
957	       substep fails again, return "invalid".

959	       1.  Use "certificate-chain" to validate that its first entry,
960	           "main-certificate" is trusted as "authority"'s server
961	           certificate ([RFC5280] and other undocumented conventions).
962	           Let "path" be the path that was used from the "main-
963	           certificate" to a trusted root, including the "main-
964	           certificate" but excluding the root.

966	       2.  Validate that "main-certificate" has the CanSignHttpExchanges
967	           extension (Section 4.2).

969	       3.  Validate that "main-certificate" has an "ocsp" property
970	           (Section 3.3) with a valid OCSP response whose lifetime
971	           ("nextUpdate - thisUpdate") is less than 7 days ([RFC6960]).
972	           Note that this does not check for revocation of intermediate
973	           certificates, and clients SHOULD implement another mechanism
974	           for that.

976	       4.  Validate that "main-certificate" has an "sct" property
977	           (Section 3.3) containing valid SCTs from trusted logs.
978	           ([RFC6962])

980	   7.  Return "valid".

982	4.1.  Stateful header fields

984	   As described in Section 6.1, a publisher can cause problems if they
985	   sign an exchange that includes private information.  There's no way
986	   for a client to be sure an exchange does or does not include private
987	   information, but header fields that store or convey stored state in
988	   the client are a good sign.

990	   A stateful request header field informs the server of per-client
991	   state.  These include but are not limited to:

993	   o  "Authorization", [RFC7235]

995	   o  "Cookie", [RFC6265]

997	   o  "Cookie2", [RFC2965]

999	   o  "Proxy-Authorization", [RFC7235]

1001	   o  "Sec-WebSocket-Key", [RFC6455]

1003	   A stateful response header field modifies state, including
1004	   authentication status, in the client.  The HTTP cache is not
1005	   considered part of this state.  These include but are not limited to:

1007	   o  "Authentication-Control", [RFC8053]

1009	   o  "Authentication-Info", [RFC7615]

1011	   o  "Optional-WWW-Authenticate", [RFC8053]

1013	   o  "Proxy-Authenticate", [RFC7235]

1015	   o  "Proxy-Authentication-Info", [RFC7615]

1017	   o  "Sec-WebSocket-Accept", [RFC6455]

1019	   o  "Set-Cookie", [RFC6265]

1021	   o  "Set-Cookie2", [RFC2965]

1023	   o  "SetProfile", [W3C.NOTE-OPS-OverHTTP]

1025	   o  "WWW-Authenticate", [RFC7235]

1027	4.2.  Certificate Requirements

1029	   We define a new X.509 extension, CanSignHttpExchanges to be used in
1030	   the certificate when the certificate permits the usage of signed
1031	   exchanges.  When this extension is not present the client MUST NOT
1032	   accept a signature from the certificate as proof that a signed
1033	   exchange is authoritative for a domain covered by the certificate.

1035	   When it is present, the client MUST follow the validation procedure
1036	   in Section 4.

1038	      id-ce-canSignHttpExchanges OBJECT IDENTIFIER ::= { TBD }

1040	      CanSignHttpExchanges ::= BIT STRING { allowed (0) }

1042	   Leaf certificates without this extension need to be revoked if the
1043	   private key is exposed to an unauthorized entity, but they generally
1044	   don't need to be revoked if a signing oracle is exposed and then
1045	   removed.

1047	   CA certificates, by contrast, need to be revoked if an unauthorized
1048	   entity is able to make even one unauthorized signature.

1050	   Certificates with this extension MUST be revoked if an unauthorized
1051	   entity is able to make even one unauthorized signature.

1053	   Conforming CAs MUST mark this extension as critical, and clients MUST
1054	   NOT accept certificates with this extension in TLS connections
1055	   (Section 4.4.2.2 of [I-D.ietf-tls-tls13]).  This prevents accidental
1056	   signing oracles exposed by TLS servers from allowing package signing
1057	   (e.g.  [DROWN] and [ROBOT]).

1059	5.  Transferring a signed exchange

1061	   A signed exchange can be transferred in several ways, of which three
1062	   are described here.

1064	5.1.  Same-origin response

1066	   The signature for a signed exchange can be included in a normal HTTP
1067	   response.  Because different clients send different request header
1068	   fields, and intermediate servers add response header fields, it can
1069	   be impossible to have a signature for the exact request and response
1070	   that the client sees.  Therefore, when a client validates the
1071	   "Signature" header field for an exchange represented as a normal HTTP
1072	   request/response pair, it MUST pass only the subset of header fields
1073	   defined by Section 5.1.1 to the validation procedure (Section 3.5).

1075	   If the client relies on signature validity for any aspect of its
1076	   behavior, it MUST ignore any header fields that it didn't pass to the
1077	   validation procedure.

1079	5.1.1.  Significant headers for a same-origin response

1081	   The significant headers of an exchange represented as a normal HTTP
1082	   request/response pair (Section 2.1 of [RFC7230] or Section 8.1 of
1083	   [RFC7540]) are:

1085	   o  The method (Section 4 of [RFC7231]) and effective request URI
1086	      (Section 5.5 of [RFC7230]) of the request.

1088	   o  The response status code (Section 6 of [RFC7231]) and the response
1089	      header fields whose names are listed in that exchange's "Signed-
1090	      Headers" header field (Section 5.1.2), in the order they appear in
1091	      that header field.  If a response header field name from "Signed-
1092	      Headers" does not appear in the exchange's response header fields,
1093	      the exchange has no significant headers.

1095	   If the exchange's "Signed-Headers" header field is not present,
1096	   doesn't parse as a Structured Header
1097	   ([I-D.ietf-httpbis-header-structure]) or doesn't follow the
1098	   constraints on its value described in Section 5.1.2, the exchange has
1099	   no significant headers.

1101	5.1.1.1.  Open Questions

1103	   Do the significant headers of an exchange need to include the
1104	   "Signed-Headers" header field itself?

1106	5.1.2.  The Signed-Headers Header

1108	   The "Signed-Headers" header field identifies an ordered list of
1109	   response header fields to include in a signature.  The request URL
1110	   and response status are included unconditionally.  This allows a TLS-
1111	   terminating intermediate to reorder headers without breaking the
1112	   signature.  This _can_ also allow the intermediate to add headers
1113	   that will be ignored by some higher-level protocols, but Section 3.5
1114	   provides a hook to let other higher-level protocols reject such
1115	   insecure headers.

1117	   This header field appears once instead of being incorporated into the
1118	   signatures' parameters because the signed header fields need to be
1119	   consistent across all signatures of an exchange, to avoid forcing
1120	   higher-level protocols to merge the header field lists of valid
1121	   signatures.

1123	   See Appendix B.2 for a discussion of why only the URL from the
1124	   request is included and not other request headers.

1126	   "Signed-Headers" is a Structured Header as defined by
1127	   [I-D.ietf-httpbis-header-structure].  Its value MUST be a list
1128	   (Section 4.8 of [I-D.ietf-httpbis-header-structure]) of lowercase
1129	   strings (Section 4.2 of [I-D.ietf-httpbis-header-structure]) naming
1130	   HTTP response header fields.  Pseudo-header field names
1131	   (Section 8.1.2.1 of [RFC7540]) MUST NOT appear in this list.

1133	   Higher-level protocols SHOULD place requirements on the minimum set
1134	   of headers to include in the "Signed-Headers" header field.

1136	5.2.  HTTP/2 extension for cross-origin Server Push

1138	   To allow servers to Server-Push (Section 8.2 of [RFC7540]) signed
1139	   exchanges (Section 3) signed by an authority for which the server is
1140	   not authoritative (Section 9.1 of [RFC7230]), this section defines an
1141	   HTTP/2 extension.

1143	5.2.1.  Indicating support for cross-origin Server Push

1145	   Clients that might accept signed Server Pushes with an authority for
1146	   which the server is not authoritative indicate this using the HTTP/2
1147	   SETTINGS parameter ENABLE_CROSS_ORIGIN_PUSH (0xSETTING-TBD).

1149	   An ENABLE_CROSS_ORIGIN_PUSH value of 0 indicates that the client does
1150	   not support cross-origin Push.  A value of 1 indicates that the
1151	   client does support cross-origin Push.

1153	   A client MUST NOT send a ENABLE_CROSS_ORIGIN_PUSH setting with a
1154	   value other than 0 or 1 or a value of 0 after previously sending a
1155	   value of 1.  If a server receives a value that violates these rules,
1156	   it MUST treat it as a connection error (Section 5.4.1 of [RFC7540])
1157	   of type PROTOCOL_ERROR.

1159	   The use of a SETTINGS parameter to opt-in to an otherwise
1160	   incompatible protocol change is a use of "Extending HTTP/2" defined
1161	   by Section 5.5 of [RFC7540].  If a server were to send a cross-origin
1162	   Push without first receiving a ENABLE_CROSS_ORIGIN_PUSH setting with
1163	   the value of 1 it would be a protocol violation.

1165	5.2.2.  NO_TRUSTED_EXCHANGE_SIGNATURE error code

1167	   The signatures on a Pushed cross-origin exchange may be untrusted for
1168	   several reasons, for example that the certificate could not be
1169	   fetched, that the certificate does not chain to a trusted root, that
1170	   the signature itself doesn't validate, that the signature is expired,
1171	   etc.  This draft conflates all of these possible failures into one
1172	   error code, NO_TRUSTED_EXCHANGE_SIGNATURE (0xERROR-TBD).

1174	5.2.2.1.  Open Questions

1176	   How fine-grained should this specification's error codes be?

1178	5.2.3.  Validating a cross-origin Push

1180	   If the client has set the ENABLE_CROSS_ORIGIN_PUSH setting to 1, the
1181	   server MAY Push a signed exchange for which it is not authoritative,
1182	   and the client MUST NOT treat a PUSH_PROMISE for which the server is
1183	   not authoritative as a stream error (Section 5.4.2 of [RFC7540]) of
1184	   type PROTOCOL_ERROR, as described in Section 8.2 of [RFC7540].

1186	   Instead, the client MUST validate such a PUSH_PROMISE and its
1187	   response by taking the "Signature" header field from the response,
1188	   and the exchange consisting of the PUSH_PROMISE and the response
1189	   without that "Signature" header field, and passing them to the
1190	   algorithm in Section 4.  If this returns "invalid", the client MUST
1191	   treat the response as a stream error (Section 5.4.2 of [RFC7540]) of
1192	   type NO_TRUSTED_EXCHANGE_SIGNATURE.  Otherwise, the client MUST treat
1193	   the pushed response as if the server were authoritative for the
1194	   PUSH_PROMISE's authority.

1196	5.2.3.1.  Open Questions

1198	   Is it right that "validityUrl" is required to be same-origin with the
1199	   exchange?  This allows the mitigation against downgrades in
1200	   Section 6.3, but prohibits intermediates from providing a cache of
1201	   the validity information.  We could do both with a list of URLs.

1203	5.3.  application/http-exchange+cbor format for HTTP/1 compatibility

1205	   To allow servers to serve cross-origin responses when either the
1206	   client or the server hasn't implemented HTTP/2 Push (Section 8.2 of
1207	   [RFC7540]) support yet, we define a format that represents an HTTP
1208	   exchange.

1210	   The "application/http-exchange+cbor" content type encodes an HTTP
1211	   exchange, including request metadata and header fields, optionally a
1212	   request body, response header fields and metadata, a payload body,
1213	   and optionally trailer header fields.

1215	   This content type consists of a canonically-serialized (Section 3.4)
1216	   CBOR array containing:

1218	   1.  The text string "htxg" to serve as a file signature, followed by

1220	   2.  Alternating member names encoded as text strings (Section 2.1 of
1221	       [RFC7049]) and member values, with each value consisting of a
1222	       single CBOR item with a type and meaning determined by the member
1223	       name.

1225	   This specification defines the following member names with their
1226	   associated values:

1228	   "request"  A map from request header field names to values, encoded
1229	      as byte strings ([RFC7049], section 2.1).  The request header
1230	      fields MUST include two pseudo-header fields (Section 8.1.2.1 of
1231	      [RFC7540]):

1233	      *  "':method'": The method of the request (Section 4 of
1234	         [RFC7231]).

1236	      *  "':url'": The effective request URI of the request (Section 5.5
1237	         of [RFC7230]).

1239	   "request payload"  A byte string ([RFC7049], section 2.1) containing
1240	      the request payload body (Section 3.3 of [RFC7230]).

1242	   "response"  A map from response header field names to values, encoded
1243	      as byte strings ([RFC7049], section 2.1).  The response header
1244	      fields MUST include one pseudo-header field (Section 8.1.2.1 of
1245	      [RFC7540]):

1247	      *  "':status'": The response's 3-digit status code (Section 6 of
1248	         [RFC7231]]).

1250	   "payload"  A byte string ([RFC7049], section 2.1) containing the
1251	      response payload body (Section 3.3 of [RFC7230]).

1253	   "trailer"  A map of trailer header field names to values, encoded as
1254	      byte strings (Section 2.1 of [RFC7049]).

1256	   A parser MAY return incremental information while parsing
1257	   "application/http-exchange+cbor" content.

1259	   Members "request", "response", and "payload" MUST be present.  If one
1260	   is missing, the parser MUST stop and report an error.

1262	   The member names MUST appear in the order:

1264	   1.  "request"

1266	   2.  "request payload"

1268	   3.  "response"
1269	   4.  "payload"

1271	   5.  "trailer"

1273	   If a member name is not a text string, appears out of order, or is
1274	   followed by a value not matching its description above, the parser
1275	   MUST stop and report an error.

1277	   If the parser encounters an unknown member name, it MUST skip the
1278	   following item and resume parsing at the next member name.

1280	5.3.1.  Example

1282	   An example "application/http-exchange+cbor" file representing a
1283	   possible exchange with https://example.com/ [9] follows, in the
1284	   extended diagnostic format defined in Appendix G of
1285	   [I-D.ietf-cbor-cddl]:

1287	   [
1288	     "htxg",
1289	     "request",
1290	     {
1291	       ':method': 'GET',
1292	       ':url': 'https://example.com/',
1293	       'accept', '*/*'
1294	     },
1295	     "response",
1296	     {
1297	       ':status': '200',
1298	       'content-type': 'text/html'
1299	     },
1300	     "payload",
1301	     '<!doctype html>\r\n<html>...'
1302	   ]

1304	5.3.2.  Open Questions

1306	   Should "application/http-exchange+cbor" support request payloads and
1307	   trailers, or only the aspects needed for signed exchanges?

1309	   Are the mime type, extension, and magic number right?

1311	6.  Security considerations
1312	6.1.  Over-signing

1314	   If a publisher blindly signs all responses as their origin, they can
1315	   cause at least two kinds of problems, described below.  To avoid
1316	   this, publishers SHOULD design their systems to opt particular public
1317	   content that doesn't depend on authentication status into signatures
1318	   instead of signing by default.

1320	   Signing systems SHOULD also incorporate the following mitigations to
1321	   reduce the risk that private responses are signed:

1323	   1.  Strip the "Cookie" request header field and other identifying
1324	       information like client authentication and TLS session IDs from
1325	       requests whose exchange is destined to be signed, before
1326	       forwarding the request to a backend.

1328	   2.  Only sign exchanges where the response includes a "Cache-Control:
1329	       public" header.  Clients are not required to fail signature-
1330	       checking for exchanges that omit this "Cache-Control" response
1331	       header field to reduce the risk that naive signing systems
1332	       blindly add it.

1334	6.1.1.  Session fixation

1336	   Blind signing can sign responses that create session cookies or
1337	   otherwise change state on the client to identify a particular
1338	   session.  This breaks certain kinds of CSRF defense and can allow an
1339	   attacker to force a user into the attacker's account, where the user
1340	   might unintentionally save private information, like credit card
1341	   numbers or addresses.

1343	   This specification defends against cookie-based attacks by blocking
1344	   the "Set-Cookie" response header, but it cannot prevent Javascript or
1345	   other response content from changing state.

1347	6.1.2.  Misleading content

1349	   If a site signs private information, an attacker might set up their
1350	   own account to show particular private information, forward that
1351	   signed information to a victim, and use that victim's confusion in a
1352	   more sophisticated attack.

1354	   Stripping authentication information from requests before sending
1355	   them to backends is likely to prevent the backend from showing
1356	   attacker-specific information in the signed response.  It does not
1357	   prevent the attacker from showing their victim a signed-out page when
1358	   the victim is actually signed in, but while this is still misleading,
1359	   it seems less likely to be useful to the attacker.

1361	6.2.  Off-path attackers

1363	   Relaxing the requirement to consult DNS when determining authority
1364	   for an origin means that an attacker who possesses a valid
1365	   certificate no longer needs to be on-path to redirect traffic to
1366	   them; instead of modifying DNS, they need only convince the user to
1367	   visit another Web site in order to serve responses signed as the
1368	   target.  This consideration and mitigations for it are shared by the
1369	   combination of [I-D.ietf-httpbis-origin-frame] and
1370	   [I-D.ietf-httpbis-http2-secondary-certs].

1372	6.3.  Downgrades

1374	   Signing a bad response can affect more users than simply serving a
1375	   bad response, since a served response will only affect users who make
1376	   a request while the bad version is live, while an attacker can
1377	   forward a signed response until its signature expires.  Authors
1378	   should consider shorter signature expiration times than they use for
1379	   cache expiration times.

1381	   Clients MAY also check the "validityUrl" (Paragraph 6) of an exchange
1382	   more often than the signature's expiration would require.  Doing so
1383	   for an exchange with an HTTPS request URI provides a TLS guarantee
1384	   that the exchange isn't out of date (as long as Section 5.2.3.1 is
1385	   resolved to keep the same-origin requirement).

1387	6.4.  Signing oracles are permanent

1389	   An attacker with temporary access to a signing oracle can sign "still
1390	   valid" assertions with arbitrary timestamps and expiration times.  As
1391	   a result, when a signing oracle is removed, the keys it provided
1392	   access to MUST be revoked so that, even if the attacker used them to
1393	   sign future-dated exchange validity assertions, the key's OCSP
1394	   assertion will expire, causing the exchange as a whole to become
1395	   untrusted.

1397	6.5.  Unsigned headers

1399	   The use of a single "Signed-Headers" header field prevents us from
1400	   signing aspects of the request other than its effective request URI
1401	   (Section 5.5 of [RFC7230]).  For example, if an author signs both
1402	   "Content-Encoding: br" and "Content-Encoding: gzip" variants of a
1403	   response, what's the impact if an attacker serves the brotli one for
1404	   a request with "Accept-Encoding: gzip"?

1406	   The simple form of "Signed-Headers" also prevents us from signing
1407	   less than the full request URL.  The SRI use case (Appendix A.3) may
1408	   benefit from being able to leave the authority less constrained.

1410	   Section 3.5 can succeed when some delivered headers aren't included
1411	   in the signed set.  This accommodates current TLS-terminating
1412	   intermediates and may be useful for SRI (Appendix A.3), but is risky
1413	   for trusting cross-origin responses (Appendix A.1, Appendix A.2, and
1414	   Appendix A.6).  Section 5.2 requires all headers to be included in
1415	   the signature before trusting cross-origin pushed resources, at Ryan
1416	   Sleevi's recommendation.

1418	6.6.  application/http-exchange+cbor

1420	   Clients MUST NOT trust an effective request URI claimed by an
1421	   "application/http-exchange+cbor" resource (Section 5.3) without
1422	   either ensuring the resource was transferred from a server that was
1423	   authoritative (Section 9.1 of [RFC7230]) for that URI's origin, or
1424	   passing the "Signature" response header field from the exchange
1425	   stored in the resource, and that exchange without its "Signature"
1426	   response header field, to the procedure in Section 4, and getting
1427	   "valid" back.

1429	7.  Privacy considerations

1431	   Normally, when a client fetches "https://o1.com/resource.js",
1432	   "o1.com" learns that the client is interested in the resource.  If
1433	   "o1.com" signs "resource.js", "o2.com" serves it as "https://o2.com/
1434	   o1resource.js", and the client fetches it from there, then "o2.com"
1435	   learns that the client is interested, and if the client executes the
1436	   Javascript, that could also report the client's interest back to
1437	   "o1.com".

1439	   Often, "o2.com" already knew about the client's interest, because
1440	   it's the entity that directed the client to "o1resource.js", but
1441	   there may be cases where this leaks extra information.

1443	   For non-executable resource types, a signed response can improve the
1444	   privacy situation by hiding the client's interest from the original
1445	   author.

1447	   To prevent network operators other than "o1.com" or "o2.com" from
1448	   learning which exchanges were read, clients SHOULD only load
1449	   exchanges fetched over a transport that's protected from
1450	   eavesdroppers.  This can be difficult to determine when the exchange
1451	   is being loaded from local disk, but when the client itself requested
1452	   the exchange over a network it SHOULD require TLS
1453	   ([I-D.ietf-tls-tls13]) or a successor transport layer, and MUST NOT
1454	   accept exchanges transferred over plain HTTP without TLS.

1456	8.  IANA considerations

1458	   TODO: possibly register the validityUrl format.

1460	8.1.  Signature Header Field Registration

1462	   This section registers the "Signature" header field in the "Permanent
1463	   Message Header Field Names" registry ([RFC3864]).

1465	   Header field name: "Signature"

1467	   Applicable protocol: http

1469	   Status: standard

1471	   Author/Change controller: IETF

1473	   Specification document(s): Section 3.1 of this document

1475	8.2.  HTTP/2 Settings

1477	   This section establishes an entry for the HTTP/2 Settings Registry
1478	   that was established by Section 11.3 of [RFC7540]

1480	   Name: ENABLE_CROSS_ORIGIN_PUSH

1482	   Code: 0xSETTING-TBD

1484	   Initial Value: 0

1486	   Specification: This document

1488	8.3.  HTTP/2 Error code

1490	   This section establishes an entry for the HTTP/2 Error Code Registry
1491	   that was established by Section 11.4 of [RFC7540]

1493	   Name: NO_TRUSTED_EXCHANGE_SIGNATURE

1495	   Code: 0xERROR-TBD

1497	   Description: The client does not trust the signature for a cross-
1498	   origin Pushed signed exchange.

1500	   Specification: This document

1502	8.4.  Internet Media Type application/http-exchange+cbor

1504	   Type name: application

1506	   Subtype name: http-exchange+cbor

1508	   Required parameters: N/A

1510	   Optional parameters: N/A

1512	   Encoding considerations: binary

1514	   Security considerations: see Section 6.6

1516	   Interoperability considerations: N/A

1518	   Published specification: This specification (see Section 5.3).

1520	   Applications that use this media type: N/A

1522	   Fragment identifier considerations: N/A

1524	   Additional information:

1526	   Deprecated alias names for this type: N/A

1528	   Magic number(s): 8? 64 68 74 78 67

1530	   File extension(s): .htxg

1532	   Macintosh file type code(s): N/A

1534	   Person and email address to contact for further information: See
1535	   Authors' Addresses section.

1537	   Intended usage: COMMON

1539	   Restrictions on usage: N/A

1541	   Author: See Authors' Addresses section.

1543	   Change controller: IESG

1545	8.5.  Internet Media Type application/cert-chain+cbor

1547	   Type name: application

1549	   Subtype name: cert-chain+cbor
1550	   Required parameters: N/A

1552	   Optional parameters: N/A

1554	   Encoding considerations: binary

1556	   Security considerations: N/A

1558	   Interoperability considerations: N/A

1560	   Published specification: This specification (see Section 3.3).

1562	   Applications that use this media type: N/A

1564	   Fragment identifier considerations: N/A

1566	   Additional information:

1568	   Deprecated alias names for this type: N/A

1570	   Magic number(s): 1*9(??) 67 F0 9F 93 9C E2 9B 93

1572	   File extension(s): N/A

1574	   Macintosh file type code(s): N/A

1576	   Person and email address to contact for further information: See
1577	   Authors' Addresses section.

1579	   Intended usage: COMMON

1581	   Restrictions on usage: N/A

1583	   Author: See Authors' Addresses section.

1585	   Change controller: IESG

1587	9.  References

1589	9.1.  Normative References

1591	   [FETCH]    WHATWG, "Fetch", March 2018,
1592	              <https://fetch.spec.whatwg.org/>.

1594	   [HTML]     WHATWG, "HTML", March 2018,
1595	              <https://html.spec.whatwg.org/multipage>.

1597	   [I-D.ietf-cbor-cddl]
1598	              Birkholz, H., Vigano, C., and C. Bormann, "Concise data
1599	              definition language (CDDL): a notational convention to
1600	              express CBOR data structures", draft-ietf-cbor-cddl-02
1601	              (work in progress), February 2018.

1603	   [I-D.ietf-httpbis-header-structure]
1604	              Nottingham, M. and P. Kamp, "Structured Headers for HTTP",
1605	              draft-ietf-httpbis-header-structure-04 (work in progress),
1606	              March 2018.

1608	   [I-D.ietf-tls-tls13]
1609	              Rescorla, E., "The Transport Layer Security (TLS) Protocol
1610	              Version 1.3", draft-ietf-tls-tls13-26 (work in progress),
1611	              March 2018.

1613	   [I-D.thomson-http-mice]
1614	              Thomson, M., "Merkle Integrity Content Encoding", draft-
1615	              thomson-http-mice-02 (work in progress), October 2016.

1617	   [POSIX]    IEEE and The Open Group, "The Open Group Base
1618	              Specifications Issue 7", name IEEE, value 1003.1-2008,
1619	              2016 Edition, 2016,
1620	              <http://pubs.opengroup.org/onlinepubs/9699919799/
1621	              basedefs/>.

1623	   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
1624	              Requirement Levels", BCP 14, RFC 2119,
1625	              DOI 10.17487/RFC2119, March 1997,
1626	              <https://www.rfc-editor.org/info/rfc2119>.

1628	   [RFC2560]  Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
1629	              Adams, "X.509 Internet Public Key Infrastructure Online
1630	              Certificate Status Protocol - OCSP", RFC 2560,
1631	              DOI 10.17487/RFC2560, June 1999,
1632	              <https://www.rfc-editor.org/info/rfc2560>.

1634	   [RFC3230]  Mogul, J. and A. Van Hoff, "Instance Digests in HTTP",
1635	              RFC 3230, DOI 10.17487/RFC3230, January 2002,
1636	              <https://www.rfc-editor.org/info/rfc3230>.

1638	   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
1639	              Procedures for Message Header Fields", BCP 90, RFC 3864,
1640	              DOI 10.17487/RFC3864, September 2004,
1641	              <https://www.rfc-editor.org/info/rfc3864>.

1643	   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
1644	              Housley, R., and W. Polk, "Internet X.509 Public Key
1645	              Infrastructure Certificate and Certificate Revocation List
1646	              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
1647	              <https://www.rfc-editor.org/info/rfc5280>.

1649	   [RFC6960]  Santesson, S., Myers, M., Ankney, R., Malpani, A.,
1650	              Galperin, S., and C. Adams, "X.509 Internet Public Key
1651	              Infrastructure Online Certificate Status Protocol - OCSP",
1652	              RFC 6960, DOI 10.17487/RFC6960, June 2013,
1653	              <https://www.rfc-editor.org/info/rfc6960>.

1655	   [RFC6962]  Laurie, B., Langley, A., and E. Kasper, "Certificate
1656	              Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
1657	              <https://www.rfc-editor.org/info/rfc6962>.

1659	   [RFC7049]  Bormann, C. and P. Hoffman, "Concise Binary Object
1660	              Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
1661	              October 2013, <https://www.rfc-editor.org/info/rfc7049>.

1663	   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1664	              Protocol (HTTP/1.1): Message Syntax and Routing",
1665	              RFC 7230, DOI 10.17487/RFC7230, June 2014,
1666	              <https://www.rfc-editor.org/info/rfc7230>.

1668	   [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1669	              Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
1670	              DOI 10.17487/RFC7231, June 2014,
1671	              <https://www.rfc-editor.org/info/rfc7231>.

1673	   [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1674	              Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1675	              RFC 7234, DOI 10.17487/RFC7234, June 2014,
1676	              <https://www.rfc-editor.org/info/rfc7234>.

1678	   [RFC7540]  Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
1679	              Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
1680	              DOI 10.17487/RFC7540, May 2015,
1681	              <https://www.rfc-editor.org/info/rfc7540>.

1683	   [RFC8017]  Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
1684	              "PKCS #1: RSA Cryptography Specifications Version 2.2",
1685	              RFC 8017, DOI 10.17487/RFC8017, November 2016,
1686	              <https://www.rfc-editor.org/info/rfc8017>.

1688	   [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
1689	              Signature Algorithm (EdDSA)", RFC 8032,
1690	              DOI 10.17487/RFC8032, January 2017,
1691	              <https://www.rfc-editor.org/info/rfc8032>.

1693	   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1694	              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1695	              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

1697	9.2.  Informative References

1699	   [DROWN]    Aviram, N., Schinzel, S., Somorovsky, J., Heninger, N.,
1700	              Dankel, M., Steube, J., Valenta, L., Adrian, D.,
1701	              Halderman, J., Dukhovni, V., Kaesper, E., Cohney, S.,
1702	              Engels, S., Paar, C., and Y. Shavitt, "The DROWN Attack",
1703	              2016, <https://drownattack.com/>.

1705	   [I-D.burke-content-signature]
1706	              Burke, B., "HTTP Header for digital signatures", draft-
1707	              burke-content-signature-00 (work in progress), March 2011.

1709	   [I-D.cavage-http-signatures]
1710	              Cavage, M. and M. Sporny, "Signing HTTP Messages", draft-
1711	              cavage-http-signatures-09 (work in progress), November
1712	              2017.

1714	   [I-D.ietf-httpbis-http2-secondary-certs]
1715	              Bishop, M., Sullivan, N., and M. Thomson, "Secondary
1716	              Certificate Authentication in HTTP/2", draft-ietf-httpbis-
1717	              http2-secondary-certs-00 (work in progress), December
1718	              2017.

1720	   [I-D.ietf-httpbis-origin-frame]
1721	              Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame",
1722	              draft-ietf-httpbis-origin-frame-06 (work in progress),
1723	              January 2018.

1725	   [I-D.thomson-http-content-signature]
1726	              Thomson, M., "Content-Signature Header Field for HTTP",
1727	              draft-thomson-http-content-signature-00 (work in
1728	              progress), July 2015.

1730	   [I-D.yasskin-webpackage-use-cases]
1731	              Yasskin, J., "Use Cases and Requirements for Web
1732	              Packages", draft-yasskin-webpackage-use-cases-00 (work in
1733	              progress), August 2017.

1735	   [RFC2965]  Kristol, D. and L. Montulli, "HTTP State Management
1736	              Mechanism", RFC 2965, DOI 10.17487/RFC2965, October 2000,
1737	              <https://www.rfc-editor.org/info/rfc2965>.

1739	   [RFC6066]  Eastlake 3rd, D., "Transport Layer Security (TLS)
1740	              Extensions: Extension Definitions", RFC 6066,
1741	              DOI 10.17487/RFC6066, January 2011,
1742	              <https://www.rfc-editor.org/info/rfc6066>.

1744	   [RFC6265]  Barth, A., "HTTP State Management Mechanism", RFC 6265,
1745	              DOI 10.17487/RFC6265, April 2011,
1746	              <https://www.rfc-editor.org/info/rfc6265>.

1748	   [RFC6454]  Barth, A., "The Web Origin Concept", RFC 6454,
1749	              DOI 10.17487/RFC6454, December 2011,
1750	              <https://www.rfc-editor.org/info/rfc6454>.

1752	   [RFC6455]  Fette, I. and A. Melnikov, "The WebSocket Protocol",
1753	              RFC 6455, DOI 10.17487/RFC6455, December 2011,
1754	              <https://www.rfc-editor.org/info/rfc6455>.

1756	   [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1757	              Protocol (HTTP/1.1): Authentication", RFC 7235,
1758	              DOI 10.17487/RFC7235, June 2014,
1759	              <https://www.rfc-editor.org/info/rfc7235>.

1761	   [RFC7615]  Reschke, J., "HTTP Authentication-Info and Proxy-
1762	              Authentication-Info Response Header Fields", RFC 7615,
1763	              DOI 10.17487/RFC7615, September 2015,
1764	              <https://www.rfc-editor.org/info/rfc7615>.

1766	   [RFC8053]  Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi,
1767	              T., and Y. Ioku, "HTTP Authentication Extensions for
1768	              Interactive Clients", RFC 8053, DOI 10.17487/RFC8053,
1769	              January 2017, <https://www.rfc-editor.org/info/rfc8053>.

1771	   [ROBOT]    Boeck, H., Somorovsky, J., and C. Young, "The ROBOT
1772	              Attack", 2017, <https://robotattack.org/>.

1774	   [SRI]      Akhawe, D., Braun, F., Marier, F., and J. Weinberger,
1775	              "Subresource Integrity", World Wide Web Consortium
1776	              Recommendation REC-SRI-20160623, June 2016,
1777	              <http://www.w3.org/TR/2016/REC-SRI-20160623>.

1779	   [W3C.NOTE-OPS-OverHTTP]
1780	              Hensley, P., Metral, M., Shardanand, U., Converse, D., and
1781	              M. Myers, "Implementation of OPS Over HTTP", W3C NOTE
1782	              NOTE-OPS-OverHTTP, June 1997.

1784	9.3.  URIs

1786	   [1] https://lists.w3.org/Archives/Public/ietf-http-wg/

1788	   [2] https://github.com/WICG/webpackage

1790	   [3] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/
1791	       V1_chap04.html#tag_04_16

1793	   [4] https://url.spec.whatwg.org/#valid-url-string

1795	   [5] https://url.spec.whatwg.org/#valid-url-string

1797	   [6] https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml

1799	   [7] https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml

1801	   [8] https://html.spec.whatwg.org/multipage/origin.html#same-origin

1803	   [9] https://example.com/

1805	   [10] https://calendar.perfplanet.com/2013/big-bad-preloader/

1807	   [11] https://github.com/mikewest/signature-based-sri

1809	   [12] https://github.com/mikewest/signature-based-sri/issues/5

1811	   [13] https://www.apple.com/ios/app-store/

1813	   [14] https://play.google.com/store

1815	   [15] https://github.com/WICG/webpackage

1817	   [16] https://tools.ietf.org/html/rfc7540#section-8.2

1819	   [17] https://www.imperialviolet.org/2012/02/05/crlsets.html

1821	   [18] https://tlswg.github.io/tls13-spec/draft-ietf-tls-
1822	        tls13.html#ocsp-and-sct

1824	Appendix A.  Use cases

1826	A.1.  PUSHed subresources

1828	   To reduce round trips, a server might use HTTP/2 Push (Section 8.2 of
1829	   [RFC7540]) to inject a subresource from another server into the
1830	   client's cache.  If anything about the subresource is expired or
1831	   can't be verified, the client would fetch it from the original
1832	   server.

1834	   For example, if "https://example.com/index.html" includes

1836	   <script src="https://jquery.com/jquery-1.2.3.min.js">

1838	   Then to avoid the need to look up and connect to "jquery.com" in the
1839	   critical path, "example.com" might push that resource signed by
1840	   "jquery.com".

1842	A.2.  Explicit use of a content distributor for subresources

1844	   In order to speed up loading but still maintain control over its
1845	   content, an HTML page in a particular origin "O.com" could tell
1846	   clients to load its subresources from an intermediate content
1847	   distributor that's not authoritative, but require that those
1848	   resources be signed by "O.com" so that the distributor couldn't
1849	   modify the resources.  This is more constrained than the common CDN
1850	   case where "O.com" has a CNAME granting the CDN the right to serve
1851	   arbitrary content as "O.com".

1853	   <img logicalsrc="https://O.com/img.png"
1854	        physicalsrc="https://distributor.com/O.com/img.png">

1856	   To make it easier to configure the right distributor for a given
1857	   request, computation of the "physicalsrc" could be encapsulated in a
1858	   custom element:

1860	   <dist-img src="https://O.com/img.png"></dist-img>

1862	   where the "<dist-img>" implementation generates an appropriate
1863	   "<img>" based on, for example, a "<meta name="dist-base">" tag
1864	   elsewhere in the page.  However, this has the downside that the
1865	   preloader [10] can no longer see the physical source to download it.
1866	   The resulting delay might cancel out the benefit of using a
1867	   distributor.

1869	   This could be used for some of the same purposes as SRI
1870	   (Appendix A.3).

1872	   To implement this with the current proposal, the distributor would
1873	   respond to the physical request to "https://distributor.com/O.com/
1874	   img.png" with first a signed PUSH_PROMISE for "https://O.com/img.png"
1875	   and then a redirect to "https://O.com/img.png".

1877	A.3.  Subresource Integrity

1879	   The W3C WebAppSec group is investigating using signatures [11] in
1880	   [SRI].  They need a way to transmit the signature with the response,
1881	   which this proposal provides.

1883	   Their needs are simpler than most other use cases in that the
1884	   "integrity="ed25519-[public-key]"" attribute and CSP-based ways of
1885	   expressing a public key don't need that key to be wrapped into a
1886	   certificate.

1888	   The "ed25519Key" signature parameter supports this simpler way of
1889	   attaching a key.

1891	   The current proposal for signature-based SRI describes signing only
1892	   the content of a resource, while this specification requires them to
1893	   sign the request URI as well.  This issue is tracked in
1894	   https://github.com/mikewest/signature-based-sri/issues/5 [12].  The
1895	   details of what they need to sign will affect whether and how they
1896	   can use this proposal.

1898	A.4.  Binary Transparency

1900	   So-called "Binary Transparency" may eventually allow users to verify
1901	   that a program they've been delivered is one that's available to the
1902	   public, and not a specially-built version intended to attack just
1903	   them.  Binary transparency systems don't exist yet, but they're
1904	   likely to work similarly to the successful Certificate Transparency
1905	   logs described by [RFC6962].

1907	   Certificate Transparency depends on Signed Certificate Timestamps
1908	   that prove a log contained a particular certificate at a particular
1909	   time.  To build the same thing for Binary Transparency logs
1910	   containing HTTP resources or full websites, we'll need a way to
1911	   provide signatures of those resources, which signed exchanges
1912	   provides.

1914	A.5.  Static Analysis

1916	   Native app stores like the Apple App Store [13] and the Android Play
1917	   Store [14] grant their contents powerful abilities, which they
1918	   attempt to make safe by analyzing the applications before offering
1919	   them to people.  The web has no equivalent way for people to wait to
1920	   run an update of a web application until a trusted authority has
1921	   vouched for it.

1923	   While full application analysis probably needs to wait until the
1924	   authority can sign bundles of exchanges, authorities may be able to
1925	   guarantee certain properties by just checking a top-level resource
1926	   and its [SRI]-constrained sub-resources.

1928	A.6.  Offline websites

1930	   Fully-offline websites can be represented as bundles of signed
1931	   exchanges, although an optimization to reduce the number of signature
1932	   verifications may be needed.  Work on this is in progress in the
1933	   https://github.com/WICG/webpackage [15] repository.

1935	Appendix B.  Requirements

1937	B.1.  Proof of origin

1939	   To verify that a thing came from a particular origin, for use in the
1940	   same context as a TLS connection, we need someone to vouch for the
1941	   signing key with as much verification as the signing keys used in
1942	   TLS.  The obvious way to do this is to re-use the web PKI and CA
1943	   ecosystem.

1945	B.1.1.  Certificate constraints

1947	   If we re-use existing TLS server certificates, we incur the risks
1948	   that:

1950	   1.  TLS server certificates must be accessible from online servers,
1951	       so they're easier to steal or use as signing oracles than an
1952	       offline key.  An exchange's signing key doesn't need to be
1953	       online.

1955	   2.  A server using an origin-trusted key for one purpose (e.g.  TLS)
1956	       might accidentally sign something that looks like an exchange, or
1957	       vice versa.

1959	   These risks are considered too high, so we define a new X.509
1960	   certificate extension in Section 4.2 that requires CAs to issue new
1961	   certificates for this purpose.  We expect at least one low-cost CA to
1962	   be willing to sign certificates with this extension.

1964	B.1.2.  Signature constraints

1966	   In order to prevent an attacker who can convince the server to sign
1967	   some resource from causing those signed bytes to be interpreted as
1968	   something else the new X.509 extension here is forbidden from being
1969	   used in TLS servers.  If Section 4.2 changes to allow re-use in TLS
1970	   servers, we would need to:

1972	   1.  Avoid key types that are used for non-TLS protocols whose output
1973	       could be confused with a signature.  That may be just the
1974	       "rsaEncryption" OID from [RFC8017].

1976	   2.  Use the same format as TLS's signatures, specified in
1977	       Section 4.4.3 of [I-D.ietf-tls-tls13], with a context string
1978	       that's specific to this use.

1980	   The specification also needs to define which signing algorithm to
1981	   use.  It currently specifies that as a function from the key type,
1982	   instead of allowing attacker-controlled data to specify it.

1984	B.1.3.  Retrieving the certificate

1986	   The client needs to be able to find the certificate vouching for the
1987	   signing key, a chain from that certificate to a trusted root, and
1988	   possibly other trust information like SCTs ([RFC6962]).  One approach
1989	   would be to include the certificate and its chain in the signature
1990	   metadata itself, but this wastes bytes when the same certificate is
1991	   used for multiple HTTP responses.  If we decide to put the signature
1992	   in an HTTP header, certificates are also unusually large for that
1993	   context.

1995	   Another option is to pass a URL that the client can fetch to retrieve
1996	   the certificate and chain.  To avoid extra round trips in fetching
1997	   that URL, it could be bundled (Appendix A.6) with the signed content
1998	   or PUSHed (Appendix A.1) with it.  The risks from the
1999	   "client_certificate_url" extension (Section 11.3 of [RFC6066]) don't
2000	   seem to apply here, since an attacker who can get a client to load an
2001	   exchange and fetch the certificates it references, can also get the
2002	   client to perform those fetches by loading other HTML.

2004	   To avoid using an unintended certificate with the same public key as
2005	   the intended one, the content of the leaf certificate or the chain
2006	   should be included in the signed data, like TLS does (Section 4.4.3
2007	   of [I-D.ietf-tls-tls13]).

2009	B.2.  How much to sign

2011	   The previous [I-D.thomson-http-content-signature] and
2012	   [I-D.burke-content-signature] schemes signed just the content, while
2013	   ([I-D.cavage-http-signatures] could also sign the response headers
2014	   and the request method and path.  However, the same path, response
2015	   headers, and content may mean something very different when retrieved
2016	   from a different server.  Section 5.1.1 currently includes the whole
2017	   request URL in the signature, but it's possible we need a more
2018	   flexible scheme to allow some higher-level protocols to accept a
2019	   less-signed URL.

2021	   The question of whether to include other request headers--primarily
2022	   the "accept*" family--is still open.  These headers need to be
2023	   represented so that clients wanting a different language, say, can
2024	   avoid using the wrong-language response, but it's not obvious that
2025	   there's a security vulnerability if an attacker can spoof them.  For
2026	   now, the proposal (Section 3) omits other request headers.

2028	   In order to allow multiple clients to consume the same signed
2029	   exchange, the exchange shouldn't include the exact request headers
2030	   that any particular client sends.  For example, a Japanese resource
2031	   wouldn't include

2033	   accept-language: ja-JP, ja;q=0.9, en;q=0.8, zh;q=0.7, *;q=0.5

2035	   Instead, it would probably include just

2037	   accept-language: ja-JP, ja

2039	   and clients would use the same matching logic as for PUSH_PROMISE
2040	   [16] frame headers.

2042	B.2.1.  Conveying the signed headers

2044	   HTTP headers are traditionally munged by proxies, making it
2045	   impossible to guarantee that the client will see the same sequence of
2046	   bytes as the author wrote.  In the HTTPS world, we have more end-to-
2047	   end header integrity, but it's still likely that there are enough
2048	   TLS-terminating proxies that the author's signatures would tend to
2049	   break before getting to the client.

2051	   There's also no way in current HTTP for the response to a client-
2052	   initiated request (Section 8.1 of [RFC7540]) to convey the request
2053	   headers it expected to respond to.  A PUSH_PROMISE (Section 8.2 of
2054	   [RFC7540]) does not have this problem, and it would be possible to
2055	   introduce a response header to convey the expected request headers.

2057	   Since proxies are unlikely to modify unknown content types, we can
2058	   wrap the original exchange into an "application/http-exchange+cbor"
2059	   format (Section 5.3) and include the "Cache-Control: no-transform"
2060	   header when sending it.

2062	   To reduce the likelihood of accidental modification by proxies, the
2063	   "application/http-exchange+cbor" format includes a file signature
2064	   that doesn't collide with other known signatures.

2066	   To help the PUSHed subresources use case (Appendix A.1), we might
2067	   also want to extend the "PUSH_PROMISE" frame type to include a
2068	   signature, and that could tell intermediates not to change the
2069	   ensuing headers.

2071	B.3.  Response lifespan

2073	   A normal HTTPS response is authoritative only for one client, for as
2074	   long as its cache headers say it should live.  A signed exchange can
2075	   be re-used for many clients, and if it was generated while a server
2076	   was compromised, it can continue compromising clients even if their
2077	   requests happen after the server recovers.  This signing scheme needs
2078	   to mitigate that risk.

2080	B.3.1.  Certificate revocation

2082	   Certificates are mis-issued and private keys are stolen, and in
2083	   response clients need to be able to stop trusting these certificates
2084	   as promptly as possible.  Online revocation checks don't work [17],
2085	   so the industry has moved to pushed revocation lists and stapled OCSP
2086	   responses [RFC6066].

2088	   Pushed revocation lists work as-is to block trust in the certificate
2089	   signing an exchange, but the signatures need an explicit strategy to
2090	   staple OCSP responses.  One option is to extend the certificate
2091	   download (Appendix B.1.3) to include the OCSP response too, perhaps
2092	   in the TLS 1.3 CertificateEntry [18] format.

2094	B.3.2.  Response downgrade attacks

2096	   The signed content in a response might be vulnerable to attacks, such
2097	   as XSS, or might simply be discovered to be incorrect after
2098	   publication.  Once the author fixes those vulnerabilities or
2099	   mistakes, clients should stop trusting the old signed content in a
2100	   reasonable amount of time.  Similar to certificate revocation, I
2101	   expect the best option to be stapled "this version is still valid"
2102	   assertions with short expiration times.

2104	   These assertions could be structured as:

2106	   1.  A signed minimum version number or timestamp for a set of request
2107	       headers: This requires that signed responses need to include a
2108	       version number or timestamp, but allows a server to provide a
2109	       single signature covering all valid versions.

2111	   2.  A replacement for the whole exchange's signature.  This requires
2112	       the author to separately re-sign each valid version and requires
2113	       each version to include a different update URL, but allows
2114	       intermediates to serve less data.  This is the approach taken in
2115	       Section 3.

2117	   3.  A replacement for the exchange's signature and an update for the
2118	       embedded "expires" and related cache-control HTTP headers
2119	       [RFC7234].  This naturally extends authors' intuitions about
2120	       cache expiration and the existing cache revalidation behavior to
2121	       signed exchanges.  This is sketched and its downsides explored in
2122	       Appendix C.

2124	   The signature also needs to include instructions to intermediates for
2125	   how to fetch updated validity assertions.

2127	Appendix C.  Determining validity using cache control

2129	   This draft could expire signature validity using the normal HTTP
2130	   cache control headers ([RFC7234]) instead of embedding an expiration
2131	   date in the signature itself.  This section specifies how that would
2132	   work, and describes why I haven't chosen that option.

2134	   The signatures in the "Signature" header field (Section 3.1) would no
2135	   longer contain "date" or "expires" fields.

2137	   The validity-checking algorithm (Section 3.5) would initialize "date"
2138	   from the resource's "Date" header field (Section 7.1.1.2 of
2139	   [RFC7231]) and initialize "expires" from either the "Expires" header
2140	   field (Section 5.3 of [RFC7234]) or the "Cache-Control" header
2141	   field's "max-age" directive (Section 5.2.2.8 of [RFC7234]) (added to
2142	   "date"), whichever is present, preferring "max-age" (or failing) if
2143	   both are present.

2145	   Validity updates (Section 3.6) would include a list of replacement
2146	   response header fields.  For each header field name in this list, the
2147	   client would remove matching header fields from the stored exchange's
2148	   response header fields.  Then the client would append the replacement
2149	   header fields to the stored exchange's response header fields.

2151	C.1.  Example of updating cache control

2153	   For example, given a stored exchange of:

2155	   GET https://example.com/ HTTP/1.1
2156	   Accept: */*

2158	   HTTP/1.1 200
2159	   Date: Mon, 20 Nov 2017 10:00:00 UTC
2160	   Content-Type: text/html
2161	   Date: Tue, 21 Nov 2017 10:00:00 UTC
2162	   Expires: Sun, 26 Nov 2017 10:00:00 UTC

2164	   <!doctype html>
2165	   <html>
2166	   ...

2168	   And an update listing the following headers:

2170	   Expires: Fri, 1 Dec 2017 10:00:00 UTC
2171	   Date: Sat, 25 Nov 2017 10:00:00 UTC

2173	   The resulting stored exchange would be:

2175	   GET https://example.com/ HTTP/1.1
2176	   Accept: */*

2178	   HTTP/1.1 200
2179	   Content-Type: text/html
2180	   Expires: Fri, 1 Dec 2017 10:00:00 UTC
2181	   Date: Sat, 25 Nov 2017 10:00:00 UTC

2183	   <!doctype html>
2184	   <html>
2185	   ...

2187	C.2.  Downsides of updating cache control

2189	   In an exchange with multiple signatures, using cache control to
2190	   expire signatures forces all signatures to initially live for the
2191	   same period.  Worse, the update from one signature's "validityUrl"
2192	   might not match the update for another signature.  Clients would need
2193	   to maintain a current set of headers for each signature, and then
2194	   decide which set to use when actually parsing the resource itself.

2196	   This need to store and reconcile multiple sets of headers for a
2197	   single signed exchange argues for embedding a signature's lifetime
2198	   into the signature.

2200	Appendix D.  Change Log

2202	   RFC EDITOR PLEASE DELETE THIS SECTION.

2204	   draft-03

2206	   o  Allow each method of transferring an exchange to define which
2207	      headers are signed, have the cross-origin methods use all headers,
2208	      and remove the "allResponseHeaders" flag.

2210	   o  Describe footguns around signing private content, and block
2211	      certain headers to make it less likely.

2213	   o  Define a CBOR structure to hold the certificate chain instead of
2214	      re-using the TLS1.3 message.  The TLS 1.3 parser fails on
2215	      unexpected extensions while this format should ignore them, and
2216	      apparently TLS implementations don't expose their message parsers
2217	      enough to allow passing a message to a certificate verifier.

2219	   o  Require an X.509 extension for the signing certificate.

2221	   draft-02

2223	   o  Signatures identify a header (e.g.  Digest or MI) to guard the
2224	      payload's integrity instead of directly signing over the payload.

2226	   o  The validityUrl is signed.

2228	   o  Use CBOR maps where appropriate, and define how they're
2229	      canonicalized.

2231	   o  Remove the update.url field from signature validity updates, in
2232	      favor of just re-fetching the original request URL.

2234	   o  Define an HTTP/2 extension to use a setting to enable cross-origin
2235	      Server Push.

2237	   o  Define an "Accept-Signature" header to negotiate whether to send
2238	      Signatures and which ones.

2240	   o  Define an "application/http-exchange+cbor" format to fetch signed
2241	      exchanges without HTTP/2 Push.

2243	   o  2 new use cases.

2245	Appendix E.  Acknowledgements

2247	   Thanks to Ilari Liusvaara, Justin Schuh, Mark Nottingham, Mike
2248	   Bishop, Ryan Sleevi, and Yoav Weiss for comments that improved this
2249	   draft.

2251	Author's Address

2253	   Jeffrey Yasskin
2254	   Google

2256	   Email: jyasskin@chromium.org