idnits 2.17.1 

draft-yasskin-http-origin-signed-responses-04.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 13 instances of too long lines in the document, the longest
     one being 38 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 (June 14, 2018) is 2137 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 1837

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  == Unused Reference: 'ROBOT' is defined on line 1822, 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-06

  == 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 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 8032

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

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

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

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

  -- 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: 10 errors (**), 0 flaws (~~), 11 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                           June 14, 2018
5	Expires: December 16, 2018

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

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 December 16, 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  . . . . . . . . . . . . . . . . . . .  12
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 identifiers . . . . . . . . . . . . . . . .  19
82	       3.7.2.  Key type identifiers  . . . . . . . . . . . . . . . .  19
83	       3.7.3.  Key value identifiers . . . . . . . . . . . . . . . .  19
84	       3.7.4.  Examples  . . . . . . . . . . . . . . . . . . . . . .  20
85	       3.7.5.  Open Questions  . . . . . . . . . . . . . . . . . . .  20
86	   4.  Cross-origin trust  . . . . . . . . . . . . . . . . . . . . .  21
87	     4.1.  Stateful header fields  . . . . . . . . . . . . . . . . .  22
88	     4.2.  Certificate Requirements  . . . . . . . . . . . . . . . .  23
89	   5.  Transferring a signed exchange  . . . . . . . . . . . . . . .  24
90	     5.1.  Same-origin response  . . . . . . . . . . . . . . . . . .  24
91	       5.1.1.  Significant headers for a same-origin response  . . .  24
92	       5.1.2.  The Signed-Headers Header . . . . . . . . . . . . . .  25
93	     5.2.  HTTP/2 extension for cross-origin Server Push . . . . . .  26
94	       5.2.1.  Indicating support for cross-origin Server Push . . .  26
95	       5.2.2.  NO_TRUSTED_EXCHANGE_SIGNATURE error code  . . . . . .  26
96	       5.2.3.  Validating a cross-origin Push  . . . . . . . . . . .  26

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

151	1.  Introduction

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

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

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

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

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

179	2.  Terminology

181	   Author  The entity that wrote the content in a particular resource.
182	      This specification deals with publishers rather than authors.

184	   Publisher  The entity that controls the server for a particular
185	      origin [RFC6454].  The publisher can get a CA to issue
186	      certificates for their private keys and can run a TLS server for
187	      their origin.

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

194	   Intermediate  An entity that fetches signed HTTP exchanges from a
195	      publisher or another intermediate and forwards them to another
196	      intermediate or a client.

198	   Client  An entity that uses a signed HTTP exchange and needs to be
199	      able to prove that the publisher vouched for it as coming from its
200	      claimed origin.

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

204	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
205	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
206	   "OPTIONAL" in this document are to be interpreted as described in BCP
207	   14 [RFC2119] [RFC8174] when, and only when, they appear in all
208	   capitals, as shown here.

210	3.  Signing an exchange

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

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

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

230	3.1.  The Signature Header

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

238	   The "Signature" header is a Structured Header as defined by
239	   [I-D.ietf-httpbis-header-structure].  Its value MUST be a
240	   parameterised list (Section 3.3 of
241	   [I-D.ietf-httpbis-header-structure]).  Its ABNF is:

243	   Signature = sh-param-list

245	   Each parameterised identifier in the list MUST have parameters named
246	   "sig", "integrity", "validity-url", "date", and "expires".  Each
247	   parameterised identifier MUST also have either "cert-url" and "cert-
248	   sha256" parameters or an "ed25519key" parameter.  This specification
249	   gives no meaning to the identifier itself, which can be used as a
250	   human-readable identifier for the signature (see
251	   Section 3.1.2, Paragraph 1).  The present parameters MUST have the
252	   following values:

254	   "sig"  Binary content (Section 3.9 of
255	      [I-D.ietf-httpbis-header-structure]) holding the signature of most
256	      of these parameters and the exchange's headers.

258	   "integrity"  A string (Section 3.7 of
259	      [I-D.ietf-httpbis-header-structure]) containing the lowercase name
260	      of the response header field that guards the response payload's
261	      integrity.

263	   "cert-url"  A string (Section 3.7 of
264	      [I-D.ietf-httpbis-header-structure]) containing an absolute-URL
265	      string [4] ([URL]).

267	   "cert-sha256"  Binary content (Section 3.9 of
268	      [I-D.ietf-httpbis-header-structure]) holding the SHA-256 hash of
269	      the first certificate found at "cert-url".

271	   "ed25519key"  Binary content (Section 3.9 of
272	      [I-D.ietf-httpbis-header-structure]) holding an Ed25519 public key
273	      ([RFC8032]).

275	   "validity-url"  A string (Section 3.7 of
276	      [I-D.ietf-httpbis-header-structure]) containing an absolute-URL
277	      string [5] ([URL]).

279	   "date" and "expires"  An integer (Section 3.5 of
280	      [I-D.ietf-httpbis-header-structure]) representing a Unix time.

282	   The "cert-url" parameter is _not_ signed, so intermediates can update
283	   it with a pointer to a cached version.

285	3.1.1.  Examples

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

291	Signature:
292	 sig1;
293	  sig=*MEUCIQDXlI2gN3RNBlgFiuRNFpZXcDIaUpX6HIEwcZEc0cZYLAIga9DsVOMM+g5YpwEBdGW3sS+bvnmAJJiSMwhuBdqp5UY=*;
294	  integrity="mi";
295	  validity-url="https://example.com/resource.validity.1511128380";
296	  cert-url="https://example.com/oldcerts";
297	  cert-sha256=*W7uB969dFW3Mb5ZefPS9Tq5ZbH5iSmOILpjv2qEArmI=*;
298	  date=1511128380; expires=1511733180,
299	 sig2;
300	  sig=*MEQCIGjZRqTRf9iKNkGFyzRMTFgwf/BrY2ZNIP/dykhUV0aYAiBTXg+8wujoT4n/W+cNgb7pGqQvIUGYZ8u8HZJ5YH26Qg=*;
301	  integrity="mi";
302	  validity-url="https://example.com/resource.validity.1511128380";
303	  cert-url="https://example.com/newcerts";
304	  cert-sha256=*J/lEm9kNRODdCmINbvitpvdYKNQ+YgBj99DlYp4fEXw=*;
305	  date=1511128380; expires=1511733180,
306	 srisig;
307	  sig=*lGZVaJJM5f2oGczFlLmBdKTDL+QADza4BgeO494ggACYJOvrof6uh5OJCcwKrk7DK+LBch0jssDYPp5CLc1SDA=*
308	  integrity="mi";
309	  validity-url="https://example.com/resource.validity.1511128380";
310	  ed25519key=*zsSevyFsxyZHiUluVBDd4eypdRLTqyWRVOJuuKUz+A8=*
311	  date=1511128380; expires=1511733180,
312	 thirdpartysig;
313	  sig=*MEYCIQCNxJzn6Rh2fNxsobktir8TkiaJYQFhWTuWI1i4PewQaQIhAMs2TVjc4rTshDtXbgQEOwgj2mRXALhfXPztXgPupii+=*;
314	  integrity="mi";
315	  validity-url="https://thirdparty.example.com/resource.validity.1511161860";
316	  cert-url="https://thirdparty.example.com/certs";
317	  cert-sha256=*UeOwUPkvxlGRTyvHcsMUN0A2oNsZbU8EUvg8A9ZAnNc=*;
318	  date=1511133060; expires=1511478660,

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

