idnits 2.17.1 

draft-yasskin-http-origin-signed-responses-08.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 10 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 (November 04, 2019) is 1633 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 2219

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

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

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

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

  -- 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: '6' on line 2230

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

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

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

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

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

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

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

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

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

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

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

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

  -- Looks like a reference, but probably isn't: '19' on line 2515

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

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

  == Outdated reference: A later version (-06) exists of
     draft-ietf-httpbis-variants-05

  -- Possible downref: Normative reference to a draft: ref.
     'I-D.ietf-httpbis-variants' 

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

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

  ** Obsolete normative reference: RFC 6844 (Obsoleted by RFC 8659)

  ** 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 (-19) exists of
     draft-ietf-httpbis-cache-05

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

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

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

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

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


     Summary: 11 errors (**), 0 flaws (~~), 7 warnings (==), 29 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                       November 04, 2019
5	Expires: May 7, 2020

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

10	Abstract

12	   This document specifies how a server can send an HTTP exchange--a
13	   request URL, content negotiation information, and a response--with
14	   signatures that vouch for that exchange's authenticity.  These
15	   signatures can be verified against an origin's certificate to
16	   establish that the exchange is authoritative for an origin even if it
17	   was transferred over a connection that isn't.  The signatures can
18	   also be used in other ways 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 May 7, 2020.

49	Copyright Notice

51	   Copyright (c) 2019 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  . . . . . . . . . . . . . . . . . .   6
70	       3.1.1.  Examples  . . . . . . . . . . . . . . . . . . . . . .   7
71	       3.1.2.  Open Questions  . . . . . . . . . . . . . . . . . . .   9
72	     3.2.  CBOR representation of exchange response headers  . . . .   9
73	       3.2.1.  Example . . . . . . . . . . . . . . . . . . . . . . .  10
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  . . . . . . . . . . . . . . . . . . .  16
78	     3.6.  Updating signature validity . . . . . . . . . . . . . . .  16
79	       3.6.1.  Examples  . . . . . . . . . . . . . . . . . . . . . .  17
80	     3.7.  The Accept-Signature header . . . . . . . . . . . . . . .  19
81	       3.7.1.  Integrity identifiers . . . . . . . . . . . . . . . .  20
82	       3.7.2.  Key type identifiers  . . . . . . . . . . . . . . . .  20
83	       3.7.3.  Key value identifiers . . . . . . . . . . . . . . . .  20
84	       3.7.4.  Examples  . . . . . . . . . . . . . . . . . . . . . .  21
85	       3.7.5.  Open Questions  . . . . . . . . . . . . . . . . . . .  21
86	   4.  Cross-origin trust  . . . . . . . . . . . . . . . . . . . . .  22
87	     4.1.  Uncached header fields  . . . . . . . . . . . . . . . . .  23
88	       4.1.1.  Stateful header fields  . . . . . . . . . . . . . . .  24
89	     4.2.  Certificate Requirements  . . . . . . . . . . . . . . . .  25
90	       4.2.1.  Extensions to the CAA Record: cansignhttpexchanges
91	               Parameter . . . . . . . . . . . . . . . . . . . . . .  26
92	   5.  Transferring a signed exchange  . . . . . . . . . . . . . . .  26
93	     5.1.  Same-origin response  . . . . . . . . . . . . . . . . . .  26
94	       5.1.1.  Serialized headers for a same-origin response . . . .  27
95	       5.1.2.  The Signed-Headers Header . . . . . . . . . . . . . .  27
96	     5.2.  HTTP/2 extension for cross-origin Server Push . . . . . .  28
97	       5.2.1.  Indicating support for cross-origin Server Push . . .  28
98	       5.2.2.  NO_TRUSTED_EXCHANGE_SIGNATURE error code  . . . . . .  29
99	       5.2.3.  Validating a cross-origin Push  . . . . . . . . . . .  29
100	     5.3.  application/signed-exchange format  . . . . . . . . . . .  30
101	       5.3.1.  Cross-origin trust in application/signed-exchange . .  31
102	       5.3.2.  Example . . . . . . . . . . . . . . . . . . . . . . .  31
103	       5.3.3.  Open Questions  . . . . . . . . . . . . . . . . . . .  32
104	   6.  Security considerations . . . . . . . . . . . . . . . . . . .  32
105	     6.1.  Over-signing  . . . . . . . . . . . . . . . . . . . . . .  32
106	       6.1.1.  Session fixation  . . . . . . . . . . . . . . . . . .  32
107	       6.1.2.  Misleading content  . . . . . . . . . . . . . . . . .  33
108	     6.2.  Off-path attackers  . . . . . . . . . . . . . . . . . . .  33
109	       6.2.1.  Mis-issued certificates . . . . . . . . . . . . . . .  33
110	       6.2.2.  Stolen private keys . . . . . . . . . . . . . . . . .  34
111	     6.3.  Downgrades  . . . . . . . . . . . . . . . . . . . . . . .  34
112	     6.4.  Signing oracles are permanent . . . . . . . . . . . . . .  35
113	     6.5.  Unsigned headers  . . . . . . . . . . . . . . . . . . . .  35
114	     6.6.  application/signed-exchange . . . . . . . . . . . . . . .  35
115	     6.7.  Key re-use with TLS . . . . . . . . . . . . . . . . . . .  36
116	     6.8.  Content sniffing  . . . . . . . . . . . . . . . . . . . .  36
117	   7.  Privacy considerations  . . . . . . . . . . . . . . . . . . .  37
118	     7.1.  Visibility of resource requests . . . . . . . . . . . . .  37
119	     7.2.  User ID transfer  . . . . . . . . . . . . . . . . . . . .  38
120	   8.  IANA considerations . . . . . . . . . . . . . . . . . . . . .  39
121	     8.1.  Signature Header Field Registration . . . . . . . . . . .  39
122	     8.2.  Accept-Signature Header Field Registration  . . . . . . .  39
123	     8.3.  Signed-Headers Header Field Registration  . . . . . . . .  39
124	     8.4.  HTTP/2 Settings . . . . . . . . . . . . . . . . . . . . .  40
125	     8.5.  HTTP/2 Error code . . . . . . . . . . . . . . . . . . . .  40
126	     8.6.  Internet Media Type application/signed-exchange . . . . .  40
127	     8.7.  Internet Media Type application/cert-chain+cbor . . . . .  42
128	     8.8.  The cansignhttpexchanges CAA Parameter  . . . . . . . . .  43
129	   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  43
130	     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  43
131	     9.2.  Informative References  . . . . . . . . . . . . . . . . .  45
132	     9.3.  URIs  . . . . . . . . . . . . . . . . . . . . . . . . . .  48
133	   Appendix A.  Use cases  . . . . . . . . . . . . . . . . . . . . .  49
134	     A.1.  PUSHed subresources . . . . . . . . . . . . . . . . . . .  49
135	     A.2.  Explicit use of a content distributor for subresources  .  49
136	     A.3.  Subresource Integrity . . . . . . . . . . . . . . . . . .  50
137	     A.4.  Binary Transparency . . . . . . . . . . . . . . . . . . .  50
138	     A.5.  Static Analysis . . . . . . . . . . . . . . . . . . . . .  51
139	     A.6.  Offline websites  . . . . . . . . . . . . . . . . . . . .  51
140	   Appendix B.  Requirements . . . . . . . . . . . . . . . . . . . .  51
141	     B.1.  Proof of origin . . . . . . . . . . . . . . . . . . . . .  51
142	       B.1.1.  Certificate constraints . . . . . . . . . . . . . . .  51
143	       B.1.2.  Signature constraints . . . . . . . . . . . . . . . .  52
144	       B.1.3.  Retrieving the certificate  . . . . . . . . . . . . .  52

146	     B.2.  How much to sign  . . . . . . . . . . . . . . . . . . . .  53
147	       B.2.1.  Conveying the signed headers  . . . . . . . . . . . .  53
148	     B.3.  Response lifespan . . . . . . . . . . . . . . . . . . . .  54
149	       B.3.1.  Certificate revocation  . . . . . . . . . . . . . . .  54
150	       B.3.2.  Response downgrade attacks  . . . . . . . . . . . . .  54
151	     B.4.  Low implementation complexity . . . . . . . . . . . . . .  55
152	       B.4.1.  Limited choices . . . . . . . . . . . . . . . . . . .  55
153	       B.4.2.  Bounded-buffering integrity checking  . . . . . . . .  55
154	   Appendix C.  Determining validity using cache control . . . . . .  56
155	     C.1.  Example of updating cache control . . . . . . . . . . . .  56
156	     C.2.  Downsides of updating cache control . . . . . . . . . . .  57
157	   Appendix D.  Change Log . . . . . . . . . . . . . . . . . . . . .  57
158	   Appendix E.  Acknowledgements . . . . . . . . . . . . . . . . . .  60
159	   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  60

161	1.  Introduction

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

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

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

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

183	   Subsequent work toward the use cases in [I-D.yasskin-wpack-use-cases]
184	   will provide a way to group signed exchanges into bundles that can be
185	   transmitted and stored together, but single signed exchanges are
186	   useful enough to standardize on their own.

188	2.  Terminology

190	   Absolute URL  A string for which the URL parser [3] ([URL]), when run
191	      without a base URL, returns a URL rather than a failure, and for
192	      which that URL has a null fragment.  This is similar to the
193	      absolute-URL string [4] concept defined by ([URL]) but might not
194	      include exactly the same strings.

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

199	   Publisher  The entity that controls the server for a particular
200	      origin [RFC6454].  The publisher can get a CA to issue
201	      certificates for their private keys and can run a TLS server for
202	      their origin.

204	   Exchange (noun)  An HTTP request URL, content negotiation
205	      information, and an HTTP response.  This can be encoded into a
206	      request message from a client with its matching response from a
207	      server, into the request in a PUSH_PROMISE with its matching
208	      response stream, or into the dedicated format in Section 5.3,
209	      which uses [I-D.ietf-httpbis-variants] to encode the content
210	      negotiation information.  This is not quite the same meaning as
211	      defined by Section 8 of [RFC7540], which assumes the content
212	      negotiation information is embedded into HTTP request headers.