325	   All 4 signatures rely on the "MI" response header to guard the
326	   integrity of the response payload.

328	   The signatures include a "validity-url" that includes the first time
329	   the resource was seen.  This allows multiple versions of a resource
330	   at the same URL to be updated with new signatures, which allows
331	   clients to avoid transferring extra data while the old versions don't
332	   have known security bugs.

334	   The certificates at "https://example.com/oldcerts" and
335	   "https://example.com/newcerts" have "subjectAltName"s of
336	   "example.com", meaning that if they and their signatures validate,
337	   the exchange can be trusted as having an origin of
338	   "https://example.com/".  The publisher might be using two
339	   certificates because their readers have disjoint sets of roots in
340	   their trust stores.

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

345	   The publisher then requested an additional signature from
346	   "thirdparty.example.com", which did some validation or processing and
347	   then signed the resource at 2017-11-19 23:11 UTC.
348	   "thirdparty.example.com" only grants 4-day signatures, so clients
349	   will need to re-validate more often.

351	3.1.2.  Open Questions

353	   [I-D.ietf-httpbis-header-structure] provides a way to parameterise
354	   identifiers but not other supported types like binary content.  If
355	   the "Signature" header field is notionally a list of parameterised
356	   signatures, maybe we should add a "parameterised binary content"
357	   type.

359	   Should the cert-url and validity-url be lists so that intermediates
360	   can offer a cache without losing the original URLs?  Putting lists in
361	   dictionary fields is more complex than
362	   [I-D.ietf-httpbis-header-structure] allows, so they're single items
363	   for now.

365	3.2.  CBOR representation of exchange headers

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

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

377	   1.  The map mapping:

379	       *  The byte string ':method' to the byte string containing
380	          "exchange"'s request's method.

382	       *  The byte string ':url' to the byte string containing
383	          "exchange"'s request's effective request URI, which MUST be an
384	          absolute-URL string [6] ([URL]).

386	       *  For each request header field in "exchange" except for the
387	          "Host" header field, the header field's lowercase name as a
388	          byte string to the header field's value as a byte string.

390	          Note: "Host" is excluded because it is already part of the
391	          effective request URI.

393	   2.  The map mapping:

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

398	       *  for each response header field in "exchange", the header
399	          field's lowercase name as a byte string to the header field's
400	          value as a byte string.

402	3.2.1.  Example

404	   Given the HTTP exchange:

406	GET / HTTP/1.1
407	Host: example.com
408	Accept: */*

410	HTTP/1.1 200
411	Content-Type: text/html
412	MI: mi-sha256=20addcf7368837f616d549f035bf6784ea6d4bf4817a3736cd2fc7a763897fe3
413	Signed-Headers: "content-type", "mi"

415	<!doctype html>
416	<html>
417	...

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

423	[
424	  {
425	    ':url': 'https://example.com/',
426	    'accept': '*/*',
427	    ':method': 'GET',
428	  },
429	  {
430	    'mi': 'mi-sha256=20addcf7368837f616d549f035bf6784ea6d4bf4817a3736cd2fc7a763897fe3',
431	    ':status': '200',
432	    'content-type': 'text/html'
433	  }
434	]

436	3.3.  Loading a certificate chain

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

442	   cert-chain = [
443	     "&#128220;&#9939;", ; U+1F4DC U+26D3
444	     + {
445	       cert: bytes,
446	       ? ocsp: bytes,
447	       ? sct: bytes,
448	       * tstr => any,
449	     }
450	   ]

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

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

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

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

469	   Loading a "cert-url" takes a "forceFetch" flag.  The client MUST:

471	   1.  Let "raw-chain" be the result of fetching ([FETCH]) "cert-url".
472	       If "forceFetch" is _not_ set, the fetch can be fulfilled from a
473	       cache using normal HTTP semantics [RFC7234].  If this fetch
474	       fails, return "invalid".

476	   2.  Let "certificate-chain" be the array of certificates and
477	       properties produced by parsing "raw-chain" using the CDDL above.
478	       If any of the requirements above aren't satisfied, return
479	       "invalid".  Note that this validation requirement might be
480	       impractical to completely achieve due to certificate validation
481	       implementations that don't enforce DER encoding or other standard
482	       constraints.

484	   3.  Return "certificate-chain".

486	3.4.  Canonical CBOR serialization

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

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

495	   o  Items MUST NOT be encoded with indefinite length.

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

501	      1.  10, encoded as 0A.

503	      2.  100, encoded as 18 64.

505	      3.  -1, encoded as 20.

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

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

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

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

515	      8.  false, encoded as F4.

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

521	3.5.  Signature validity

523	   The client MUST parse the "Signature" header field as the
524	   parameterised list (Section 4.2.3 of
525	   [I-D.ietf-httpbis-header-structure]) described in Section 3.1.  If an
526	   error is thrown during this parsing or any of the requirements
527	   described there aren't satisfied, the exchange has no valid
528	   signatures.  Otherwise, each member of this list represents a
529	   signature with parameters.

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

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

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

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

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

551	   2.  Let:

553	       *  "signature" be the signature (binary content in the
554	          parameterised identifier's "sig" parameter).

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

558	       *  "validity-url" be the signature's "validity-url" parameter.

560	       *  "cert-url" be the signature's "cert-url" parameter, if any.

562	       *  "cert-sha256" be the signature's "cert-sha256" parameter, if
563	          any.

565	       *  "ed25519key" be the signature's "ed25519key" parameter, if
566	          any.

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

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

574	   3.  If "integrity" names a header field that is not present in
575	       "exchange"'s response headers or which the client cannot use to
576	       check the integrity of "payload" (for example, the header field
577	       is new and hasn't been implemented yet), then return "invalid".
578	       If the selected header field provides integrity guarantees weaker
579	       than SHA-256, return "invalid".  If validating integrity using
580	       the selected header field requires the client to process records
581	       larger than TBD bytes, return "invalid".  Clients MUST implement
582	       at least the "MI" ([I-D.thomson-http-mice]) header field with its
583	       "mi-sha256" content encoding.

585	   4.  Set "publicKey" and "signing-alg" depending on which key fields
586	       are present:

588	       1.  If "cert-url" is present:

590	           1.  Let "certificate-chain" be the result of loading the
591	               certificate chain at "cert-url" passing the "forceFetch"
592	               flag (Section 3.3).  If this returns "invalid", return
593	               "invalid".

595	           2.  Let "main-certificate" be the first certificate in
596	               "certificate-chain".

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

600	           4.  If "publicKey" is an RSA key, return "invalid".

602	           5.  If "publicKey" is a key using the secp256r1 elliptic
603	               curve, set "signing-alg" to ecdsa_secp256r1_sha256 as
604	               defined in Section 4.2.3 of [I-D.ietf-tls-tls13].

606	           6.  Otherwise, either return "invalid" or set "signing-alg"
607	               to a non-legacy signing algorithm defined by TLS 1.3 or
608	               later ([I-D.ietf-tls-tls13]).  This choice MUST depend
609	               only on "publicKey"'s type and not on any other context.

611	       2.  If "ed25519key" is present, set "publicKey" to "ed25519key"
612	           and "signing-alg" to ed25519, as defined by [RFC8032]

614	   5.  If "expires" is more than 7 days (604800 seconds) after "date",
615	       return "invalid".

617	   6.  If the current time is before "date" or after "expires", return
618	       "invalid".

620	   7.  Let "message" be the concatenation of the following byte strings.
621	       This matches the [I-D.ietf-tls-tls13] format to avoid cross-
622	       protocol attacks if anyone uses the same key in a TLS certificate
623	       and an exchange-signing certificate.

625	       1.  A string that consists of octet 32 (0x20) repeated 64 times.

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

629	           Note: RFC EDITOR PLEASE DELETE THIS NOTE; The implementation
630	           of the final RFC MUST use this context string, but
631	           implementations of drafts MUST NOT use it and MUST use
632	           another draft-specific string beginning with "HTTP Exchange 1
633	           " instead.  This ensures that signers can predict how their
634	           signatures will be used.

636	       3.  A single 0 byte which serves as a separator.

638	       4.  The bytes of the canonical CBOR serialization (Section 3.4)
639	           of a CBOR map mapping:

641	           1.  If "cert-sha256" is set:

643	               1.  The text string "cert-sha256" to the byte string
644	                   value of "cert-sha256".

646	           2.  The text string "validity-url" to the byte string value
647	               of "validity-url".

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

651	           4.  The text string "expires" to the integer value of
652	               "expires".

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

657	   8.  If "cert-url" is present and the SHA-256 hash of "main-
658	       certificate"'s "cert_data" is not equal to "cert-sha256" (whose
659	       presence was checked when the "Signature" header field was
660	       parsed), return "invalid".

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

668	   9.  If "signature" is a valid signature of "message" by "publicKey"
669	       using "signing-alg", return "potentially-valid" with whichever is
670	       present of "certificate-chain" or "ed25519key".  Otherwise,
671	       return "invalid".

673	   Note that the above algorithm can determine that an exchange's
674	   headers are potentially-valid before the exchange's payload is
675	   received.  Similarly, if "integrity" identifies a header field like
676	   "MI" ([I-D.thomson-http-mice]) that can incrementally validate the
677	   payload, early parts of the payload can be determined to be
678	   potentially-valid before later parts of the payload.  Higher-level
679	   protocols MAY process parts of the exchange that have been determined
680	   to be potentially-valid as soon as that determination is made but
681	   MUST NOT process parts of the exchange that are not yet potentially-
682	   valid.  Similarly, as the higher-level protocol determines that parts
683	   of the exchange are actually valid, the client MAY process those
684	   parts of the exchange and MUST wait to process other parts of the
685	   exchange until they too are determined to be valid.

687	3.5.1.  Open Questions

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

692	3.6.  Updating signature validity

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

698	   This specification provides no way to update OCSP responses by
699	   themselves.  Instead, clients need to re-fetch the "cert-url"
700	   (Section 3.5, Paragraph 4) to get a chain including a newer OCSP
701	   response.

703	   The "validity-url" parameter (Paragraph 6) of the signatures provides
704	   a way to fetch new signatures or learn where to fetch a complete
705	   updated exchange.

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

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

714	   validity = {
715	     ? signatures: [ + bytes ]
716	     ? update: {
717	       ? size: uint,
718	     }
719	   ]

721	   The elements of the "signatures" array are parameterised identifiers
722	   (Section 4.2.4 of [I-D.ietf-httpbis-header-structure]) meant to
723	   replace the signatures within the "Signature" header field pointing
724	   to this validity data.  If the signed exchange contains a bug severe
725	   enough that clients need to stop using the content, the "signatures"
726	   array MUST NOT be present.

728	   If the the "update" map is present, that indicates that a new version
729	   of the signed exchange is available at its effective request URI
730	   (Section 5.5 of [RFC7230]) and can give an estimate of the size of
731	   the updated exchange ("update.size").  If the signed exchange is
732	   currently the most recent version, the "update" SHOULD NOT be
733	   present.

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

739	3.6.1.  Examples

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

745	Signature:
746	 sig1;
747	  sig=*MEUCIQ...*;
748	  ...
749	  validity-url="https://example.com/resource.validity.1511157180";
750	  cert-url="https://example.com/oldcerts";
751	  date=1511128380; expires=1511733180,
752	 sig2;
753	  sig=*MEQCIG...*;
754	  ...
755	  validity-url="https://example.com/resource.validity.1511157180";
756	  cert-url="https://example.com/newcerts";
757	  date=1511128380; expires=1511733180,
758	 thirdpartysig;
759	  sig=*MEYCIQ...*;
760	  ...
761	  validity-url="https://thirdparty.example.com/resource.validity.1511161860";
762	  cert-url="https://thirdparty.example.com/certs";
763	  date=1511478660; expires=1511824260

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

771	{
772	  "signatures": [
773	    'sig1; '
774	    'sig=*MEQCIC/I9Q+7BZFP6cSDsWx43pBAL0ujTbON/+7RwKVk+ba5AiB3FSFLZqpzmDJ0NumNwN04pqgJZE99fcK86UjkPbj4jw==*; '
775	    'validity-url="https://example.com/resource.validity.1511157180"; '
776	    'integrity="mi"; '
777	    'cert-url="https://example.com/newcerts"; '
778	    'cert-sha256=*J/lEm9kNRODdCmINbvitpvdYKNQ+YgBj99DlYp4fEXw=*; '
779	    'date=1511733180; expires=1512337980'
780	  ],
781	  "update": {
782	    "size": 5557452
783	  }
784	}

786	   This indicates that the client could fetch a newer version at
787	   "https://example.com/resource" (the original URL of the exchange), or
788	   that the validity period of the old version can be extended by
789	   replacing the first two of the original signatures (the ones with a
790	   validity-url of "https://example.com/resource.validity.1511157180")
791	   with the single new signature provided.  (This might happen at the
792	   end of a migration to a new root certificate.)  The signatures of the
793	   updated signed exchange would be:

795	Signature:
796	 sig1;
797	  sig=*MEQCIC...*;
798	  ...
799	  validity-url="https://example.com/resource.validity.1511157180";
800	  cert-url="https://example.com/newcerts";
801	  date=1511733180; expires=1512337980,
802	 thirdpartysig;
803	  sig=*MEYCIQ...*;
804	  ...
805	  validity-url="https://thirdparty.example.com/resource.validity.1511161860";
806	  cert-url="https://thirdparty.example.com/certs";
807	  date=1511478660; expires=1511824260

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

813	3.7.  The Accept-Signature header

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

822	   When a server receives an "Accept-Signature" header field in a client
823	   request, it SHOULD reply with any available "Signature" header fields
824	   for its response that the "Accept-Signature" header field indicates
825	   the client supports.  However, if the "Accept-Signature" value
826	   violates a requirement in this section, the server MUST behave as if
827	   it hadn't received any "Accept-Signature" header at all.

829	   The "Accept-Signature" header field is a Structured Header as defined
830	   by [I-D.ietf-httpbis-header-structure].  Its value MUST be a
831	   parameterised list (Section 3.3 of
832	   [I-D.ietf-httpbis-header-structure]).  Its ABNF is:

834	   Accept-Signature = sh-param-list

836	   The order of identifiers in the "Accept-Signature" list is not
837	   significant.  Identifiers, ignoring any initial "-" character, MUST
838	   NOT be duplicated.

840	   Each identifier in the "Accept-Signature" header field's value
841	   indicates that a feature of the "Signature" header field
842	   (Section 3.1) is supported.  If the identifier begins with a "-"
843	   character, it instead indicates that the feature named by the rest of
844	   the identifier is not supported.  Unknown identifiers and parameters
845	   MUST be ignored because new identifiers and new parameters on
846	   existing identifiers may be defined by future specifications.

848	3.7.1.  Integrity identifiers

850	   Identifiers starting with "mi/" indicate that the client supports the
851	   "MI" header field ([I-D.thomson-http-mice]) with the parameter from
852	   the HTTP MI Parameter Registry registry named in lower-case by the
853	   rest of the identifier.  For example, "mi/mi-blake2" indicates
854	   support for Merkle integrity with the as-yet-unspecified mi-blake2
855	   parameter, and "-digest/mi-sha256" indicates non-support for Merkle
856	   integrity with the mi-sha256 content encoding.

858	   If the "Accept-Signature" header field is present, servers SHOULD
859	   assume support for "mi/mi-sha256" unless the header field states
860	   otherwise.

862	3.7.2.  Key type identifiers

864	   Identifiers starting with "ecdsa/" indicate that the client supports
865	   certificates holding ECDSA public keys on the curve named in lower-
866	   case by the rest of the identifier.

868	   If the "Accept-Signature" header field is present, servers SHOULD
869	   assume support for "ecdsa/secp256r1" unless the header field states
870	   otherwise.

872	3.7.3.  Key value identifiers

874	   The "ed25519key" identifier has parameters indicating the public keys
875	   that will be used to validate the returned signature.  Each
876	   parameter's name is re-interpreted as binary content (Section 3.9 of
877	   [I-D.ietf-httpbis-header-structure]) encoding a prefix of the public
878	   key.  For example, if the client will validate signatures using the
879	   public key whose base64 encoding is
880	   "11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo=", valid "Accept-
881	   Signature" header fields include:

883	Accept-Signature: ..., ed25519key; *11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo=*
884	Accept-Signature: ..., ed25519key; *11qYAYKxCrfVS/7TyWQHOg==*
885	Accept-Signature: ..., ed25519key; *11qYAQ==*
886	Accept-Signature: ..., ed25519key; **
887	   but not

889	   Accept-Signature: ..., ed25519key; *11qYA===*

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

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

895	   because it doesn't start or end with the "*"s that indicate binary
896	   content.

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

904	3.7.4.  Examples

906	   Accept-Signature: mi/mi-sha256

908	   states that the client will accept signatures with payload integrity
909	   assured by the "MI" header and "mi-sha256" content encoding and
910	   implies that the client will accept integrity assured by the "Digest:
911	   SHA-256" header and signatures from ECDSA keys on the secp256r1
912	   curve.

914	   Accept-Signature: -ecdsa/secp256r1, ecdsa/secp384r1

916	   states that the client will accept ECDSA keys on the secp384r1 curve
917	   but not the secp256r1 curve and payload integrity assured with the
918	   "MI: mi-sha256" header field.

920	3.7.5.  Open Questions

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

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

931	   Do I have the right structure for the identifiers indicating feature
932	   support?

934	4.  Cross-origin trust

936	   To determine whether to trust a cross-origin exchange, the client
937	   takes a "Signature" header field (Section 3.1) and the "exchange".
938	   The client MUST parse the "Signature" header into a list of
939	   signatures according to the instructions in Section 3.5, and run the
940	   following algorithm for each signature, stopping at the first one
941	   that returns "valid".  If any signature returns "valid", return
942	   "valid".  Otherwise, return "invalid".

944	   1.  If the signature's "validity-url" parameter (Paragraph 6) is not
945	       same-origin [7] with "exchange"'s effective request URI
946	       (Section 5.5 of [RFC7230]), return "invalid".

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

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

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

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

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

967	       1.  Use "certificate-chain" to validate that its first entry,
968	           "main-certificate" is trusted as "authority"'s server
969	           certificate ([RFC5280] and other undocumented conventions).
970	           Let "path" be the path that was used from the "main-
971	           certificate" to a trusted root, including the "main-
972	           certificate" but excluding the root.

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

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

984	       4.  Validate that valid SCTs from trusted logs are available from
985	           any of:

987	           +  The "SignedCertificateTimestampList" in "main-
988	              certificate"'s "sct" property (Section 3.3),

990	           +  An OCSP extension in the OCSP response in "main-
991	              certificate"'s "ocsp" property, or

993	           +  An X.509 extension in the certificate in "main-
994	              certificate"'s "cert" property,

996	           as described by Section 3.3 of [RFC6962].

998	   7.  Return "valid".

1000	4.1.  Stateful header fields

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

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

1011	   o  "Authorization", [RFC7235]

1013	   o  "Cookie", [RFC6265]

1015	   o  "Cookie2", [RFC2965]

1017	   o  "Proxy-Authorization", [RFC7235]

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

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

1025	   o  "Authentication-Control", [RFC8053]

1027	   o  "Authentication-Info", [RFC7615]
1028	   o  "Optional-WWW-Authenticate", [RFC8053]

1030	   o  "Proxy-Authenticate", [RFC7235]

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

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

1036	   o  "Set-Cookie", [RFC6265]

1038	   o  "Set-Cookie2", [RFC2965]

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

1042	   o  "WWW-Authenticate", [RFC7235]

1044	4.2.  Certificate Requirements

1046	   We define a new X.509 extension, CanSignHttpExchanges to be used in
1047	   the certificate when the certificate permits the usage of signed
1048	   exchanges.  When this extension is not present the client MUST NOT
1049	   accept a signature from the certificate as proof that a signed
1050	   exchange is authoritative for a domain covered by the certificate.
1051	   When it is present, the client MUST follow the validation procedure
1052	   in Section 4.

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

1056	      CanSignHttpExchanges ::= NULL

1058	   Note that this extension contains an ASN.1 NULL (bytes "05 00")
1059	   because some implementations have bugs with empty extensions.

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

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

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

1072	   Conforming CAs MUST mark this extension as critical, and clients MUST
1073	   NOT accept certificates with this extension in TLS connections
1074	   (Section 4.4.2.2 of [I-D.ietf-tls-tls13]).  This simplifies security
1075	   analysis of this protocol and avoids encouraging server operators to
1076	   put exchange-signing keys on servers exposed directly to the
1077	   internet.

1079	   RFC EDITOR PLEASE DELETE THE REST OF THE PARAGRAPHS IN THIS SECTION

1081	   id-ce-google OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 11129 }
1082	   id-ce-testCanSignHttpExchanges OBJECT IDENTIFIER ::= { id-ce-google 2 1 22 }

1084	   Implementations of drafts of this specification MAY recognize the
1085	   "id-ce-testCanSignHttpExchanges" OID as identifying the
1086	   CanSignHttpExchanges extension.  This OID might or might not be used
1087	   as the final OID for the extension, so certificates including it
1088	   might need to be reissued once the final RFC is published.

1090	5.  Transferring a signed exchange

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

1095	5.1.  Same-origin response