214	   Intermediate  An entity that fetches signed HTTP exchanges from a
215	      publisher or another intermediate and forwards them to another
216	      intermediate or a client.

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

222	   Unix time  Defined by [POSIX] section 4.16 [5].

224	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
225	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
226	   "OPTIONAL" in this document are to be interpreted as described in BCP
227	   14 [RFC2119] [RFC8174] when, and only when, they appear in all
228	   capitals, as shown here.

230	3.  Signing an exchange

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

238	   The client categorizes each signature as "valid" or "invalid" by
239	   validating that signature with its certificate or public key and
240	   other metadata against the exchange's URL, response headers, and
241	   content (Section 3.5).  This validity then informs higher-level
242	   protocols.

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

251	3.1.  The Signature Header

253	   The "Signature" header field conveys a list of signatures for an
254	   exchange, each one accompanied by information about how to determine
255	   the authority of and refresh that signature.  Each signature directly
256	   signs the exchange's URL and response headers and identifies one of
257	   those headers that enforces the integrity of the exchange's payload.

259	   The "Signature" header is a Structured Header as defined by
260	   [I-D.ietf-httpbis-header-structure].  Its value MUST be a
261	   parameterised list (Section 3.4 of
262	   [I-D.ietf-httpbis-header-structure]).  Its ABNF is:

264	   Signature = sh-param-list

266	   Each parameterised identifier in the list MUST have parameters named
267	   "sig", "integrity", "validity-url", "date", and "expires".  Each
268	   parameterised identifier MUST also have either "cert-url" and "cert-
269	   sha256" parameters or an "ed25519key" parameter.  This specification
270	   gives no meaning to the identifier itself, which can be used as a
271	   human-readable identifier for the signature (however, this is likely
272	   to change soon; see Section 3.1.2, Paragraph 1).  The present
273	   parameters MUST have the following values:

275	   "sig"  Byte sequence (Section 3.10 of
276	      [I-D.ietf-httpbis-header-structure]) holding the signature of most
277	      of these parameters and the exchange's URL and response headers.

279	   "integrity"  A string (Section 3.8 of
280	      [I-D.ietf-httpbis-header-structure]) containing a "/"-separated
281	      sequence of names starting with the lowercase name of the response
282	      header field that guards the response payload's integrity.  The
283	      meaning of subsequent names depends on the response header field,
284	      but for the "digest" header field, the single following name is
285	      the name of the digest algorithm that guards the payload's
286	      integrity.

288	   "cert-url"  A string (Section 3.8 of
289	      [I-D.ietf-httpbis-header-structure]) containing an absolute URL
290	      (Section 2) with a scheme of "https" or "data".

292	   "cert-sha256"  Byte sequence (Section 3.10 of
293	      [I-D.ietf-httpbis-header-structure]) holding the SHA-256 hash of
294	      the first certificate found at "cert-url".

296	   "ed25519key"  Byte sequence (Section 3.10 of
297	      [I-D.ietf-httpbis-header-structure]) holding an Ed25519 public key
298	      ([RFC8032]).

300	   "validity-url"  A string (Section 3.8 of
301	      [I-D.ietf-httpbis-header-structure]) containing an absolute URL
302	      (Section 2) with a scheme of "https".

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

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

310	3.1.1.  Examples

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

316	Signature:
317	 sig1;
318	  sig=*MEUCIQDXlI2gN3RNBlgFiuRNFpZXcDIaUpX6HIEwcZEc0cZYLAIga9DsVOMM+g5YpwEBdGW3sS+bvnmAJJiSMwhuBdqp5UY=*;
319	  integrity="digest/mi-sha256";
320	  validity-url="https://example.com/resource.validity.1511128380";
321	  cert-url="https://example.com/oldcerts";
322	  cert-sha256=*W7uB969dFW3Mb5ZefPS9Tq5ZbH5iSmOILpjv2qEArmI=*;
323	  date=1511128380; expires=1511733180,
324	 sig2;
325	  sig=*MEQCIGjZRqTRf9iKNkGFyzRMTFgwf/BrY2ZNIP/dykhUV0aYAiBTXg+8wujoT4n/W+cNgb7pGqQvIUGYZ8u8HZJ5YH26Qg==*;
326	  integrity="digest/mi-sha256";
327	  validity-url="https://example.com/resource.validity.1511128380";
328	  cert-url="https://example.com/newcerts";
329	  cert-sha256=*J/lEm9kNRODdCmINbvitpvdYKNQ+YgBj99DlYp4fEXw=*;
330	  date=1511128380; expires=1511733180,
331	 srisig;
332	  sig=*lGZVaJJM5f2oGczFlLmBdKTDL+QADza4BgeO494ggACYJOvrof6uh5OJCcwKrk7DK+LBch0jssDYPp5CLc1SDA==*;
333	  integrity="digest/mi-sha256";
334	  validity-url="https://example.com/resource.validity.1511128380";
335	  ed25519key=*zsSevyFsxyZHiUluVBDd4eypdRLTqyWRVOJuuKUz+A8=*
336	  date=1511128380; expires=1511733180,
337	 thirdpartysig;
338	  sig=*MEYCIQCNxJzn6Rh2fNxsobktir8TkiaJYQFhWTuWI1i4PewQaQIhAMs2TVjc4rTshDtXbgQEOwgj2mRXALhfXPztXgPupii+*;
339	  integrity="digest/mi-sha256";
340	  validity-url="https://thirdparty.example.com/resource.validity.1511161860";
341	  cert-url="https://thirdparty.example.com/certs";
342	  cert-sha256=*UeOwUPkvxlGRTyvHcsMUN0A2oNsZbU8EUvg8A9ZAnNc=*;
343	  date=1511133060; expires=1511478660,

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

350	   All 4 signatures rely on the "Digest" response header with the mi-
351	   sha256 digest algorithm to guard the integrity of the response
352	   payload.

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

360	   The certificates at "https://example.com/oldcerts" and
361	   "https://example.com/newcerts" have "subjectAltName"s of
362	   "example.com", meaning that if they and their signatures validate,
363	   the exchange can be trusted as having an origin of
364	   "https://example.com/".  The publisher might be using two
365	   certificates because their readers have disjoint sets of roots in
366	   their trust stores.

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

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

377	3.1.2.  Open Questions

379	   The next revision of [I-D.ietf-httpbis-header-structure] will provide
380	   a way to parameterise byte sequences, at which point the signature
381	   itself is likely to become the main list item.

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

389	3.2.  CBOR representation of exchange response headers

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

399	   The CBOR representation of a set of response metadata and headers is
400	   the CBOR ([RFC7049]) map with the following mappings:

402	   o  The byte string ':status' to the byte string containing the
403	      response's 3-digit status code, and

405	   o  For each response header field, the header field's lowercase name
406	      as a byte string to the header field's value as a byte string.

408	3.2.1.  Example

410	   Given the HTTP exchange:

412	   GET / HTTP/1.1
413	   Host: example.com
414	   Accept: */*

416	   HTTP/1.1 200
417	   Content-Type: text/html
418	   Digest: mi-sha256=dcRDgR2GM35DluAV13PzgnG6+pvQwPywfFvAu1UeFrs=
419	   Signed-Headers: "content-type", "digest"

421	   <!doctype html>
422	   <html>
423	   ...

425	   The cbor representation consists of the following item, represented
426	   using the extended diagnostic notation from [CDDL] appendix G:

428	   {
429	     'digest': 'mi-sha256=dcRDgR2GM35DluAV13PzgnG6+pvQwPywfFvAu1UeFrs=',
430	     ':status': '200',
431	     'content-type': 'text/html'
432	   }

434	3.3.  Loading a certificate chain

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

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

451	   The first map (second item) in the CBOR array is treated as the end-
452	   entity certificate, and the client will attempt to build a path
453	   ([RFC5280]) to it from a trusted root using the other certificates in
454	   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 MUST be a complete, DER-
461	       encoded OCSP response for that certificate (using the ASN.1 type
462	       "OCSPResponse" defined in [RFC6960]).  Subsequent certificates
463	       MUST NOT have an "ocsp" value.

465	   3.  Each certificate's "sct" value if any 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.5 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's

535	   o  "requestUrl", a byte sequence that can be parsed into the
536	      exchange's effective request URI (Section 5.5 of [RFC7230]),

538	   o  "responseHeaders", a byte sequence holding the canonical
539	      serialization (Section 3.4) of the CBOR representation
540	      (Section 3.2) of the exchange's response metadata and headers, and

542	   o  "payload", a stream of bytes constituting the exchange's payload
543	      body (Section 3.3 of [RFC7230]).  Note that the payload body is
544	      the message body with any transfer encodings removed.

546	   Potentially-valid results include:

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

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

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

560	   1.   Let:

562	        *  "signature" be the signature (byte sequence in the
563	           parameterised identifier's "sig" parameter).

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

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

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

571	        *  "cert-sha256" be the signature's "cert-sha256" parameter, if
572	           any.

574	        *  "ed25519key" be the signature's "ed25519key" parameter, if
575	           any.

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

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

583	   2.   Set "publicKey" and "signing-alg" depending on which key fields
584	        are present:

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

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

593	            2.  Let "main-certificate" be the first certificate in
594	                "certificate-chain".

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

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

600	            5.  If "publicKey" is a key using the secp256r1 elliptic
601	                curve, set "signing-alg" to ecdsa_secp256r1_sha256 as
602	                defined in Section 4.2.3 of [RFC8446].

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

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

612	   3.   If "expires" is more than 7 days (604800 seconds) after "date",
613	        return "invalid".

615	   4.   If the current time is before "date" or after "expires", return
616	        "invalid".

618	   5.   Let "message" be the concatenation of the following byte
619	        strings.  This matches the [RFC8446] format to avoid cross-
620	        protocol attacks if anyone uses the same key in a TLS
621	        certificate and an exchange-signing certificate.

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

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

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

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

636	        4.  If "cert-sha256" is set, a byte holding the value 32
637	            followed by the 32 bytes of the value of "cert-sha256".
638	            Otherwise a 0 byte.

640	        5.  The 8-byte big-endian encoding of the length in bytes of
641	            "validity-url", followed by the bytes of "validity-url".

643	        6.  The 8-byte big-endian encoding of "date".

645	        7.  The 8-byte big-endian encoding of "expires".

647	        8.  The 8-byte big-endian encoding of the length in bytes of
648	            "requestUrl", followed by the bytes of "requestUrl".

650	        9.  The 8-byte big-endian encoding of the length in bytes of
651	            "responseHeaders", followed by the bytes of
652	            "responseHeaders".

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

659	        Note that this intentionally differs from TLS 1.3, which signs
660	        the entire certificate chain in its Certificate Verify
661	        (Section 4.4.3 of [RFC8446]), in order to allow updating the
662	        stapled OCSP response without updating signatures at the same
663	        time.

665	   7.   If "signature" is not a valid signature of "message" by
666	        "publicKey" using "signing-alg", return "invalid".

668	   8.   If "headers", interpreted according to Section 3.2, does not
669	        contain a "Content-Type" response header field (Section 3.1.1.5
670	        of [RFC7231]), return "invalid".

672	        Clients MUST interpret the signed payload as this specified
673	        media type instead of trying to sniff a media type from the
674	        bytes of the payload, for example by attaching an "X-Content-
675	        Type-Options: nosniff" header field ([FETCH]) to the extracted
676	        response.

678	   9.   If "integrity" names a header field and parameter that is not
679	        present in "responseHeaders" or which the client cannot use to
680	        check the integrity of "payload" (for example, the header field
681	        is new and hasn't been implemented yet), then return "invalid".
682	        If the selected header field provides integrity guarantees
683	        weaker than SHA-256, return "invalid".  If validating integrity
684	        using the selected header field requires the client to process
685	        records larger than 16384 bytes, return "invalid".  Clients MUST
686	        implement at least the "Digest" header field with its "mi-
687	        sha256" digest algorithm (Section 3 of [I-D.thomson-http-mice]).

689	        Note: RFC EDITOR PLEASE DELETE THIS NOTE; Implementations of
690	        drafts of this RFC MUST recognize the draft spelling of the
691	        content encoding and digest algorithm specified by
692	        [I-D.thomson-http-mice] until that draft is published as an RFC.
693	        For example, implementations of draft-thomson-http-mice-03 would
694	        use "mi-sha256-03" and MUST NOT use "mi-sha256" itself.  This
695	        ensures that final implementations don't need to handle
696	        compatibility with implementations of early drafts of that
697	        content encoding.

699	        If "payload" doesn't match the integrity information in the
700	        header described by "integrity", return "invalid".

702	   10.  Return "potentially-valid" with whichever is present of
703	        "certificate-chain" or "ed25519key".

705	   Note that the above algorithm can determine that an exchange's
706	   headers are potentially-valid before the exchange's payload is
707	   received.  Similarly, if "integrity" identifies a header field and
708	   parameter like "Digest:mi-sha256" ([I-D.thomson-http-mice]) that can
709	   incrementally validate the payload, early parts of the payload can be
710	   determined to be potentially-valid before later parts of the payload.
711	   Higher-level protocols MAY process parts of the exchange that have
712	   been determined to be potentially-valid as soon as that determination
713	   is made but MUST NOT process parts of the exchange that are not yet
714	   potentially-valid.  Similarly, as the higher-level protocol
715	   determines that parts of the exchange are actually valid, the client
716	   MAY process those parts of the exchange and MUST wait to process
717	   other parts of the exchange until they too are determined to be
718	   valid.

720	3.5.1.  Open Questions

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

725	3.6.  Updating signature validity

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

731	   This specification provides no way to update OCSP responses by
732	   themselves.  Instead, clients need to re-fetch the "cert-url"
733	   (Section 3.5, Paragraph 6) to get a chain including a newer OCSP
734	   response.

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

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

744	   The resource at a "validity-url" is "validity data", a CBOR map
745	   matching the following CDDL ([CDDL]):

747	   validity = {
748	     ? signatures: [ + bytes ]
749	     ? update: {
750	       ? size: uint,
751	     }
752	   ]

754	   The elements of the "signatures" array are parameterised identifiers
755	   (Section 4.2.6 of [I-D.ietf-httpbis-header-structure]) meant to
756	   replace the signatures within the "Signature" header field pointing
757	   to this validity data.  If the signed exchange contains a bug severe
758	   enough that clients need to stop using the content, the "signatures"
759	   array MUST NOT be present.

761	   If the the "update" map is present, that indicates that a new version
762	   of the signed exchange is available at its effective request URI
763	   (Section 5.5 of [RFC7230]) and can give an estimate of the size of
764	   the updated exchange ("update.size").  If the signed exchange is
765	   currently the most recent version, the "update" SHOULD NOT be
766	   present.

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

772	3.6.1.  Examples

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

778	Signature:
779	 sig1;
780	  sig=*MEUCIQ...*;
781	  ...
782	  validity-url="https://example.com/resource.validity.1511157180";
783	  cert-url="https://example.com/oldcerts";
784	  date=1511128380; expires=1511733180,
785	 sig2;
786	  sig=*MEQCIG...*;
787	  ...
788	  validity-url="https://example.com/resource.validity.1511157180";
789	  cert-url="https://example.com/newcerts";
790	  date=1511128380; expires=1511733180,
791	 thirdpartysig;
792	  sig=*MEYCIQ...*;
793	  ...
794	  validity-url="https://thirdparty.example.com/resource.validity.1511161860";
795	  cert-url="https://thirdparty.example.com/certs";
796	  date=1511478660; expires=1511824260

798	   At 2017-11-27 11:02 UTC, "sig1" and "sig2" have expired, but
799	   "thirdpartysig" doesn't exipire until 23:11 that night, so the client
800	   needs to fetch "https://example.com/resource.validity.1511157180"
801	   (the "validity-url" of "sig1" and "sig2") if it wishes to update
802	   those signatures.  This URL might contain:

804	{
805	  "signatures": [
806	    'sig1; '
807	    'sig=*MEQCIC/I9Q+7BZFP6cSDsWx43pBAL0ujTbON/+7RwKVk+ba5AiB3FSFLZqpzmDJ0NumNwN04pqgJZE99fcK86UjkPbj4jw==*; '
808	    'validity-url="https://example.com/resource.validity.1511157180"; '
809	    'integrity="digest/mi-sha256"; '
810	    'cert-url="https://example.com/newcerts"; '
811	    'cert-sha256=*J/lEm9kNRODdCmINbvitpvdYKNQ+YgBj99DlYp4fEXw=*; '
812	    'date=1511733180; expires=1512337980'
813	  ],
814	  "update": {
815	    "size": 5557452
816	  }
817	}

819	   This indicates that the client could fetch a newer version at
820	   "https://example.com/resource" (the original URL of the exchange), or
821	   that the validity period of the old version can be extended by
822	   replacing the first two of the original signatures (the ones with a
823	   validity-url of "https://example.com/resource.validity.1511157180")
824	   with the single new signature provided.  (This might happen at the
825	   end of a migration to a new root certificate.)  The signatures of the
826	   updated signed exchange would be:

828	Signature:
829	 sig1;
830	  sig=*MEQCIC...*;
831	  ...
832	  validity-url="https://example.com/resource.validity.1511157180";
833	  cert-url="https://example.com/newcerts";
834	  date=1511733180; expires=1512337980,
835	 thirdpartysig;
836	  sig=*MEYCIQ...*;
837	  ...
838	  validity-url="https://thirdparty.example.com/resource.validity.1511161860";
839	  cert-url="https://thirdparty.example.com/certs";
840	  date=1511478660; expires=1511824260

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

846	3.7.  The Accept-Signature header

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

855	   When a server receives an "Accept-Signature" header field in a client
856	   request, it SHOULD reply with any available "Signature" header fields
857	   for its response that the "Accept-Signature" header field indicates
858	   the client supports.  However, if the "Accept-Signature" value
859	   violates a requirement in this section, the server MUST behave as if
860	   it hadn't received any "Accept-Signature" header at all.

862	   The "Accept-Signature" header field is a Structured Header as defined
863	   by [I-D.ietf-httpbis-header-structure].  Its value MUST be a
864	   parameterised list (Section 3.4 of
865	   [I-D.ietf-httpbis-header-structure]).  Its ABNF is:

867	   Accept-Signature = sh-param-list

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

873	   Each identifier in the "Accept-Signature" header field's value
874	   indicates that a feature of the "Signature" header field
875	   (Section 3.1) is supported.  If the identifier begins with a "-"
876	   character, it instead indicates that the feature named by the rest of
877	   the identifier is not supported.  Unknown identifiers and parameters
878	   MUST be ignored because new identifiers and new parameters on
879	   existing identifiers may be defined by future specifications.

881	3.7.1.  Integrity identifiers

883	   Identifiers starting with "digest/" indicate that the client supports
884	   the "Digest" header field ([RFC3230]) with the parameter from the
885	   HTTP Digest Algorithm Values Registry [6] registry named in lower-
886	   case by the rest of the identifier.  For example, "digest/mi-blake2"
887	   indicates support for Merkle integrity with the as-yet-unspecified
888	   mi-blake2 parameter, and "-digest/mi-sha256" indicates non-support
889	   for Merkle integrity with the mi-sha256 content encoding.

891	   If the "Accept-Signature" header field is present, servers SHOULD
892	   assume support for "digest/mi-sha256" unless the header field states
893	   otherwise.

895	3.7.2.  Key type identifiers

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

901	   If the "Accept-Signature" header field is present, servers SHOULD
902	   assume support for "ecdsa/secp256r1" unless the header field states
903	   otherwise.

905	3.7.3.  Key value identifiers

907	   The "ed25519key" identifier has parameters indicating the public keys
908	   that will be used to validate the returned signature.  Each
909	   parameter's name is re-interpreted as a byte sequence (Section 3.10
910	   of [I-D.ietf-httpbis-header-structure]) encoding a prefix of the
911	   public key.  For example, if the client will validate signatures
912	   using the public key whose base64 encoding is
913	   "11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo=", valid "Accept-
914	   Signature" header fields include:

916	Accept-Signature: ..., ed25519key; *11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo=*
917	Accept-Signature: ..., ed25519key; *11qYAYKxCrfVS/7TyWQHOg==*
918	Accept-Signature: ..., ed25519key; *11qYAQ==*
919	Accept-Signature: ..., ed25519key; **
920	   but not

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

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

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

928	   because it doesn't start or end with the "*"s that indicate a byte
929	   sequence.

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

937	3.7.4.  Examples

939	   Accept-Signature: digest/mi-sha256

941	   states that the client will accept signatures with payload integrity
942	   assured by the "Digest" header and "mi-sha256" digest algorithm and
943	   implies that the client will accept signatures from ECDSA keys on the
944	   secp256r1 curve.

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

948	   states that the client will accept ECDSA keys on the secp384r1 curve
949	   but not the secp256r1 curve and payload integrity assured with the
950	   "Digest: mi-sha256" header field.

952	3.7.5.  Open Questions

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

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

963	   Do I have the right structure for the identifiers indicating feature
964	   support?

966	4.  Cross-origin trust

968	   To determine whether to trust a cross-origin exchange, the client
969	   takes a "Signature" header field (Section 3.1) and the exchange's

971	   o  "requestUrl", a byte sequence that can be parsed into the
972	      exchange's effective request URI (Section 5.5 of [RFC7230]),

974	   o  "responseHeaders", a byte sequence holding the canonical
975	      serialization (Section 3.4) of the CBOR representation
976	      (Section 3.2) of the exchange's response metadata and headers, and

978	   o  "payload", a stream of bytes constituting the exchange's payload
979	      body (Section 3.3 of [RFC7230]).

981	   The client MUST parse the "Signature" header into a list of
982	   signatures according to the instructions in Section 3.5, and run the
983	   following algorithm for each signature, stopping at the first one
984	   that returns "valid".  If any signature returns "valid", return
985	   "valid".  Otherwise, return "invalid".

987	   1.  If the signature's "validity-url" parameter (Paragraph 6) is not
988	       same-origin [7] with "requestUrl", return "invalid".

990	   2.  Use Section 3.5 to determine the signature's validity for
991	       "requestUrl", "responseHeaders", and "payload", getting
992	       "certificate-chain" back.  If this returned "invalid" or didn't
993	       return a certificate chain, return "invalid".

995	   3.  Let "response" be the response metadata and headers parsed out of
996	       "responseHeaders".

998	   4.  If Section 3 of [RFC7234] forbids a shared cache from storing
999	       "response", return "invalid".

1001	   5.  If "response"'s headers contain an uncached header field, as
1002	       defined in Section 4.1, return "invalid".

1004	   6.  Let "authority" be the host component of "requestUrl".

1006	   7.  Validate the "certificate-chain" using the following substeps.
1007	       If any of them fail, re-run Section 3.5 once over the signature
1008	       with the "forceFetch" flag set, and restart from step 2.  If a
1009	       substep fails again, return "invalid".

1011	       1.  Use "certificate-chain" to validate that its first entry,
1012	           "main-certificate" is trusted as "authority"'s server
1013	           certificate ([RFC5280] and other undocumented conventions).

1015	           Let "path" be the path that was used from the "main-
1016	           certificate" to a trusted root, including the "main-
1017	           certificate" but excluding the root.

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

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

1029	       4.  Validate that valid SCTs from trusted logs are available from
1030	           any of:

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

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

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

1041	           as described by Section 3.3 of [RFC6962].

1043	   8.  Return "valid".

1045	4.1.  Uncached header fields

1047	   Hop-by-hop and other uncached headers MUST NOT appear in a signed
1048	   exchange.  These will eventually be listed in
1049	   [I-D.ietf-httpbis-cache], but for now they're listed here:

1051	   o  Hop-by-hop header fields listed in the Connection header field
1052	      (Section 6.1 of [RFC7230]).

1054	   o  Header fields listed in the no-cache response directive in the
1055	      Cache-Control header field (Section 5.2.2.2 of [RFC7234]).

1057	   o  Header fields defined as hop-by-hop:

1059	      *  Connection

1061	      *  Keep-Alive
1062	      *  Proxy-Connection

1064	      *  Trailer

1066	      *  Transfer-Encoding

1068	      *  Upgrade

1070	   o  Stateful headers as defined below.

1072	4.1.1.  Stateful header fields

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

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

1084	   o  "Authentication-Control", [RFC8053]

1086	   o  "Authentication-Info", [RFC7615]

1088	   o  "Clear-Site-Data", [W3C.WD-clear-site-data-20171130]

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

1092	   o  "Proxy-Authenticate", [RFC7235]

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

1096	   o  "Public-Key-Pins", [RFC7469]

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

1100	   o  "Set-Cookie", [RFC6265]

1102	   o  "Set-Cookie2", [RFC2965]

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

1106	   o  "Strict-Transport-Security", [RFC6797]

1108	   o  "WWW-Authenticate", [RFC7235]

1110	4.2.  Certificate Requirements

1112	   We define a new X.509 extension, CanSignHttpExchanges to be used in
1113	   the certificate when the certificate permits the usage of signed
1114	   exchanges.  When this extension is not present the client MUST NOT
1115	   accept a signature from the certificate as proof that a signed
1116	   exchange is authoritative for a domain covered by the certificate.
1117	   When it is present, the client MUST follow the validation procedure
1118	   in Section 4.

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

1122	      CanSignHttpExchanges ::= NULL

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

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

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

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

1138	   Certificates with this extension MUST have a Validity Period no
1139	   greater than 90 days.

1141	   Conforming CAs MUST NOT mark this extension as critical.

1143	   A conforming CA MUST NOT issue certificates with this extension
1144	   unless, for each dNSName in the subjectAltName extension of the
1145	   certificate to be issued:

1147	   1.  An "issue" or "issuewild" CAA property ([RFC6844]) exists that
1148	       authorizes the CA to issue the certificate; and

1150	   2.  The "cansignhttpexchanges" parameter (Section 4.2.1) is present
1151	       on the property and is equal to "yes"

1153	   Clients MUST NOT accept certificates with this extension in TLS
1154	   connections (Section 4.4.2.2 of [RFC8446]).

1156	   RFC EDITOR PLEASE DELETE THE REST OF THE PARAGRAPHS IN THIS SECTION
1157	   id-ce-google OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 11129 }
1158	   id-ce-canSignHttpExchangesDraft OBJECT IDENTIFIER ::= { id-ce-google 2 1 22 }

1160	   Implementations of drafts of this specification MAY recognize the
1161	   "id-ce-canSignHttpExchangesDraft" OID as identifying the
1162	   CanSignHttpExchanges extension.  This OID might or might not be used
1163	   as the final OID for the extension, so certificates including it
1164	   might need to be reissued once the final RFC is published.

1166	   Some certificates have already been issued with this extension and
1167	   with validity periods longer than 90 days.  These certificates will
1168	   not immediately be treated as invalid.  Instead:

1170	   o  Clients MUST reject certificates with this extension that were
1171	      issued after 2019-05-01 and have a Validity Period longer than 90
1172	      days.

1174	   o  After 2019-08-01, clients MUST reject all certificates with this
1175	      extension that have a Validity Period longer than 90 days.

1177	   The above requirements on CAs to limit the Validity Period and check
1178	   for a CAA parameter are effective starting 2019-05-01.

1180	4.2.1.  Extensions to the CAA Record: cansignhttpexchanges Parameter

1182	   A CAA parameter "cansignhttpexchanges" is defined for the "issue" and
1183	   "issuewild" properties defined by [RFC6844].  The value of this
1184	   parameter, if specified, MUST be "yes".

1186	5.  Transferring a signed exchange

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

1191	5.1.  Same-origin response

1193	   The signature for a signed exchange can be included in a normal HTTP
1194	   response.  Because different clients send different request header
1195	   fields, clients don't know how the server's content negotiation
1196	   algorithm works, and intermediate servers add response header fields,
1197	   it can be impossible to have a signature for the exchange's exact
1198	   request, content negotiation, and response.  Therefore, when a client
1199	   calls the validation procedure in Section 3.5) to validate the
1200	   "Signature" header field for an exchange represented as a normal HTTP
1201	   request/response pair, it MUST pass:

1203	   o  The "Signature" header field,
1204	   o  The effective request URI (Section 5.5 of [RFC7230]) of the
1205	      request,

1207	   o  The serialized headers defined by Section 5.1.1, and

1209	   o  The response's payload.

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

1215	   If the signed response includes a "Variants" header field, the client
1216	   MUST use the cache behavior algorithm in Section 4 of
1217	   [I-D.ietf-httpbis-variants] to check that the signed response is an
1218	   appropriate representation for the request the client is trying to
1219	   fulfil.  If the response is not an appropriate representation, the
1220	   client MUST treat the signature as invalid.

1222	5.1.1.  Serialized headers for a same-origin response

1224	   The serialized headers of an exchange represented as a normal HTTP
1225	   request/response pair (Section 2.1 of [RFC7230] or Section 8.1 of
1226	   [RFC7540]) are the canonical serialization (Section 3.4) of the CBOR
1227	   representation (Section 3.2) of the response status code (Section 6
1228	   of [RFC7231]) and the response header fields whose names are listed
1229	   in that response's "Signed-Headers" header field (Section 5.1.2).  If
1230	   a response header field name from "Signed-Headers" does not appear in
1231	   the response's header fields, the exchange has no serialized headers.

1233	   If the exchange's "Signed-Headers" header field is not present,
1234	   doesn't parse as a Structured Header
1235	   ([I-D.ietf-httpbis-header-structure]) or doesn't follow the
1236	   constraints on its value described in Section 5.1.2, the exchange has
1237	   no serialized headers.

1239	5.1.1.1.  Open Questions

1241	   Do the serialized headers of an exchange need to include the "Signed-
1242	   Headers" header field itself?

1244	5.1.2.  The Signed-Headers Header

1246	   The "Signed-Headers" header field identifies an ordered list of
1247	   response header fields to include in a signature.  The request URL
1248	   and response status are included unconditionally.  This allows a TLS-
1249	   terminating intermediate to reorder headers without breaking the
1250	   signature.  This _can_ also allow the intermediate to add headers
1251	   that will be ignored by some higher-level protocols, but Section 3.5
1252	   provides a hook to let other higher-level protocols reject such
1253	   insecure headers.

1255	   This header field appears once instead of being incorporated into the
1256	   signatures' parameters because the signed header fields need to be
1257	   consistent across all signatures of an exchange, to avoid forcing
1258	   higher-level protocols to merge the header field lists of valid
1259	   signatures.

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

1265	   Signed-Headers = sh-list

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

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

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

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

1282	5.2.1.  Indicating support for cross-origin Server Push

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

1288	   An ENABLE_CROSS_ORIGIN_PUSH value of 0 indicates that the client does
1289	   not support cross-origin Push.  A value of 1 indicates that the
1290	   client does support cross-origin Push.

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

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

1304	5.2.2.  NO_TRUSTED_EXCHANGE_SIGNATURE error code

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

1313	5.2.2.1.  Open Questions

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

1317	5.2.3.  Validating a cross-origin Push

1319	   If the client has set the ENABLE_CROSS_ORIGIN_PUSH setting to 1, the
1320	   server MAY Push a signed exchange for which it is not authoritative,
1321	   and the client MUST NOT treat a PUSH_PROMISE for which the server is
1322	   not authoritative as a stream error (Section 5.4.2 of [RFC7540]) of
1323	   type PROTOCOL_ERROR, as described in Section 8.2 of [RFC7540], unless
1324	   there is another error as described below.

1326	   Instead, the client MUST validate such a PUSH_PROMISE and its
1327	   response against the following list:

1329	   1.  If the PUSH_PROMISE includes any non-pseudo request header
1330	       fields, the client MUST treat it as a stream error (Section 5.4.2
1331	       of [RFC7540]) of type PROTOCOL_ERROR.

1333	   2.  If the PUSH_PROMISE's method is not "GET", the client MUST treat
1334	       it as a stream error (Section 5.4.2 of [RFC7540]) of type
1335	       PROTOCOL_ERROR.

1337	   3.  Run the algorithm in Section 4 over:

1339	       *  The "Signature" header field from the response.

1341	       *  The effective request URI from the PUSH_PROMISE.

1343	       *  The canonical serialization (Section 3.4) of the CBOR
1344	          representation (Section 3.2) of the pushed response's status
1345	          and its headers except for the "Signature" header field.

1347	       *  The response's payload.

1349	       If this returns "invalid", the client MUST treat the response as
1350	       a stream error (Section 5.4.2 of [RFC7540]) of type
1351	       NO_TRUSTED_EXCHANGE_SIGNATURE.  Otherwise, the client MUST treat
1352	       the pushed response as if the server were authoritative for the
1353	       PUSH_PROMISE's authority.

1355	5.2.3.1.  Open Questions

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

1362	5.3.  application/signed-exchange format

1364	   To allow signed exchanges to be the targets of "<link rel=prefetch>"
1365	   tags, we define the "application/signed-exchange" content type that
1366	   represents a signed HTTP exchange, including a request URL, response
1367	   metadata and header fields, and a response payload.

1369	   When served over HTTP, a response containing an "application/signed-
1370	   exchange" payload MUST include at least the following response header
1371	   fields, to reduce content sniffing vulnerabilities (Section 6.8):

1373	   o  Content-Type: application/signed-exchange;v=_version_

1375	   o  X-Content-Type-Options: nosniff

1377	   This content type consists of the concatenation of the following
1378	   items:

1380	   1.  8 bytes consisting of the ASCII characters "sxg1" followed by 4
1381	       0x00 bytes, to serve as a file signature.  This is redundant with
1382	       the MIME type, and recipients that receive both MUST check that
1383	       they match and stop parsing if they don't.

1385	       Note: RFC EDITOR PLEASE DELETE THIS NOTE; The implementation of
1386	       the final RFC MUST use this file signature, but implementations
1387	       of drafts MUST NOT use it and MUST use another implementation-
1388	       specific 8-byte string beginning with "sxg1-".

1390	   2.  2 bytes storing a big-endian integer "fallbackUrlLength".

1392	   3.  "fallbackUrlLength" bytes holding a "fallbackUrl", which MUST
1393	       UTF-8 decode to an absolute URL with a scheme of "https".

1395	       Note: The byte location of the fallback URL is intended to remain
1396	       invariant across versions of the "application/signed-exchange"
1397	       format so that parsers encountering unknown versions can always
1398	       find a URL to redirect to.

1400	       Issue: Should this fallback information also include the method?

1402	   4.  3 bytes storing a big-endian integer "sigLength".  If this is
1403	       larger than 16384 (16*1024), parsing MUST fail.

1405	   5.  3 bytes storing a big-endian integer "headerLength".  If this is
1406	       larger than 524288 (512*1024), parsing MUST fail.

1408	   6.  "sigLength" bytes holding the "Signature" header field's value
1409	       (Section 3.1).

1411	   7.  "headerLength" bytes holding "signedHeaders", the canonical
1412	       serialization (Section 3.4) of the CBOR representation of the
1413	       response headers of the exchange represented by the "application/
1414	       signed-exchange" resource (Section 3.2), excluding the
1415	       "Signature" header field.

1417	   8.  The payload body (Section 3.3 of [RFC7230]) of the exchange
1418	       represented by the "application/signed-exchange" resource.

1420	       Note that the use of the payload body here means that a
1421	       "Transfer-Encoding" header field inside the "application/signed-
1422	       exchange" header block has no effect.  A "Transfer-Encoding"
1423	       header field on the outer HTTP response that transfers this
1424	       resource still has its normal effect.

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

1428	   To determine whether to trust a cross-origin exchange stored in an
1429	   "application/signed-exchange" resource, pass the "Signature" header
1430	   field's value, "fallbackUrl" as the effective request URI,
1431	   "signedHeaders", and the payload body to the algorithm in Section 4.

1433	5.3.2.  Example

1435	   An example "application/signed-exchange" file representing a possible
1436	   signed exchange with https://example.com/ [8] follows, with lengths
1437	   represented by descriptions in "<>"s, CBOR represented in the
1438	   extended diagnostic format defined in Appendix G of [CDDL], and most
1439	   of the "Signature" header field and payload elided with a ...:

1441	   sxg1\0\0\0\0<2-byte length of the following url string>
1442	   https://example.com/<3-byte length of the following header
1443	   value><3-byte length of the encoding of the
1444	   following map>sig1; sig=*...; integrity="digest/mi-sha256"; ...{
1445	     ':status': '200',
1446	     'content-type': 'text/html'
1447	   }<!doctype html>\r\n<html>...

1449	5.3.3.  Open Questions

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

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

1456	6.  Security considerations

1458	6.1.  Over-signing

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

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

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

1474	   2.  Only sign exchanges where the response includes a "Cache-Control:
1475	       public" header.  Clients are not required to fail signature-
1476	       checking for exchanges that omit this "Cache-Control" response
1477	       header field to reduce the risk that naive signing systems
1478	       blindly add it.

1480	6.1.1.  Session fixation

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

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

1493	6.1.2.  Misleading content

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

1500	   Stripping authentication information from requests before sending
1501	   them to backends is likely to prevent the backend from showing
1502	   attacker-specific information in the signed response.  It does not
1503	   prevent the attacker from showing their victim a signed-out page when
1504	   the victim is actually signed in, but while this is still misleading,
1505	   it seems less likely to be useful to the attacker.

1507	6.2.  Off-path attackers

1509	   Relaxing the requirement to consult DNS when determining authority
1510	   for an origin means that an attacker who possesses a valid
1511	   certificate no longer needs to be on-path to redirect traffic to
1512	   them; instead of modifying DNS or IP routing, they need only convince
1513	   the user to visit another Web site in order to serve responses signed
1514	   as the target.  This consideration and mitigations for it are shared
1515	   by the combination of [RFC8336] and
1516	   [I-D.ietf-httpbis-http2-secondary-certs], and are discussed further
1517	   in [I-D.bishop-httpbis-origin-fed-up].

1519	6.2.1.  Mis-issued certificates

1521	   If a CA mis-issues a certificate for a domain, this specification
1522	   provides a way to detect the mis-issuance and mitigate harm within
1523	   approximately two weeks.  Specifically, because all signed exchanges
1524	   must include a "SignedCertificateTimestampList" ([RFC6962], a CT log
1525	   has promised to publish the mis-issued certificate within that log's
1526	   Maximum Merge Delay, 1 day for many logs.  The domain owner can then
1527	   detect the mis-issued certificate and notify the CA to revoke it,
1528	   which the [BRs], section 4.9.1.1, say they must do within another 5
1529	   days.

1531	   Once the mis-issued certificate is revoked, existing OCSP responses
1532	   begin to expire.  The [BRs], section 4.9.10, require that OCSP
1533	   responses have a maximum expiration time of 10 days, after which they
1534	   can't be used to validate a certificate chain (Section 3.3).  This
1535	   leads to a total compromised time of 16 days after a mis-issuance.

1537	   However, CAs might future-date their OCSP responses, in which case
1538	   the mitigation doesn't work.

1540	   CAs are forbidden from future-dating their OCSP responses by the
1541	   [BRs] section 4.9.9, "OCSP responses MUST conform to RFC6960 and/or
1542	   RFC5019."  [RFC6960] includes, "The time at which the status was
1543	   known to be correct SHALL be reflected in the thisUpdate field of the
1544	   response.", and [RFC5019] includes, "When pre-producing OCSPResponse
1545	   messages, the responder MUST set the thisUpdate, nextUpdate, and
1546	   producedAt times as follows: thisUpdate: The time at which the status
1547	   being indicated is known to be correct."

1549	   However, if a CA violates the [BRs] to sign future-dated OCSP
1550	   responses, attempts to keep the nonconformant OCSP responses private,
1551	   but then leaks them, it could cause clients to trust a hostile signed
1552	   exchange long after its certificate has been revoked.

1554	   Clients could use systems like [CRLSets] and [OneCrl] to revoke the
1555	   intermediate certificate that signed the future-dated OCSP responses.

1557	6.2.2.  Stolen private keys

1559	   If the private key for a CanSignHttpExchanges certificate is stolen,
1560	   it can be used at scale until the certificate expires or is revoked,
1561	   and unlike for a stolen key for a normal TLS-terminating certificate,
1562	   the rightful owner can't detect the problem by watching for attacks
1563	   on the DNS or routing infrastructure.

1565	   This specification does not currently propose a way for the rightful
1566	   owner to detect that their keys are being used by an attacker, after
1567	   they've opted into the risk by requesting a CanSignHttpExchanges
1568	   certificate in the first place.  Clients can fetch a signature's
1569	   "validity-url" (Section 3.1) to help owners detect key compromise,
1570	   but that compromises some of the privacy properties of this
1571	   specification.

1573	6.3.  Downgrades

1575	   Signing a bad response can affect more users than simply serving a
1576	   bad response, since a served response will only affect users who make
1577	   a request while the bad version is live, while an attacker can
1578	   forward a signed response until its signature expires.  Publishers
1579	   should consider shorter signature expiration times than they use for
1580	   cache expiration times.

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

1588	6.4.  Signing oracles are permanent

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

1598	6.5.  Unsigned headers

1600	   The use of a single "Signed-Headers" header field prevents us from
1601	   signing aspects of the request other than its effective request URI
1602	   (Section 5.5 of [RFC7230]).  For example, if a publisher signs both
1603	   "Content-Encoding: br" and "Content-Encoding: gzip" variants of a
1604	   response, what's the impact if an attacker serves the brotli one for
1605	   a request with "Accept-Encoding: gzip"?  This is mitigated by using
1606	   [I-D.ietf-httpbis-variants] instead of request headers to describe
1607	   how the client should run content negotiation.

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

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

1621	6.6.  application/signed-exchange

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

1629	6.7.  Key re-use with TLS

1631	   In general, key re-use across multiple protocols is a bad idea.

1633	   Using an exchange-signing key in a TLS (or other directly-internet-
1634	   facing) server increases the risk that an attacker can steal the
1635	   private key, which will allow them to mint packages (similar to
1636	   Section 6.4) until their theft is discovered.

1638	   Using a TLS key in a CanSignHttpExchanges certificate makes it less
1639	   likely that the server operator will discover key theft, due to the
1640	   considerations in Section 6.2.

1642	   This specification uses the CanSignHttpExchanges X.509 extension
1643	   (Section 4.2) to discourage re-use of TLS keys to sign exchanges or
1644	   vice-versa.

1646	   We require that clients reject certificates with the
1647	   CanSignHttpExchanges extension when making TLS connections to
1648	   minimize the chance that servers will re-use keys like this.
1649	   Ideally, we would make the extension critical so that even clients
1650	   that don't understand it would reject such TLS connections, but this
1651	   proved impossible because certificate-validating libraries ship on
1652	   significantly different schedules from the clients that use them.

1654	   Even once all clients reject these certificates in TLS connections,
1655	   this will still just discourage and not prevent key re-use, since a
1656	   server operator can unwisely request two different certificates with
1657	   the same private key.

1659	6.8.  Content sniffing

1661	   While modern browsers tend to trust the "Content-Type" header sent
1662	   with a resource, especially when accompanied by "X-Content-Type-
1663	   Options: nosniff", plugins will sometimes search for executable
1664	   content buried inside a resource and execute it in the context of the
1665	   origin that served the resource, leading to XSS vulnerabilities.  For
1666	   example, some PDF reader plugins look for "%PDF" anywhere in the
1667	   first 1kB and execute the code that follows it.

1669	   The "application/signed-exchange" format (Section 5.3) includes a URL
1670	   and response headers early in the format, which an attacker could use
1671	   to cause these plugins to sniff a bad content type.

1673	   To avoid vulnerabilities, in addition to the response header
1674	   requirements in Section 5.3, servers are advised to only serve an
1675	   "application/signed-exchange" resource (SXG) from a domain if it
1676	   would also be safe for that domain to serve the SXG's content
1677	   directly, and to follow at least one of the following strategies:

1679	   1.  Only serve signed exchanges from dedicated domains that don't
1680	       have access to sensitive cookies or user storage.

1682	   2.  Generate signed exchanges "offline", that is, in response to a
1683	       trusted author submitting content or existing signatures reaching
1684	       a certain age, rather than in response to untrusted-reader
1685	       queries.

1687	   3.  Do all of:

1689	       1.  If the SXG's fallback URL (Section 5.3) is derived from the
1690	           request URL, percent-encode [9] ([URL]) any bytes that are
1691	           greater than 0x7E or are not URL code points [10] ([URL]) in
1692	           the fallback URL . It is particularly important to make sure
1693	           no unescaped nulls (0x00) or angle brackets (0x3C and 0x3E)
1694	           appear.

1696	       2.  Do not reflect request header fields into the set of response
1697	           headers.

1699	   There are still a few binary length fields that an attacker may
1700	   influence to contain sensitive bytes, but they're always followed by
1701	   lowercase alphabetic strings from a small set of possibilities, which
1702	   reduces the chance that a client will sniff them as indicating a
1703	   particular content type.

1705	   To encourage servers to include the "X-Content-Type-Options: nosniff"
1706	   header field, clients SHOULD reject signed exchanges served without
1707	   it.

1709	7.  Privacy considerations

1711	7.1.  Visibility of resource requests

1713	   Normally, when a client follows a link from https://source.example/
1714	   page.html to "https://publisher.example/page.html",
1715	   "publisher.example" learns that the client is interested in the
1716	   resource. "source.example" also has several ways of discovering that
1717	   the client has clicked the link, including the use of Javascript to
1718	   record the click or having the link point to a URL that serves a 302
1719	   redirect to the real target.

1721	   If "publisher.example" signs "page.html" into "page.sxg",
1722	   "distributor.example" serves it as
1723	   "https://distributor.example/publisher/page.sxg", and the client
1724	   fetches it from there, then "distributor.example" learns that the
1725	   client is interested, and if the client executes some Javascript on
1726	   the page or makes subresource requests, that could also report the
1727	   client's interest back to "publisher.example".

1729	   To prevent network operators other than "distributor.example" or
1730	   "publisher.example" from learning which exchanges were read, clients
1731	   SHOULD only load exchanges fetched over a transport that's protected
1732	   from eavesdroppers.  This can be difficult to determine when the
1733	   exchange is being loaded from local disk, but when the client itself
1734	   requested the exchange over a network it SHOULD require TLS
1735	   ([RFC8446]) or a successor transport layer, and MUST NOT accept
1736	   exchanges transferred over plain HTTP without TLS.

1738	   If "source.example" and "distributor.example" are controlled by the
1739	   same entity, no extra information escapes here.  If they are run by
1740	   different entities, a similar amount of information escapes as if
1741	   "source.example" had implemented its click tracking by outsourcing to
1742	   a service like https://bit.ly/ [11].

1744	   There has been discussion of allowing a publisher to restrict the set
1745	   of distributors that can host its signed content.  If that's added,
1746	   then the privacy situation becomes more similar to the situation with
1747	   CDNs, where a publisher chooses a CDN to serve their content, and the
1748	   CDN learns about all requests for that content.  Here the publisher
1749	   would choose one or more distributors, and the distributor(s) would
1750	   learn about requests for the content.

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

1756	7.2.  User ID transfer

1758	   If a request for "https://distributor.example/publisher/page.sxg"
1759	   comes with the source's or distributor's user ID for the user, either
1760	   because it's sent with the distributor's cookies or because the
1761	   source stashes an encoded user ID into either the request's path or a
1762	   subdomain, the distributor has a few ways to pass that user ID on to
1763	   the publisher that signed the page:

1765	   1.  If the distributor has the publisher's signing keys, it can sign
1766	       a new page with its user ID directly embedded.

1768	   2.  Otherwise, the publisher can sign lots of copies of their
1769	       package, and the distributor can choose a particular copy to send
1770	       a subset of the bits in its user ID to the publisher on each
1771	       click, which will eventually transfer the whole thing.

1773	   To prevent this, the request for a signed exchange needs to omit
1774	   credentials and block them from appearing in the URL in the same way
1775	   it would block them from appearing in a cross-origin URL.  We're
1776	   exploring ways the link can mark the request so user agents can take
1777	   the right counter-measures.

1779	8.  IANA considerations

1781	   TODO: possibly register the validity-url format.

1783	8.1.  Signature Header Field Registration

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

1788	   Header field name: "Signature"

1790	   Applicable protocol: http

1792	   Status: standard

1794	   Author/Change controller: IETF

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

1798	8.2.  Accept-Signature Header Field Registration

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

1803	   Header field name: "Accept-Signature"

1805	   Applicable protocol: http

1807	   Status: standard

1809	   Author/Change controller: IETF

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

1813	8.3.  Signed-Headers Header Field Registration

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

1818	   Header field name: "Signed-Headers"

1820	   Applicable protocol: http
1821	   Status: standard

1823	   Author/Change controller: IETF

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

1827	8.4.  HTTP/2 Settings

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

1832	   Name: ENABLE_CROSS_ORIGIN_PUSH

1834	   Code: 0xSETTING-TBD

1836	   Initial Value: 0

1838	   Specification: This document

1840	8.5.  HTTP/2 Error code

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

1845	   Name: NO_TRUSTED_EXCHANGE_SIGNATURE

1847	   Code: 0xERROR-TBD

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

1852	   Specification: This document

1854	8.6.  Internet Media Type application/signed-exchange

1856	   IANA is requested to register the MIME media type
1857	   ([IANA.media-types]) for signed exchanges, application/signed-
1858	   exchange, as follows:

1860	   Type name: application

1862	   Subtype name: signed-exchange

1864	   Required parameters:

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

1874	      Note: RFC EDITOR PLEASE DELETE THIS NOTE; Implementations of
1875	      drafts of this specification MUST NOT use simple integers to
1876	      describe their versions, and MUST instead define implementation-
1877	      specific strings to identify which draft is implemented.  The
1878	      newest version of
1879	      [I-D.yasskin-httpbis-origin-signed-exchanges-impl] describes the
1880	      meaning of one such string.

1882	   Optional parameters: N/A

1884	   Encoding considerations: binary

1886	   Security considerations: see Section 6.6

1888	   Interoperability considerations: N/A

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

1892	   Applications that use this media type: N/A

1894	   Fragment identifier considerations: N/A

1896	   Additional information:

1898	   Deprecated alias names for this type: N/A

1900	   Magic number(s): 73 78 67 31 00

1902	   File extension(s): .sxg

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

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

1909	   Intended usage: COMMON

1911	   Restrictions on usage: N/A

1913	   Author: See Authors' Addresses section.

1915	   Change controller: IESG
1916	   Provisional registration?  Yes

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

1920	   IANA is requested to register the MIME media type
1921	   ([IANA.media-types]) for CBOR-format certificate chains, application/
1922	   cert-chain+cbor, as follows:

1924	   Type name: application

1926	   Subtype name: cert-chain+cbor

1928	   Required parameters: N/A

1930	   Optional parameters: N/A

1932	   Encoding considerations: binary

1934	   Security considerations: N/A

1936	   Interoperability considerations: N/A

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

1940	   Applications that use this media type: N/A

1942	   Fragment identifier considerations: N/A

1944	   Additional information:

1946	   Deprecated alias names for this type: N/A

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

1950	   File extension(s): N/A

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

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

1957	   Intended usage: COMMON

1959	   Restrictions on usage: N/A

1961	   Author: See Authors' Addresses section.

1963	   Change controller: IESG
1964	   Provisional registration?  Yes

1966	8.8.  The cansignhttpexchanges CAA Parameter

1968	   There are no IANA considerations for this parameter.

1970	9.  References

1972	9.1.  Normative References

1974	   [CDDL]     Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
1975	              Definition Language (CDDL): A Notational Convention to
1976	              Express Concise Binary Object Representation (CBOR) and
1977	              JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
1978	              June 2019, <https://www.rfc-editor.org/info/rfc8610>.

1980	   [FETCH]    WHATWG, "Fetch", November 2019,
1981	              <https://fetch.spec.whatwg.org/>.

1983	   [I-D.ietf-httpbis-header-structure]
1984	              Nottingham, M. and P. Kamp, "Structured Headers for HTTP",
1985	              draft-ietf-httpbis-header-structure-14 (work in progress),
1986	              October 2019.

1988	   [I-D.ietf-httpbis-variants]
1989	              Nottingham, M., "HTTP Representation Variants", draft-
1990	              ietf-httpbis-variants-05 (work in progress), March 2019.

1992	   [I-D.thomson-http-mice]
1993	              Thomson, M. and J. Yasskin, "Merkle Integrity Content
1994	              Encoding", draft-thomson-http-mice-03 (work in progress),
1995	              August 2018.

1997	   [IANA.media-types]
1998	              IANA, "Media Types",
1999	              <http://www.iana.org/assignments/media-types>.

2001	   [POSIX]    IEEE and The Open Group, "The Open Group Base
2002	              Specifications Issue 7", name IEEE, value 1003.1-2008,
2003	              2016 Edition, 2016,
2004	              <http://pubs.opengroup.org/onlinepubs/9699919799/
2005	              basedefs/>.

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

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

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

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

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

2032	   [RFC6844]  Hallam-Baker, P. and R. Stradling, "DNS Certification
2033	              Authority Authorization (CAA) Resource Record", RFC 6844,
2034	              DOI 10.17487/RFC6844, January 2013,
2035	              <https://www.rfc-editor.org/info/rfc6844>.

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

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

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

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

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

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

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

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

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

2080	   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
2081	              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
2082	              <https://www.rfc-editor.org/info/rfc8446>.

2084	   [URL]      WHATWG, "URL", November 2019,
2085	              <https://url.spec.whatwg.org/>.

2087	9.2.  Informative References

2089	   [BRs]      CA/Browser Forum, "Baseline Requirements for the Issuance
2090	              and Management of Publicly-Trusted Certificates", December
2091	              2018,
2092	              <https://cabforum.org/baseline-requirements-documents/>.

2094	   [CRLSets]  Langley, A., "Revocation checking and Chrome's CRL",
2095	              February 2012,
2096	              <https://www.imperialviolet.org/2012/02/05/crlsets.html>.

2098	   [I-D.bishop-httpbis-origin-fed-up]
2099	              Bishop, M. and E. Nygren, "DNS Security with HTTP/2
2100	              ORIGIN", draft-bishop-httpbis-origin-fed-up-00 (work in
2101	              progress), January 2019.

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

2107	   [I-D.cavage-http-signatures]
2108	              Cavage, M. and M. Sporny, "Signing HTTP Messages", draft-
2109	              cavage-http-signatures-12 (work in progress), October
2110	              2019.

2112	   [I-D.ietf-httpbis-cache]
2113	              Fielding, R., Nottingham, M., and J. Reschke, "HTTP
2114	              Caching", draft-ietf-httpbis-cache-05 (work in progress),
2115	              July 2019.

2117	   [I-D.ietf-httpbis-http2-secondary-certs]
2118	              Bishop, M., Sullivan, N., and M. Thomson, "Secondary
2119	              Certificate Authentication in HTTP/2", draft-ietf-httpbis-
2120	              http2-secondary-certs-05 (work in progress), November
2121	              2019.

2123	   [I-D.thomson-http-content-signature]
2124	              Thomson, M., "Content-Signature Header Field for HTTP",
2125	              draft-thomson-http-content-signature-00 (work in
2126	              progress), July 2015.

2128	   [I-D.yasskin-httpbis-origin-signed-exchanges-impl]
2129	              Yasskin, J. and K. Ueno, "Signed HTTP Exchanges
2130	              Implementation Checkpoints", draft-yasskin-httpbis-origin-
2131	              signed-exchanges-impl-03 (work in progress), July 2019.

2133	   [I-D.yasskin-wpack-use-cases]
2134	              Yasskin, J., "Use Cases and Requirements for Web
2135	              Packages", draft-yasskin-wpack-use-cases-00 (work in
2136	              progress), October 2019.

2138	   [OneCrl]   Goodwin, M., "Revoking Intermediate Certificates:
2139	              Introducing OneCRL", March 2015,
2140	              <https://blog.mozilla.org/security/2015/03/03/revoking-
2141	              intermediate-certificates-introducing-onecrl/>.

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

2147	   [RFC5019]  Deacon, A. and R. Hurst, "The Lightweight Online
2148	              Certificate Status Protocol (OCSP) Profile for High-Volume
2149	              Environments", RFC 5019, DOI 10.17487/RFC5019, September
2150	              2007, <https://www.rfc-editor.org/info/rfc5019>.

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

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

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

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

2169	   [RFC6797]  Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
2170	              Transport Security (HSTS)", RFC 6797,
2171	              DOI 10.17487/RFC6797, November 2012,
2172	              <https://www.rfc-editor.org/info/rfc6797>.

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

2179	   [RFC7469]  Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
2180	              Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
2181	              2015, <https://www.rfc-editor.org/info/rfc7469>.

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

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

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

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

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

2207	   [W3C.NOTE-OPS-OverHTTP]
2208	              Hensley, P., Metral, M., Shardanand, U., Converse, D., and
2209	              M. Myers, "Implementation of OPS Over HTTP", W3C NOTE
2210	              NOTE-OPS-OverHTTP, June 1997.

2212	   [W3C.WD-clear-site-data-20171130]
2213	              West, M., "Clear Site Data", World Wide Web Consortium WD
2214	              WD-clear-site-data-20171130, November 2017,
2215	              <https://www.w3.org/TR/2017/WD-clear-site-data-20171130>.

2217	9.3.  URIs

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

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

2223	   [3] https://url.spec.whatwg.org/#concept-url-parser

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

2227	   [5] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/
2228	       V1_chap04.html#tag_04_16

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

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

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

2236	   [9] https://url.spec.whatwg.org/#percent-encode

2238	   [10] https://url.spec.whatwg.org/#url-code-points

2240	   [11] https://bit.ly/

2242	   [12] https://calendar.perfplanet.com/2013/big-bad-preloader/

2244	   [13] https://github.com/mikewest/signature-based-sri

2246	   [14] https://github.com/mikewest/signature-based-sri/issues/5

2248	   [15] https://www.apple.com/ios/app-store/

2250	   [16] https://play.google.com/store

2252	   [17] https://github.com/WICG/webpackage

2254	   [18] https://www.imperialviolet.org/2012/02/05/crlsets.html

2256	   [19] https://tlswg.github.io/tls13-spec/draft-ietf-tls-
2257	        tls13.html#ocsp-and-sct

2259	Appendix A.  Use cases

2261	A.1.  PUSHed subresources

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

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

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

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

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

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

2288	   <img logicalsrc="https://O.com/img.png"
2289	        physicalsrc="https://distributor.com/O.com/img.png">

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

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

2297	   where the "<dist-img>" implementation generates an appropriate
2298	   "<img>" based on, for example, a "<meta name="dist-base">" tag
2299	   elsewhere in the page.  However, this has the downside that the
2300	   preloader [12] can no longer see the physical source to download it.
2301	   The resulting delay might cancel out the benefit of using a
2302	   distributor.

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

2307	   To implement this with the current proposal, the distributor would
2308	   respond to the physical request to "https://distributor.com/O.com/
2309	   img.png" with first a signed PUSH_PROMISE for "https://O.com/img.png"
2310	   and then a redirect to "https://O.com/img.png".

2312	A.3.  Subresource Integrity

2314	   The W3C WebAppSec group is investigating using signatures [13] in
2315	   [SRI].  They need a way to transmit the signature with the response,
2316	   which this proposal provides.

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

2323	   The "ed25519key" signature parameter supports this simpler way of
2324	   attaching a key.

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

2333	A.4.  Binary Transparency

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

2342	   Certificate Transparency depends on Signed Certificate Timestamps
2343	   that prove a log contained a particular certificate at a particular
2344	   time.  To build the same thing for Binary Transparency logs
2345	   containing HTTP resources or full websites, we'll need a way to
2346	   provide signatures of those resources, which signed exchanges
2347	   provides.

2349	A.5.  Static Analysis

2351	   Native app stores like the Apple App Store [15] and the Android Play
2352	   Store [16] grant their contents powerful abilities, which they
2353	   attempt to make safe by analyzing the applications before offering
2354	   them to people.  The web has no equivalent way for people to wait to
2355	   run an update of a web application until a trusted authority has
2356	   vouched for it.

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

2363	A.6.  Offline websites

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

2370	Appendix B.  Requirements

2372	B.1.  Proof of origin

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

2380	B.1.1.  Certificate constraints

2382	   If we re-use existing TLS server certificates, we incur the risks
2383	   that:

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

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

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

2399	B.1.2.  Signature constraints

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

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

2411	   2.  Use the same format as TLS's signatures, specified in
2412	       Section 4.4.3 of [RFC8446], with a context string that's specific
2413	       to this use.

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

2419	B.1.3.  Retrieving the certificate

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

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

2439	   To avoid using an unintended certificate with the same public key as
2440	   the intended one, the content of the leaf certificate or the chain
2441	   should be included in the signed data, like TLS does (Section 4.4.3
2442	   of [RFC8446]).

2444	B.2.  How much to sign

2446	   The previous [I-D.thomson-http-content-signature] and
2447	   [I-D.burke-content-signature] schemes signed just the content, while
2448	   ([I-D.cavage-http-signatures] could also sign the response headers
2449	   and the request method and path.  However, the same path, response
2450	   headers, and content may mean something very different when retrieved
2451	   from a different server.  Section 5.1.1 currently includes the whole
2452	   request URL in the signature, but it's possible we need a more
2453	   flexible scheme to allow some higher-level protocols to accept a
2454	   less-signed URL.

2456	   Servers might want to sign other request headers in order to capture
2457	   their effects on content negotiation.  However, there's no standard
2458	   algorithm to check that a client's actual request headers match
2459	   request headers sent by a server.  The most promising attempt at this
2460	   is [I-D.ietf-httpbis-variants], which encodes the content negotiation
2461	   algorithm into the "Variants" and "Variant-Key" response headers.
2462	   The proposal here (Section 3) assumes that is in use and doesn't sign
2463	   request headers.

2465	B.2.1.  Conveying the signed headers

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

2474	   There's no way in current HTTP for the response to a client-initiated
2475	   request (Section 8.1 of [RFC7540]) to convey the request headers it
2476	   expected to respond to, but we sidestep that by conveying content
2477	   negotiation information in response headers, per
2478	   [I-D.ietf-httpbis-variants].

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

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

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

2494	B.3.  Response lifespan

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

2503	B.3.1.  Certificate revocation

2505	   Certificates are mis-issued and private keys are stolen, and in
2506	   response clients need to be able to stop trusting these certificates
2507	   as promptly as possible.  Online revocation checks don't work [18],
2508	   so the industry has moved to pushed revocation lists and stapled OCSP
2509	   responses [RFC6066].

2511	   Pushed revocation lists work as-is to block trust in the certificate
2512	   signing an exchange, but the signatures need an explicit strategy to
2513	   staple OCSP responses.  One option is to extend the certificate
2514	   download (Appendix B.1.3) to include the OCSP response too, perhaps
2515	   in the TLS 1.3 CertificateEntry [19] format.

2517	B.3.2.  Response downgrade attacks

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

2527	   These assertions could be structured as:

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

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

2540	   3.  A replacement for the exchange's signature and an update for the
2541	       embedded "expires" and related cache-control HTTP headers
2542	       [RFC7234].  This naturally extends publishers' intuitions about
2543	       cache expiration and the existing cache revalidation behavior to
2544	       signed exchanges.  This is sketched and its downsides explored in
2545	       Appendix C.

2547	   The signature also needs to include instructions to intermediates for
2548	   how to fetch updated validity assertions.

2550	B.4.  Low implementation complexity

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

2556	B.4.1.  Limited choices

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

2562	B.4.2.  Bounded-buffering integrity checking

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

2571	   To allow the network layer to verify signed exchanges using a bounded
2572	   amount of memory, Section 5.3 requires the signature to be less than
2573	   16kB and the headers to be less than 512kB, and Section 3.5 requires
2574	   that the MI record size be less than 16kB.  This allows the network
2575	   layer to validate a bounded chunk at a time, and pass that chunk on
2576	   to a renderer, and then forget about that chunk before processing the
2577	   next one.

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

2582	Appendix C.  Determining validity using cache control

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

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

2592	   The validity-checking algorithm (Section 3.5) would initialize "date"
2593	   from the resource's "Date" header field (Section 7.1.1.2 of
2594	   [RFC7231]) and initialize "expires" from either the "Expires" header
2595	   field (Section 5.3 of [RFC7234]) or the "Cache-Control" header
2596	   field's "max-age" directive (Section 5.2.2.8 of [RFC7234]) (added to
2597	   "date"), whichever is present, preferring "max-age" (or failing) if
2598	   both are present.

2600	   Validity updates (Section 3.6) would include a list of replacement
2601	   response header fields.  For each header field name in this list, the
2602	   client would remove matching header fields from the stored exchange's
2603	   response header fields.  Then the client would append the replacement
2604	   header fields to the stored exchange's response header fields.

2606	C.1.  Example of updating cache control

2608	   For example, given a stored exchange of:

2610	   GET  / HTTP/1.1
2611	   Host: example.com
2612	   Accept: */*