1097	   The signature for a signed exchange can be included in a normal HTTP
1098	   response.  Because different clients send different request header
1099	   fields, and intermediate servers add response header fields, it can
1100	   be impossible to have a signature for the exact request and response
1101	   that the client sees.  Therefore, when a client validates the
1102	   "Signature" header field for an exchange represented as a normal HTTP
1103	   request/response pair, it MUST pass only the subset of header fields
1104	   defined by Section 5.1.1 to the validation procedure (Section 3.5).

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

1110	5.1.1.  Significant headers for a same-origin response

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

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

1119	   o  The response status code (Section 6 of [RFC7231]) and the response
1120	      header fields whose names are listed in that exchange's "Signed-
1121	      Headers" header field (Section 5.1.2), in the order they appear in
1122	      that header field.  If a response header field name from "Signed-
1123	      Headers" does not appear in the exchange's response header fields,
1124	      the exchange has no significant headers.

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

1132	5.1.1.1.  Open Questions

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

1137	5.1.2.  The Signed-Headers Header

1139	   The "Signed-Headers" header field identifies an ordered list of
1140	   response header fields to include in a signature.  The request URL
1141	   and response status are included unconditionally.  This allows a TLS-
1142	   terminating intermediate to reorder headers without breaking the
1143	   signature.  This _can_ also allow the intermediate to add headers
1144	   that will be ignored by some higher-level protocols, but Section 3.5
1145	   provides a hook to let other higher-level protocols reject such
1146	   insecure headers.

1148	   This header field appears once instead of being incorporated into the
1149	   signatures' parameters because the signed header fields need to be
1150	   consistent across all signatures of an exchange, to avoid forcing
1151	   higher-level protocols to merge the header field lists of valid
1152	   signatures.

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

1157	   "Signed-Headers" is a Structured Header as defined by
1158	   [I-D.ietf-httpbis-header-structure].  Its value MUST be a list
1159	   (Section 3.2 of [I-D.ietf-httpbis-header-structure]).  Its ABNF is:

1161	   Signed-Headers = sh-list

1163	   Each element of the "Signed-Headers" list must be a lowercase string
1164	   (Section 3.7 of [I-D.ietf-httpbis-header-structure]) naming an HTTP
1165	   response header field.  Pseudo-header field names (Section 8.1.2.1 of
1166	   [RFC7540]) MUST NOT appear in this list.

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

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

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

1178	5.2.1.  Indicating support for cross-origin Server Push

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

1184	   An ENABLE_CROSS_ORIGIN_PUSH value of 0 indicates that the client does
1185	   not support cross-origin Push.  A value of 1 indicates that the
1186	   client does support cross-origin Push.

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

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

1200	5.2.2.  NO_TRUSTED_EXCHANGE_SIGNATURE error code

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

1209	5.2.2.1.  Open Questions

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

1213	5.2.3.  Validating a cross-origin Push

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

1221	   Instead, the client MUST validate such a PUSH_PROMISE and its
1222	   response by taking the "Signature" header field from the response,
1223	   and the exchange consisting of the PUSH_PROMISE and the response
1224	   without that "Signature" header field, and passing them to the
1225	   algorithm in Section 4.  If this returns "invalid", the client MUST
1226	   treat the response as a stream error (Section 5.4.2 of [RFC7540]) of
1227	   type NO_TRUSTED_EXCHANGE_SIGNATURE.  Otherwise, the client MUST treat
1228	   the pushed response as if the server were authoritative for the
1229	   PUSH_PROMISE's authority.

1231	5.2.3.1.  Open Questions

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

1238	5.3.  application/signed-exchange format

1240	   To allow signed exchanges to be the targets of "<link rel=prefetch>"
1241	   tags, we define the "application/signed-exchange" content type that
1242	   represents a signed HTTP exchange, including request metadata and
1243	   header fields, response metadata and header fields, and a response
1244	   payload.

1246	   This content type consists of the concatenation of the following
1247	   items:

1249	   1.  The ASCII characters "sxg1" followed by a 0 byte, to serve as a
1250	       file signature.  This is redundant with the MIME type, and
1251	       receipients that receive both MUST check that they match and stop
1252	       parsing if they don't.

1254	       Note: RFC EDITOR PLEASE DELETE THIS NOTE; The implementation of
1255	       the final RFC MUST use this file signature, but implementations
1256	       of drafts MUST NOT use it and MUST use another implementation-
1257	       specific string beginning with "sxg1-" and ending with a 0 byte
1258	       instead.

1260	   2.  3 bytes storing a big-endian integer "sigLength".  If this is
1261	       larger than TBD, parsing MUST fail.

1263	   3.  3 bytes storing a big-endian integer "headerLength".  If this is
1264	       larger than TBD, parsing MUST fail.

1266	   4.  "sigLength" bytes holding the "Signature" header field's value
1267	       (Section 3.1).

1269	   5.  "headerLength" bytes holding the signed headers, the canonical
1270	       serialization (Section 3.4) of the CBOR representation of the
1271	       request and response headers of the exchange represented by the
1272	       "application/signed-exchange" resource (Section 3.2), excluding
1273	       the "Signature" header field.

1275	       Note that this is exactly the bytes used when checking signature
1276	       validity in Section 3.5.

1278	   6.  The payload body (Section 3.3 of [RFC7230]) of the exchange
1279	       represented by the "application/signed-exchange" resource.

1281	       Note that the use of the payload body here means that a
1282	       "Transfer-Encoding" header field inside the "application/signed-
1283	       exchange" header block has no effect.  A "Transfer-Encoding"
1284	       header field on the outer HTTP response that transfers this
1285	       resource still has its normal effect.

1287	5.3.1.  Cross-origin trust in application/signed-exchange

1289	   To determine whether to trust a cross-origin exchange stored in an
1290	   "application/signed-exchange" resource, pass the "Signature" header
1291	   field from the non-signed header section and an exchange consisting
1292	   of the headers from the signed headers section and the payload body,
1293	   to the algorithm in Section 4.

1295	5.3.2.  Example

1297	   An example "application/signed-exchange" file representing a possible
1298	   signed exchange with https://example.com/ [8] follows, with lengths
1299	   represented by descriptions in "<>"s, CBOR represented in the
1300	   extended diagnostic format defined in Appendix G of
1301	   [I-D.ietf-cbor-cddl], and most of the "Signature" header field and
1302	   payload elided with a ...:

1304	sxg1\0<3-byte length of the following header
1305	value>sig1; sig=*...; integrity="mi"; ...<3-byte length of the encoding of the
1306	following array>[
1307	  {
1308	    ':method': 'GET',
1309	    ':url': 'https://example.com/',
1310	    'accept', '*/*'
1311	  },
1312	  {
1313	    ':status': '200',
1314	    'content-type': 'text/html'
1315	  }
1316	]<!doctype html>\r\n<html>...

1318	5.3.3.  Open Questions

1320	   Should this be a CBOR format, or is the current mix of binary and
1321	   CBOR better?

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

1325	6.  Security considerations

1327	6.1.  Over-signing

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

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

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

1343	   2.  Only sign exchanges where the response includes a "Cache-Control:
1344	       public" header.  Clients are not required to fail signature-
1345	       checking for exchanges that omit this "Cache-Control" response
1346	       header field to reduce the risk that naive signing systems
1347	       blindly add it.

1349	6.1.1.  Session fixation

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

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

1362	6.1.2.  Misleading content

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

1369	   Stripping authentication information from requests before sending
1370	   them to backends is likely to prevent the backend from showing
1371	   attacker-specific information in the signed response.  It does not
1372	   prevent the attacker from showing their victim a signed-out page when
1373	   the victim is actually signed in, but while this is still misleading,
1374	   it seems less likely to be useful to the attacker.

1376	6.2.  Off-path attackers

1378	   Relaxing the requirement to consult DNS when determining authority
1379	   for an origin means that an attacker who possesses a valid
1380	   certificate no longer needs to be on-path to redirect traffic to
1381	   them; instead of modifying DNS, they need only convince the user to
1382	   visit another Web site in order to serve responses signed as the
1383	   target.  This consideration and mitigations for it are shared by the
1384	   combination of [RFC8336] and
1385	   [I-D.ietf-httpbis-http2-secondary-certs].

1387	6.3.  Downgrades

1389	   Signing a bad response can affect more users than simply serving a
1390	   bad response, since a served response will only affect users who make
1391	   a request while the bad version is live, while an attacker can
1392	   forward a signed response until its signature expires.  Publishers
1393	   should consider shorter signature expiration times than they use for
1394	   cache expiration times.

1396	   Clients MAY also check the "validity-url" (Paragraph 6) of an
1397	   exchange more often than the signature's expiration would require.
1398	   Doing so for an exchange with an HTTPS request URI provides a TLS
1399	   guarantee that the exchange isn't out of date (as long as
1400	   Section 5.2.3.1 is resolved to keep the same-origin requirement).

1402	6.4.  Signing oracles are permanent

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

1412	6.5.  Unsigned headers

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

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

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

1433	6.6.  application/signed-exchange

1435	   Clients MUST NOT trust an effective request URI claimed by an
1436	   "application/signed-exchange" resource (Section 5.3) without either
1437	   ensuring the resource was transferred from a server that was
1438	   authoritative (Section 9.1 of [RFC7230]) for that URI's origin, or
1439	   calling the algorithm in Section 5.3.1 and getting "valid" back.

1441	7.  Privacy considerations

1443	   Normally, when a client fetches "https://o1.com/resource.js",
1444	   "o1.com" learns that the client is interested in the resource.  If
1445	   "o1.com" signs "resource.js", "o2.com" serves it as "https://o2.com/
1446	   o1resource.js", and the client fetches it from there, then "o2.com"
1447	   learns that the client is interested, and if the client executes the
1448	   Javascript, that could also report the client's interest back to
1449	   "o1.com".

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

1455	   For non-executable resource types, a signed response can improve the
1456	   privacy situation by hiding the client's interest from the original
1457	   publisher.

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

1468	8.  IANA considerations

1470	   TODO: possibly register the validity-url format.

1472	8.1.  Signature Header Field Registration

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

1477	   Header field name: "Signature"

1479	   Applicable protocol: http

1481	   Status: standard

1483	   Author/Change controller: IETF

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

1487	8.2.  Accept-Signature Header Field Registration

1489	   This section registers the "Accept-Signature" header field in the
1490	   "Permanent Message Header Field Names" registry ([RFC3864]).

1492	   Header field name: "Accept-Signature"

1494	   Applicable protocol: http

1496	   Status: standard

1498	   Author/Change controller: IETF

1500	   Specification document(s): Section 3.7 of this document

1502	8.3.  Signed-Headers Header Field Registration

1504	   This section registers the "Signed-Headers" header field in the
1505	   "Permanent Message Header Field Names" registry ([RFC3864]).

1507	   Header field name: "Signed-Headers"

1509	   Applicable protocol: http

1511	   Status: standard

1513	   Author/Change controller: IETF

1515	   Specification document(s): Section 5.1.2 of this document

1517	8.4.  HTTP/2 Settings

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

1522	   Name: ENABLE_CROSS_ORIGIN_PUSH

1524	   Code: 0xSETTING-TBD

1526	   Initial Value: 0

1528	   Specification: This document

1530	8.5.  HTTP/2 Error code

1532	   This section establishes an entry for the HTTP/2 Error Code Registry
1533	   that was established by Section 11.4 of [RFC7540]
1534	   Name: NO_TRUSTED_EXCHANGE_SIGNATURE

1536	   Code: 0xERROR-TBD

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

1541	   Specification: This document

1543	8.6.  Internet Media Type application/signed-exchange

1545	   Type name: application

1547	   Subtype name: signed-exchange

1549	   Required parameters:

1551	   o  v: A string denoting the version of the file format.  ([RFC5234]
1552	      ABNF: "version = DIGIT/%x61-7A") The version defined in this
1553	      specification is "1".  When used with the "Accept" header field
1554	      (Section 5.3.1 of [RFC7231]), this parameter can be a comma
1555	      (,)-separated list of version strings.  ([RFC5234] ABNF: "version-
1556	      list = version *( "," version )") The server is then expected to
1557	      reply with a resource using a particular version from that list.

1559	      Note: RFC EDITOR PLEASE DELETE THIS NOTE; Implementations of
1560	      drafts of this specification MUST NOT use simple integers to
1561	      describe their versions, and MUST instead define implementation-
1562	      specific strings to identify which draft is implemented.

1564	   Optional parameters: N/A

1566	   Encoding considerations: binary

1568	   Security considerations: see Section 6.6

1570	   Interoperability considerations: N/A

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

1574	   Applications that use this media type: N/A

1576	   Fragment identifier considerations: N/A

1578	   Additional information:

1580	   Deprecated alias names for this type: N/A
1581	   Magic number(s): 73 78 67 31 00

1583	   File extension(s): .sxg

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

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

1590	   Intended usage: COMMON

1592	   Restrictions on usage: N/A

1594	   Author: See Authors' Addresses section.

1596	   Change controller: IESG

1598	8.7.  Internet Media Type application/cert-chain+cbor

1600	   Type name: application

1602	   Subtype name: cert-chain+cbor

1604	   Required parameters: N/A

1606	   Optional parameters: N/A

1608	   Encoding considerations: binary

1610	   Security considerations: N/A

1612	   Interoperability considerations: N/A

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

1616	   Applications that use this media type: N/A

1618	   Fragment identifier considerations: N/A

1620	   Additional information:

1622	   Deprecated alias names for this type: N/A

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

1626	   File extension(s): N/A

1628	   Macintosh file type code(s): N/A
1629	   Person and email address to contact for further information: See
1630	   Authors' Addresses section.

1632	   Intended usage: COMMON

1634	   Restrictions on usage: N/A

1636	   Author: See Authors' Addresses section.

1638	   Change controller: IESG

1640	9.  References

1642	9.1.  Normative References

1644	   [FETCH]    WHATWG, "Fetch", June 2018,
1645	              <https://fetch.spec.whatwg.org/>.

1647	   [HTML]     WHATWG, "HTML", June 2018,
1648	              <https://html.spec.whatwg.org/multipage>.

1650	   [I-D.ietf-cbor-cddl]
1651	              Birkholz, H., Vigano, C., and C. Bormann, "Concise data
1652	              definition language (CDDL): a notational convention to
1653	              express CBOR data structures", draft-ietf-cbor-cddl-02
1654	              (work in progress), February 2018.

1656	   [I-D.ietf-httpbis-header-structure]
1657	              Nottingham, M. and P. Kamp, "Structured Headers for HTTP",
1658	              draft-ietf-httpbis-header-structure-06 (work in progress),
1659	              June 2018.

1661	   [I-D.ietf-tls-tls13]
1662	              Rescorla, E., "The Transport Layer Security (TLS) Protocol
1663	              Version 1.3", draft-ietf-tls-tls13-28 (work in progress),
1664	              March 2018.

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

1670	   [POSIX]    IEEE and The Open Group, "The Open Group Base
1671	              Specifications Issue 7", name IEEE, value 1003.1-2008,
1672	              2016 Edition, 2016,
1673	              <http://pubs.opengroup.org/onlinepubs/9699919799/
1674	              basedefs/>.

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

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

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

1690	   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
1691	              Specifications: ABNF", STD 68, RFC 5234,
1692	              DOI 10.17487/RFC5234, January 2008,
1693	              <https://www.rfc-editor.org/info/rfc5234>.

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

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

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

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

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

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

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

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

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

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

1744	   [URL]      WHATWG, "URL", June 2018, <https://url.spec.whatwg.org/>.

1746	9.2.  Informative References

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

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

1758	   [I-D.cavage-http-signatures]
1759	              Cavage, M. and M. Sporny, "Signing HTTP Messages", draft-
1760	              cavage-http-signatures-10 (work in progress), May 2018.

1762	   [I-D.ietf-httpbis-http2-secondary-certs]
1763	              Bishop, M., Sullivan, N., and M. Thomson, "Secondary
1764	              Certificate Authentication in HTTP/2", draft-ietf-httpbis-
1765	              http2-secondary-certs-01 (work in progress), May 2018.

1767	   [I-D.thomson-http-content-signature]
1768	              Thomson, M., "Content-Signature Header Field for HTTP",
1769	              draft-thomson-http-content-signature-00 (work in
1770	              progress), July 2015.

1772	   [I-D.yasskin-webpackage-use-cases]
1773	              Yasskin, J., "Use Cases and Requirements for Web
1774	              Packages", draft-yasskin-webpackage-use-cases-01 (work in
1775	              progress), March 2018.

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

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

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

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

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

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

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

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

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