2614	   HTTP/1.1 200
2615	   Date: Mon, 20 Nov 2017 10:00:00 UTC
2616	   Content-Type: text/html
2617	   Date: Tue, 21 Nov 2017 10:00:00 UTC
2618	   Expires: Sun, 26 Nov 2017 10:00:00 UTC

2620	   <!doctype html>
2621	   <html>
2622	   ...

2624	   And an update listing the following headers:

2626	   Expires: Fri, 1 Dec 2017 10:00:00 UTC
2627	   Date: Sat, 25 Nov 2017 10:00:00 UTC

2629	   The resulting stored exchange would be:

2631	   GET / HTTP/1.1
2632	   Host: example.com
2633	   Accept: */*

2635	   HTTP/1.1 200
2636	   Content-Type: text/html
2637	   Expires: Fri, 1 Dec 2017 10:00:00 UTC
2638	   Date: Sat, 25 Nov 2017 10:00:00 UTC

2640	   <!doctype html>
2641	   <html>
2642	   ...

2644	C.2.  Downsides of updating cache control

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

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

2657	Appendix D.  Change Log

2659	   RFC EDITOR PLEASE DELETE THIS SECTION.

2661	   draft-08

2663	   o  Improve the privacy considerations.

2665	   draft-07

2667	   o  Provisionally register application/signed-exchange and
2668	      application/cert-chain+cbor.

2670	   draft-06

2672	   o  Add a security consideration for future-dated OCSP responses and
2673	      for stolen private keys.

2675	   o  Define a CAA parameter to opt into certificate issuance.

2677	   o  Limit certificate lifetimes to 90 days.

2679	   o  UTF-8 decode the fallback URL.

2681	   draft-05

2683	   o  Define absolute URLs, and limit the schemes each instance can use.

2685	   o  Fill in TBD size limits.

2687	   o  Update to mice-03 including the Digest header.

2689	   o  Refer to draft-yasskin-httpbis-origin-signed-exchanges-impl for
2690	      draft version numbers.

2692	   o  Require "exchange"'s response to be cachable by a shared cache.

2694	   o  Define the "integrity" field of the Signature header to include
2695	      subfields of the main integrity-protecting header, including the
2696	      digest algorithm.

2698	   o  Put a fallback URL at the beginning of the "application/signed-
2699	      exchange" format, which replaces the ':url' key from the CBOR
2700	      representation of the exchange's request and response metadata and
2701	      headers.

2703	   o  Remove the rest of the request headers from the signed data, in
2704	      favor of representing content negotiation with the "Variants"
2705	      response header.

2707	   o  Make the signed message format a concatenation of byte sequences,
2708	      which helps implementations avoid re-serializing the exchange's
2709	      request and response metadata and headers.

2711	   o  Explicitly check the response payload's integrity instead of
2712	      assuming the client did it elsewhere in processing the response.

2714	   o  Reject uncached header fields.

2716	   o  Update to draft-ietf-httpbis-header-structure-09.

2718	   o  Update to the final TLS 1.3 RFC.

2720	   draft-04

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

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

2727	      *  Doesn't require a streaming CBOR parser parse it from a network
2728	         stream.

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

2733	      *  Allows checking the signature before parsing the exchange
2734	         headers.

2736	   o  Require absolute URLs.

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

2741	   o  Switch back to the TLS 1.3 signature format.

2743	   o  Include the version and draft number in the signature context
2744	      string.

2746	   o  Remove support for integrity protection using the Digest header
2747	      field.

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

2751	   o  Forbid RSA keys, and only require clients to support secp256r1
2752	      keys.

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

2756	   draft-03

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

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

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

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

2773	   draft-02
2774	   o  Signatures identify a header (e.g.  Digest or MI) to guard the
2775	      payload's integrity instead of directly signing over the payload.

2777	   o  The validityUrl is signed.

2779	   o  Use CBOR maps where appropriate, and define how they're
2780	      canonicalized.

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

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

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

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

2794	   o  2 new use cases.

2796	Appendix E.  Acknowledgements

2798	   Thanks to Andrew Ayer, Devin Mullins, Ilari Liusvaara, John Wilander,
2799	   Justin Schuh, Mark Nottingham, Mike Bishop, Ryan Sleevi, and Yoav
2800	   Weiss for comments that improved this draft.

2802	Author's Address

2804	   Jeffrey Yasskin
2805	   Google

2807	   Email: jyasskin@chromium.org