1818	   [RFC8336]  Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame",
1819	              RFC 8336, DOI 10.17487/RFC8336, March 2018,
1820	              <https://www.rfc-editor.org/info/rfc8336>.

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

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

1830	   [W3C.NOTE-OPS-OverHTTP]
1831	              Hensley, P., Metral, M., Shardanand, U., Converse, D., and
1832	              M. Myers, "Implementation of OPS Over HTTP", W3C NOTE
1833	              NOTE-OPS-OverHTTP, June 1997.

1835	9.3.  URIs

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

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

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

1844	   [4] https://url.spec.whatwg.org/#absolute-url-string

1846	   [5] https://url.spec.whatwg.org/#absolute-url-string

1848	   [6] https://url.spec.whatwg.org/#absolute-url-string

1850	   [7] https://html.spec.whatwg.org/multipage/origin.html#same-origin

1852	   [8] https://example.com/

1854	   [9] https://calendar.perfplanet.com/2013/big-bad-preloader/

1856	   [10] https://github.com/mikewest/signature-based-sri

1858	   [11] https://github.com/mikewest/signature-based-sri/issues/5

1860	   [12] https://www.apple.com/ios/app-store/

1862	   [13] https://play.google.com/store

1864	   [14] https://github.com/WICG/webpackage

1866	   [15] https://tools.ietf.org/html/rfc7540#section-8.2

1868	   [16] https://www.imperialviolet.org/2012/02/05/crlsets.html

1870	   [17] https://tlswg.github.io/tls13-spec/draft-ietf-tls-
1871	        tls13.html#ocsp-and-sct

1873	Appendix A.  Use cases

1875	A.1.  PUSHed subresources

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

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

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

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

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

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

1902	   <img logicalsrc="https://O.com/img.png"
1903	        physicalsrc="https://distributor.com/O.com/img.png">

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

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

1911	   where the "<dist-img>" implementation generates an appropriate
1912	   "<img>" based on, for example, a "<meta name="dist-base">" tag
1913	   elsewhere in the page.  However, this has the downside that the
1914	   preloader [9] can no longer see the physical source to download it.
1915	   The resulting delay might cancel out the benefit of using a
1916	   distributor.

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

1921	   To implement this with the current proposal, the distributor would
1922	   respond to the physical request to "https://distributor.com/O.com/
1923	   img.png" with first a signed PUSH_PROMISE for "https://O.com/img.png"
1924	   and then a redirect to "https://O.com/img.png".

1926	A.3.  Subresource Integrity

1928	   The W3C WebAppSec group is investigating using signatures [10] in
1929	   [SRI].  They need a way to transmit the signature with the response,
1930	   which this proposal provides.

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

1937	   The "ed25519key" signature parameter supports this simpler way of
1938	   attaching a key.

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

1947	A.4.  Binary Transparency

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

1956	   Certificate Transparency depends on Signed Certificate Timestamps
1957	   that prove a log contained a particular certificate at a particular
1958	   time.  To build the same thing for Binary Transparency logs
1959	   containing HTTP resources or full websites, we'll need a way to
1960	   provide signatures of those resources, which signed exchanges
1961	   provides.

1963	A.5.  Static Analysis

1965	   Native app stores like the Apple App Store [12] and the Android Play
1966	   Store [13] grant their contents powerful abilities, which they
1967	   attempt to make safe by analyzing the applications before offering
1968	   them to people.  The web has no equivalent way for people to wait to
1969	   run an update of a web application until a trusted authority has
1970	   vouched for it.

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

1977	A.6.  Offline websites

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

1984	Appendix B.  Requirements

1986	B.1.  Proof of origin

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

1994	B.1.1.  Certificate constraints

1996	   If we re-use existing TLS server certificates, we incur the risks
1997	   that:

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

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

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

2013	B.1.2.  Signature constraints

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

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

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

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

2033	B.1.3.  Retrieving the certificate

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

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

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

2058	B.2.  How much to sign

2060	   The previous [I-D.thomson-http-content-signature] and
2061	   [I-D.burke-content-signature] schemes signed just the content, while
2062	   ([I-D.cavage-http-signatures] could also sign the response headers
2063	   and the request method and path.  However, the same path, response
2064	   headers, and content may mean something very different when retrieved
2065	   from a different server.  Section 5.1.1 currently includes the whole
2066	   request URL in the signature, but it's possible we need a more
2067	   flexible scheme to allow some higher-level protocols to accept a
2068	   less-signed URL.

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

2077	   In order to allow multiple clients to consume the same signed
2078	   exchange, the exchange shouldn't include the exact request headers
2079	   that any particular client sends.  For example, a Japanese resource
2080	   wouldn't include

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

2084	   Instead, it would probably include just

2086	   accept-language: ja-JP, ja

2088	   and clients would use the same matching logic as for PUSH_PROMISE
2089	   [15] frame headers.

2091	B.2.1.  Conveying the signed headers

2093	   HTTP headers are traditionally munged by proxies, making it
2094	   impossible to guarantee that the client will see the same sequence of
2095	   bytes as the publisher published.  In the HTTPS world, we have more
2096	   end-to-end header integrity, but it's still likely that there are
2097	   enough TLS-terminating proxies that the publisher's signatures would
2098	   tend to break before getting to the client.

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

2106	   Since proxies are unlikely to modify unknown content types, we can
2107	   wrap the original exchange into an "application/signed-exchange"
2108	   format (Section 5.3) and include the "Cache-Control: no-transform"
2109	   header when sending it.

2111	   To reduce the likelihood of accidental modification by proxies, the
2112	   "application/signed-exchange" format includes a file signature that
2113	   doesn't collide with other known signatures.

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

2120	B.3.  Response lifespan

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

2129	B.3.1.  Certificate revocation

2131	   Certificates are mis-issued and private keys are stolen, and in
2132	   response clients need to be able to stop trusting these certificates
2133	   as promptly as possible.  Online revocation checks don't work [16],
2134	   so the industry has moved to pushed revocation lists and stapled OCSP
2135	   responses [RFC6066].

2137	   Pushed revocation lists work as-is to block trust in the certificate
2138	   signing an exchange, but the signatures need an explicit strategy to
2139	   staple OCSP responses.  One option is to extend the certificate
2140	   download (Appendix B.1.3) to include the OCSP response too, perhaps
2141	   in the TLS 1.3 CertificateEntry [17] format.

2143	B.3.2.  Response downgrade attacks

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

2153	   These assertions could be structured as:

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

2160	   2.  A replacement for the whole exchange's signature.  This requires
2161	       the publisher to separately re-sign each valid version and
2162	       requires each version to include a different update URL, but
2163	       allows intermediates to serve less data.  This is the approach
2164	       taken in Section 3.

2166	   3.  A replacement for the exchange's signature and an update for the
2167	       embedded "expires" and related cache-control HTTP headers
2168	       [RFC7234].  This naturally extends publishers' intuitions about
2169	       cache expiration and the existing cache revalidation behavior to
2170	       signed exchanges.  This is sketched and its downsides explored in
2171	       Appendix C.

2173	   The signature also needs to include instructions to intermediates for
2174	   how to fetch updated validity assertions.

2176	B.4.  Low implementation complexity

2178	   Simpler implementations are, all things equal, less likely to include
2179	   bugs.  This section describes decisions that were made in the rest of
2180	   the specification to reduce complexity.

2182	B.4.1.  Limited choices

2184	   In general, we're trying to eliminate unnecessary choices in the
2185	   specification.  For example, instead of requiring clients to support
2186	   two methods for verifying payload integrity, we only require one.

2188	B.4.2.  Bounded-buffering integrity checking

2190	   Clients can be designed with a more-trusted network layer that
2191	   decides how to trust resources and then provides those resources to
2192	   less-trusted rendering processes along with handles to the storage
2193	   and other resources they're allowed to access.  If the network layer
2194	   can enforce that it only operates on chunks of data up to a certain
2195	   size, it can avoid the complexity of spooling large files to disk.

2197	   To allow the network layer to verify signed exchanges using a bounded
2198	   amount of memory, Section 5.3 requires the signature and headers to
2199	   be less than TBD bytes long, and Section 3.5 requires that the MI
2200	   record size be less than TBD bytes.  This allows the network layer to
2201	   validate a bounded chunk at a time, and pass that chunk on to a
2202	   renderer, and then forget about that chunk before processing the next
2203	   one.

2205	   The "Digest" header field from [RFC3230] requires the network layer
2206	   to buffer the entire response body, so it's disallowed.

2208	Appendix C.  Determining validity using cache control

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

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

2218	   The validity-checking algorithm (Section 3.5) would initialize "date"
2219	   from the resource's "Date" header field (Section 7.1.1.2 of
2220	   [RFC7231]) and initialize "expires" from either the "Expires" header
2221	   field (Section 5.3 of [RFC7234]) or the "Cache-Control" header
2222	   field's "max-age" directive (Section 5.2.2.8 of [RFC7234]) (added to
2223	   "date"), whichever is present, preferring "max-age" (or failing) if
2224	   both are present.

2226	   Validity updates (Section 3.6) would include a list of replacement
2227	   response header fields.  For each header field name in this list, the
2228	   client would remove matching header fields from the stored exchange's
2229	   response header fields.  Then the client would append the replacement
2230	   header fields to the stored exchange's response header fields.

2232	C.1.  Example of updating cache control

2234	   For example, given a stored exchange of:

2236	   GET  / HTTP/1.1
2237	   Host: example.com
2238	   Accept: */*

2240	   HTTP/1.1 200
2241	   Date: Mon, 20 Nov 2017 10:00:00 UTC
2242	   Content-Type: text/html
2243	   Date: Tue, 21 Nov 2017 10:00:00 UTC
2244	   Expires: Sun, 26 Nov 2017 10:00:00 UTC

2246	   <!doctype html>
2247	   <html>
2248	   ...

2250	   And an update listing the following headers:

2252	   Expires: Fri, 1 Dec 2017 10:00:00 UTC
2253	   Date: Sat, 25 Nov 2017 10:00:00 UTC

2255	   The resulting stored exchange would be:

2257	   GET / HTTP/1.1
2258	   Host: example.com
2259	   Accept: */*

2261	   HTTP/1.1 200
2262	   Content-Type: text/html
2263	   Expires: Fri, 1 Dec 2017 10:00:00 UTC
2264	   Date: Sat, 25 Nov 2017 10:00:00 UTC

2266	   <!doctype html>
2267	   <html>
2268	   ...

2270	C.2.  Downsides of updating cache control

2272	   In an exchange with multiple signatures, using cache control to
2273	   expire signatures forces all signatures to initially live for the
2274	   same period.  Worse, the update from one signature's "validity-url"
2275	   might not match the update for another signature.  Clients would need
2276	   to maintain a current set of headers for each signature, and then
2277	   decide which set to use when actually parsing the resource itself.

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

2283	Appendix D.  Change Log

2285	   RFC EDITOR PLEASE DELETE THIS SECTION.

2287	   draft-04

2289	   o  Update to draft-ietf-httpbis-header-structure-06.

2291	   o  Replace the application/http-exchange+cbor format with a simpler
2292	      application/signed-exchange format that:

2294	      *  Doesn't require a streaming CBOR parser parse it from a network
2295	         stream.

2297	      *  Doesn't allow request payloads or response trailers, which
2298	         don't fit into the signature model.

2300	      *  Allows checking the signature before parsing the exchange
2301	         headers.

2303	   o  Require absolute URLs.

2305	   o  Make all identifiers in headers lower-case, as required by
2306	      Structured Headers.

2308	   o  Switch back to the TLS 1.3 signature format.

2310	   o  Include the version and draft number in the signature context
2311	      string.

2313	   o  Remove support for integrity protection using the Digest header
2314	      field.

2316	   o  Limit the record size in the mi-sha256 encoding.

2318	   o  Forbid RSA keys, and only require clients to support secp256r1
2319	      keys.

2321	   o  Add a test OID for the CanSignHttpExchanges X.509 extension.

2323	   draft-03

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

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

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

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

2340	   draft-02

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

2345	   o  The validityUrl is signed.

2347	   o  Use CBOR maps where appropriate, and define how they're
2348	      canonicalized.

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

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

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

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

2362	   o  2 new use cases.

2364	Appendix E.  Acknowledgements

2366	   Thanks to Ilari Liusvaara, Justin Schuh, Mark Nottingham, Mike
2367	   Bishop, Ryan Sleevi, and Yoav Weiss for comments that improved this
2368	   draft.

2370	Author's Address

2372	   Jeffrey Yasskin
2373	   Google

2375	   Email: jyasskin@chromium.org