idnits 2.17.1 

draft-yasskin-http-origin-signed-responses-09.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:
  ----------------------------------------------------------------------------

  == There is 1 instance of lines with non-ascii characters in the document.


  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.


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

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

  -- The document date (27 July 2020) is 1367 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: '100' on line 516

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

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

  -- 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-10

  == 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: 10 errors (**), 0 flaws (~~), 5 warnings (==), 10 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                            27 July 2020
5	Expires: 28 January 2021

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

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/
28	   (https://lists.w3.org/Archives/Public/ietf-http-wg/).

30	   The source code and issues list for this draft can be found in
31	   https://github.com/WICG/webpackage (https://github.com/WICG/
32	   webpackage).

34	Status of This Memo

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

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

44	   Internet-Drafts are draft documents valid for a maximum of six months
45	   and may be updated, replaced, or obsoleted by other documents at any
46	   time.  It is inappropriate to use Internet-Drafts as reference
47	   material or to cite them other than as "work in progress."
48	   This Internet-Draft will expire on 28 January 2021.

50	Copyright Notice

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

55	   This document is subject to BCP 78 and the IETF Trust's Legal
56	   Provisions Relating to IETF Documents (https://trustee.ietf.org/
57	   license-info) in effect on the date of publication of this document.
58	   Please review these documents carefully, as they describe your rights
59	   and restrictions with respect to this document.  Code Components
60	   extracted from this document must include Simplified BSD License text
61	   as described in Section 4.e of the Trust Legal Provisions and are
62	   provided without warranty as 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 . . . . . . . . . . . . . . . . . . . . . . .   9
74	     3.3.  Loading a certificate chain . . . . . . . . . . . . . . .  10
75	     3.4.  Canonical CBOR serialization  . . . . . . . . . . . . . .  11
76	     3.5.  Signature validity  . . . . . . . . . . . . . . . . . . .  12
77	       3.5.1.  Open Questions  . . . . . . . . . . . . . . . . . . .  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  . . . . . . . . . . . . . . . . . .  27
94	       5.1.1.  Serialized headers for a same-origin response . . . .  27
95	       5.1.2.  The Signed-Headers Header . . . . . . . . . . . . . .  28

97	     5.2.  HTTP/2 extension for cross-origin Server Push . . . . . .  28
98	       5.2.1.  Indicating support for cross-origin Server Push . . .  28
99	       5.2.2.  NO_TRUSTED_EXCHANGE_SIGNATURE error code  . . . . . .  29
100	       5.2.3.  Validating a cross-origin Push  . . . . . . . . . . .  29
101	     5.3.  application/signed-exchange format  . . . . . . . . . . .  30
102	       5.3.1.  Cross-origin trust in application/signed-exchange . .  31
103	       5.3.2.  Example . . . . . . . . . . . . . . . . . . . . . . .  32
104	       5.3.3.  Open Questions  . . . . . . . . . . . . . . . . . . .  32
105	   6.  Security considerations . . . . . . . . . . . . . . . . . . .  32
106	     6.1.  Over-signing  . . . . . . . . . . . . . . . . . . . . . .  32
107	       6.1.1.  Session fixation  . . . . . . . . . . . . . . . . . .  33
108	       6.1.2.  Misleading content  . . . . . . . . . . . . . . . . .  33
109	     6.2.  Off-path attackers  . . . . . . . . . . . . . . . . . . .  33
110	       6.2.1.  Mis-issued certificates . . . . . . . . . . . . . . .  33
111	       6.2.2.  Stolen private keys . . . . . . . . . . . . . . . . .  34
112	     6.3.  Downgrades  . . . . . . . . . . . . . . . . . . . . . . .  35
113	     6.4.  Signing oracles are permanent . . . . . . . . . . . . . .  35
114	     6.5.  Unsigned headers  . . . . . . . . . . . . . . . . . . . .  35
115	     6.6.  application/signed-exchange . . . . . . . . . . . . . . .  36
116	     6.7.  Key re-use with TLS . . . . . . . . . . . . . . . . . . .  36
117	     6.8.  Content sniffing  . . . . . . . . . . . . . . . . . . . .  36
118	   7.  Privacy considerations  . . . . . . . . . . . . . . . . . . .  37
119	     7.1.  Visibility of resource requests . . . . . . . . . . . . .  38
120	     7.2.  User ID transfer  . . . . . . . . . . . . . . . . . . . .  39
121	   8.  IANA considerations . . . . . . . . . . . . . . . . . . . . .  39
122	     8.1.  Signature Header Field Registration . . . . . . . . . . .  39
123	     8.2.  Accept-Signature Header Field Registration  . . . . . . .  39
124	     8.3.  Signed-Headers Header Field Registration  . . . . . . . .  40
125	     8.4.  HTTP/2 Settings . . . . . . . . . . . . . . . . . . . . .  40
126	     8.5.  HTTP/2 Error code . . . . . . . . . . . . . . . . . . . .  40
127	     8.6.  Internet Media Type application/signed-exchange . . . . .  41
128	     8.7.  Internet Media Type application/cert-chain+cbor . . . . .  42
129	     8.8.  The cansignhttpexchanges CAA Parameter  . . . . . . . . .  43
130	   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  43
131	     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  43
132	     9.2.  Informative References  . . . . . . . . . . . . . . . . .  46
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	   *  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	   *  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	   *  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
191	      (https://url.spec.whatwg.org/#concept-url-parser) ([URL]), when
192	      run without a base URL, returns a URL rather than a failure, and
193	      for which that URL has a null fragment.  This is similar to the
194	      absolute-URL string (https://url.spec.whatwg.org/#absolute-url-
195	      string) concept defined by ([URL]) but might not include exactly
196	      the same strings.

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

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

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

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

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

224	   Unix time  Defined by [POSIX] section 4.16
225	      (http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/
226	      V1_chap04.html#tag_04_16).

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

234	3.  Signing an exchange

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

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

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

255	3.1.  The Signature Header

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

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

268	   Signature = sh-param-list

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

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

283	   "integrity"  A string (Section 3.8 of

285	      [I-D.ietf-httpbis-header-structure]) containing a "/"-separated
286	      sequence of names starting with the lowercase name of the response
287	      header field that guards the response payload's integrity.  The
288	      meaning of subsequent names depends on the response header field,
289	      but for the "digest" header field, the single following name is
290	      the name of the digest algorithm that guards the payload's
291	      integrity.

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

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

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

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

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

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

315	3.1.1.  Examples

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

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

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

355	   All 4 signatures rely on the "Digest" response header with the mi-
356	   sha256 digest algorithm to guard the integrity of the response
357	   payload.

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

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

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

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

382	3.1.2.  Open Questions

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

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

394	3.2.  CBOR representation of exchange response headers

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

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

407	   *  The byte string ':status' to the byte string containing the
408	      response's 3-digit status code, and

410	   *  For each response header field, the header field's lowercase name
411	      as a byte string to the header field's value as a byte string.

413	3.2.1.  Example

415	   Given the HTTP exchange:

417	   GET / HTTP/1.1
418	   Host: example.com
419	   Accept: */*

421	   HTTP/1.1 200
422	   Content-Type: text/html
423	   Digest: mi-sha256=dcRDgR2GM35DluAV13PzgnG6+pvQwPywfFvAu1UeFrs=
424	   Signed-Headers: "content-type", "digest"

426	   <!doctype html>
427	   <html>
428	   ...

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

433	   {
434	     'digest': 'mi-sha256=dcRDgR2GM35DluAV13PzgnG6+pvQwPywfFvAu1UeFrs=',
435	     ':status': '200',
436	     'content-type': 'text/html'
437	   }

439	3.3.  Loading a certificate chain

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

445	   cert-chain = [
446	     "📜⛓", ; U+1F4DC U+26D3
447	     + augmented-certificate
448	   ]
449	   augmented-certificate = {
450	     cert: bytes,
451	     ? ocsp: bytes,
452	     ? sct: bytes,
453	     * tstr => any,
454	   }

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

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

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

470	   3.  Each certificate's "sct" value if any MUST be a
471	       "SignedCertificateTimestampList" for that certificate as defined
472	       by Section 3.3 of [RFC6962].

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

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

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

489	   3.  Return "certificate-chain".

491	3.4.  Canonical CBOR serialization

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

497	   *  Integers and the lengths of arrays, maps, and strings MUST use the
498	      smallest possible encoding.

500	   *  Items MUST NOT be encoded with indefinite length.

502	   *  The keys in every map MUST be sorted in the bytewise lexicographic
503	      order of their canonical encodings.  For example, the following
504	      keys are correctly sorted:

506	      1.  10, encoded as 0A.

508	      2.  100, encoded as 18 64.

510	      3.  -1, encoded as 20.

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

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

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

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

520	      8.  false, encoded as F4.

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

526	3.5.  Signature validity

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

536	   The client MUST use the following algorithm to determine whether each
537	   signature with parameters is invalid or potentially-valid for an
538	   exchange's

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

543	   *  "responseHeaders", a byte sequence holding the canonical
544	      serialization (Section 3.4) of the CBOR representation
545	      (Section 3.2) of the exchange's response metadata and headers, and

547	   *  "payload", a stream of bytes constituting the exchange's payload
548	      body (Section 3.3 of [RFC7230]).  Note that the payload body is
549	      the message body with any transfer encodings removed.

551	   Potentially-valid results include:

553	   *  The signed headers of the exchange so that higher-level protocols
554	      can avoid relying on unsigned headers, and

556	   *  Either a certificate chain or a public key so that a higher-level
557	      protocol can determine whether it's actually valid.

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

565	   1.   Let:

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

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

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

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

576	        *  "cert-sha256" be the signature's "cert-sha256" parameter, if
577	           any.

579	        *  "ed25519key" be the signature's "ed25519key" parameter, if
580	           any.

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

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

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

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

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

598	            2.  Let "main-certificate" be the first certificate in
599	                "certificate-chain".

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

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

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

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

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

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

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

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

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

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

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

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

641	        4.  If "cert-sha256" is set, a byte holding the value 32
642	            followed by the 32 bytes of the value of "cert-sha256".
643	            Otherwise a 0 byte.

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

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

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

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

655	        9.  The 8-byte big-endian encoding of the length in bytes of
656	            "responseHeaders", followed by the bytes of
657	            "responseHeaders".

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

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

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

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

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

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

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

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

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

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

725	3.5.1.  Open Questions

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

730	3.6.  Updating signature validity

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

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

741	   The "validity-url" parameter (Section 3.1) of the signatures provides
742	   a way to fetch new signatures or learn where to fetch a complete
743	   updated exchange.

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

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

752	   validity = {
753	     ? signatures: [ + bytes ]
754	     ? update: {
755	       ? size: uint,
756	     }
757	   ]

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

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

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

777	3.6.1.  Examples

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

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

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

809	{
810	  "signatures": [
811	    'sig1; '
812	    'sig=*MEQCIC/I9Q+7BZFP6cSDsWx43pBAL0ujTbON/+7RwKVk+ba5AiB3FSFLZqpzmDJ0NumNwN04pqgJZE99fcK86UjkPbj4jw==*; '
813	    'validity-url="https://example.com/resource.validity.1511157180"; '
814	    'integrity="digest/mi-sha256"; '
815	    'cert-url="https://example.com/newcerts"; '
816	    'cert-sha256=*J/lEm9kNRODdCmINbvitpvdYKNQ+YgBj99DlYp4fEXw=*; '
817	    'date=1511733180; expires=1512337980'
818	  ],
819	  "update": {
820	    "size": 5557452
821	  }
822	}
823	   This indicates that the client could fetch a newer version at
824	   "https://example.com/resource" (the original URL of the exchange), or
825	   that the validity period of the old version can be extended by
826	   replacing the first two of the original signatures (the ones with a
827	   validity-url of "https://example.com/resource.validity.1511157180")
828	   with the single new signature provided.  (This might happen at the
829	   end of a migration to a new root certificate.)  The signatures of the
830	   updated signed exchange would be:

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

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

850	3.7.  The Accept-Signature header

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

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

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

871	   Accept-Signature = sh-param-list

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

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

885	3.7.1.  Integrity identifiers

887	   Identifiers starting with "digest/" indicate that the client supports
888	   the "Digest" header field ([RFC3230]) with the parameter from the
889	   HTTP Digest Algorithm Values Registry
890	   (https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml)
891	   registry named in lower-case by the rest of the identifier.  For
892	   example, "digest/mi-blake2" indicates support for Merkle integrity
893	   with the as-yet-unspecified mi-blake2 parameter, and "-digest/mi-
894	   sha256" indicates non-support for Merkle integrity with the mi-sha256
895	   content encoding.

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

901	3.7.2.  Key type identifiers

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

907	   If the "Accept-Signature" header field is present, servers SHOULD
908	   assume support for "ecdsa/secp256r1" unless the header field states
909	   otherwise.

911	3.7.3.  Key value identifiers

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

922	Accept-Signature: ..., ed25519key; *11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo=*
923	Accept-Signature: ..., ed25519key; *11qYAYKxCrfVS/7TyWQHOg==*
924	Accept-Signature: ..., ed25519key; *11qYAQ==*
925	Accept-Signature: ..., ed25519key; **

927	   but not

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

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

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

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

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

944	3.7.4.  Examples

946	   Accept-Signature: digest/mi-sha256

948	   states that the client will accept signatures with payload integrity
949	   assured by the "Digest" header and "mi-sha256" digest algorithm and
950	   implies that the client will accept signatures from ECDSA keys on the
951	   secp256r1 curve.

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

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

959	3.7.5.  Open Questions

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

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

970	   Do I have the right structure for the identifiers indicating feature
971	   support?

973	4.  Cross-origin trust

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

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

981	   *  "responseHeaders", a byte sequence holding the canonical
982	      serialization (Section 3.4) of the CBOR representation
983	      (Section 3.2) of the exchange's response metadata and headers, and

985	   *  "payload", a stream of bytes constituting the exchange's payload
986	      body (Section 3.3 of [RFC7230]).

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

994	   1.  If the signature's "validity-url" parameter (Section 3.1) is not
995	       same-origin (https://html.spec.whatwg.org/multipage/
996	       origin.html#same-origin) with "requestUrl", return "invalid".

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

1003	   3.  Let "response" be the response metadata and headers parsed out of
1004	       "responseHeaders".

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

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

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

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

1019	       1.  Use "certificate-chain" to validate that its first entry,
1020	           "main-certificate" is trusted as "authority"'s server
1021	           certificate ([RFC5280] and other undocumented conventions).
1022	           Let "path" be the path that was used from the "main-
1023	           certificate" to a trusted root, including the "main-
1024	           certificate" but excluding the root.

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

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

1036	       4.  Validate that valid SCTs from trusted logs are available from
1037	           any of:

1039	           *  The "SignedCertificateTimestampList" in "main-
1040	              certificate"'s "sct" property (Section 3.3),

1042	           *  An OCSP extension in the OCSP response in "main-
1043	              certificate"'s "ocsp" property, or

1045	           *  An X.509 extension in the certificate in "main-
1046	              certificate"'s "cert" property,

1048	           as described by Section 3.3 of [RFC6962].

1050	   8.  Return "valid".

1052	4.1.  Uncached header fields

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

1058	   *  Hop-by-hop header fields listed in the Connection header field
1059	      (Section 6.1 of [RFC7230]).

1061	   *  Header fields listed in the no-cache response directive in the
1062	      Cache-Control header field (Section 5.2.2.2 of [RFC7234]).

1064	   *  Header fields defined as hop-by-hop:

1066	      -  Connection

1068	      -  Keep-Alive

1070	      -  Proxy-Connection

1072	      -  Trailer

1074	      -  Transfer-Encoding

1076	      -  Upgrade

1078	   *  Stateful headers as defined below.

1080	4.1.1.  Stateful header fields

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

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

1092	   *  "Authentication-Control", [RFC8053]

1094	   *  "Authentication-Info", [RFC7615]

1096	   *  "Clear-Site-Data", [W3C.WD-clear-site-data-20171130]

1098	   *  "Optional-WWW-Authenticate", [RFC8053]

1100	   *  "Proxy-Authenticate", [RFC7235]

1102	   *  "Proxy-Authentication-Info", [RFC7615]

1104	   *  "Public-Key-Pins", [RFC7469]

1106	   *  "Sec-WebSocket-Accept", [RFC6455]

1108	   *  "Set-Cookie", [RFC6265]
1109	   *  "Set-Cookie2", [RFC2965]

1111	   *  "SetProfile", [W3C.NOTE-OPS-OverHTTP]

1113	   *  "Strict-Transport-Security", [RFC6797]

1115	   *  "WWW-Authenticate", [RFC7235]

1117	4.2.  Certificate Requirements

1119	   We define a new X.509 extension, CanSignHttpExchanges to be used in
1120	   the certificate when the certificate permits the usage of signed
1121	   exchanges.  When this extension is not present the client MUST NOT
1122	   accept a signature from the certificate as proof that a signed
1123	   exchange is authoritative for a domain covered by the certificate.
1124	   When it is present, the client MUST follow the validation procedure
1125	   in Section 4.

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

1129	      CanSignHttpExchanges ::= NULL

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

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

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

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

1145	   Certificates with this extension MUST have a Validity Period no
1146	   greater than 90 days.

1148	   Conforming CAs MUST NOT mark this extension as critical.

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

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

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

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

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

1165	   id-ce-google OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 11129 }
1166	   id-ce-canSignHttpExchangesDraft OBJECT IDENTIFIER ::= { id-ce-google 2 1 22 }

1168	   Implementations of drafts of this specification MAY recognize the
1169	   "id-ce-canSignHttpExchangesDraft" OID as identifying the
1170	   CanSignHttpExchanges extension.  This OID might or might not be used
1171	   as the final OID for the extension, so certificates including it
1172	   might need to be reissued once the final RFC is published.

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

1178	   *  Clients MUST reject certificates with this extension that were
1179	      issued after 2019-05-01 and have a Validity Period longer than 90
1180	      days.

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

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

1188	4.2.1.  Extensions to the CAA Record: cansignhttpexchanges Parameter

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

1194	5.  Transferring a signed exchange

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

1199	5.1.  Same-origin response

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

1211	   *  The "Signature" header field,

1213	   *  The effective request URI (Section 5.5 of [RFC7230]) of the
1214	      request,

1216	   *  The serialized headers defined by Section 5.1.1, and

1218	   *  The response's payload.

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

1224	   If the signed response includes a "Variants" header field, the client
1225	   MUST use the cache behavior algorithm in Section 4 of
1226	   [I-D.ietf-httpbis-variants] to check that the signed response is an
1227	   appropriate representation for the request the client is trying to
1228	   fulfil.  If the response is not an appropriate representation, the
1229	   client MUST treat the signature as invalid.

1231	5.1.1.  Serialized headers for a same-origin response

1233	   The serialized headers of an exchange represented as a normal HTTP
1234	   request/response pair (Section 2.1 of [RFC7230] or Section 8.1 of
1235	   [RFC7540]) are the canonical serialization (Section 3.4) of the CBOR
1236	   representation (Section 3.2) of the response status code (Section 6
1237	   of [RFC7231]) and the response header fields whose names are listed
1238	   in that response's "Signed-Headers" header field (Section 5.1.2).  If
1239	   a response header field name from "Signed-Headers" does not appear in
1240	   the response's header fields, the exchange has no serialized headers.

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

1248	5.1.1.1.  Open Questions

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

1253	5.1.2.  The Signed-Headers Header

1255	   The "Signed-Headers" header field identifies an ordered list of
1256	   response header fields to include in a signature.  The request URL
1257	   and response status are included unconditionally.  This allows a TLS-
1258	   terminating intermediate to reorder headers without breaking the
1259	   signature.  This _can_ also allow the intermediate to add headers
1260	   that will be ignored by some higher-level protocols, but Section 3.5
1261	   provides a hook to let other higher-level protocols reject such
1262	   insecure headers.

1264	   This header field appears once instead of being incorporated into the
1265	   signatures' parameters because the signed header fields need to be
1266	   consistent across all signatures of an exchange, to avoid forcing
1267	   higher-level protocols to merge the header field lists of valid
1268	   signatures.

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

1274	   Signed-Headers = sh-list

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

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

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

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

1291	5.2.1.  Indicating support for cross-origin Server Push

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

1297	   An ENABLE_CROSS_ORIGIN_PUSH value of 0 indicates that the client does
1298	   not support cross-origin Push.  A value of 1 indicates that the
1299	   client does support cross-origin Push.

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

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

1313	5.2.2.  NO_TRUSTED_EXCHANGE_SIGNATURE error code

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

1322	5.2.2.1.  Open Questions

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

1326	5.2.3.  Validating a cross-origin Push

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

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

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

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

1346	   3.  Run the algorithm in Section 4 over:

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

1350	       *  The effective request URI from the PUSH_PROMISE.

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

1356	       *  The response's payload.

1358	       If this returns "invalid", the client MUST treat the response as
1359	       a stream error (Section 5.4.2 of [RFC7540]) of type
1360	       NO_TRUSTED_EXCHANGE_SIGNATURE.  Otherwise, the client MUST treat
1361	       the pushed response as if the server were authoritative for the
1362	       PUSH_PROMISE's authority.

1364	5.2.3.1.  Open Questions

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

1371	5.3.  application/signed-exchange format

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

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

1382	   *  Content-Type: application/signed-exchange;v=_version_

1384	   *  X-Content-Type-Options: nosniff

1386	   This content type consists of the concatenation of the following
1387	   items:

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

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

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

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

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

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

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

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

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

1420	   7.  "headerLength" bytes holding "signedHeaders", the canonical
1421	       serialization (Section 3.4) of the CBOR representation of the
1422	       response headers of the exchange represented by the "application/
1423	       signed-exchange" resource (Section 3.2), excluding the
1424	       "Signature" header field.

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

1429	       Note that the use of the payload body here means that a
1430	       "Transfer-Encoding" header field inside the "application/signed-
1431	       exchange" header block has no effect.  A "Transfer-Encoding"
1432	       header field on the outer HTTP response that transfers this
1433	       resource still has its normal effect.

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

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

1442	5.3.2.  Example

1444	   An example "application/signed-exchange" file representing a possible
1445	   signed exchange with https://example.com/ (https://example.com/)
1446	   follows, with lengths represented by descriptions in "<>"s, CBOR
1447	   represented in the extended diagnostic format defined in Appendix G
1448	   of [CDDL], and most of the "Signature" header field and payload
1449	   elided with a ...:

1451	   sxg1\0\0\0\0<2-byte length of the following url string>
1452	   https://example.com/<3-byte length of the following header
1453	   value><3-byte length of the encoding of the
1454	   following map>sig1; sig=*...; integrity="digest/mi-sha256"; ...{
1455	     ':status': '200',
1456	     'content-type': 'text/html'
1457	   }<!doctype html>\r\n<html>...

1459	5.3.3.  Open Questions

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

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

1466	6.  Security considerations

1468	6.1.  Over-signing

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

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

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

1484	   2.  Only sign exchanges where the response includes a "Cache-Control:
1485	       public" header.  Clients are not required to fail signature-
1486	       checking for exchanges that omit this "Cache-Control" response
1487	       header field to reduce the risk that naive signing systems
1488	       blindly add it.

1490	6.1.1.  Session fixation

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

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

1503	6.1.2.  Misleading content

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

1510	   Stripping authentication information from requests before sending
1511	   them to backends is likely to prevent the backend from showing
1512	   attacker-specific information in the signed response.  It does not
1513	   prevent the attacker from showing their victim a signed-out page when
1514	   the victim is actually signed in, but while this is still misleading,
1515	   it seems less likely to be useful to the attacker.

1517	6.2.  Off-path attackers

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

1529	6.2.1.  Mis-issued certificates

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

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

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

1550	   CAs are forbidden from future-dating their OCSP responses by the
1551	   [BRs] section 4.9.9, "OCSP responses MUST conform to RFC6960 and/or
1552	   RFC5019."  [RFC6960] includes, "The time at which the status was
1553	   known to be correct SHALL be reflected in the thisUpdate field of the
1554	   response.", and [RFC5019] includes, "When pre-producing OCSPResponse
1555	   messages, the responder MUST set the thisUpdate, nextUpdate, and
1556	   producedAt times as follows: thisUpdate: The time at which the status
1557	   being indicated is known to be correct."

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

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

1567	6.2.2.  Stolen private keys

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

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

1583	6.3.  Downgrades

1585	   Signing a bad response can affect more users than simply serving a
1586	   bad response, since a served response will only affect users who make
1587	   a request while the bad version is live, while an attacker can
1588	   forward a signed response until its signature expires.  Publishers
1589	   should consider shorter signature expiration times than they use for
1590	   cache expiration times.

1592	   Clients MAY also check the "validity-url" (Section 3.1) of an
1593	   exchange more often than the signature's expiration would require.
1594	   Doing so for an exchange with an HTTPS request URI provides a TLS
1595	   guarantee that the exchange isn't out of date (as long as
1596	   Section 5.2.3.1 is resolved to keep the same-origin requirement).

1598	6.4.  Signing oracles are permanent

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

1608	6.5.  Unsigned headers

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

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

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

1631	6.6.  application/signed-exchange

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

1639	6.7.  Key re-use with TLS

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

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

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

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

1656	   We require that clients reject certificates with the
1657	   CanSignHttpExchanges extension when making TLS connections to
1658	   minimize the chance that servers will re-use keys like this.
1659	   Ideally, we would make the extension critical so that even clients
1660	   that don't understand it would reject such TLS connections, but this
1661	   proved impossible because certificate-validating libraries ship on
1662	   significantly different schedules from the clients that use them.

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

1669	6.8.  Content sniffing

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

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

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

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

1692	   2.  Generate signed exchanges "offline", that is, in response to a
1693	       trusted author submitting content or existing signatures reaching
1694	       a certain age, rather than in response to untrusted-reader
1695	       queries.

1697	   3.  Do all of:

1699	       1.  If the SXG's fallback URL (Section 5.3) is derived from the
1700	           request URL, percent-encode
1701	           (https://url.spec.whatwg.org/#percent-encode) ([URL]) any
1702	           bytes that are greater than 0x7E or are not URL code points
1703	           (https://url.spec.whatwg.org/#url-code-points) ([URL]) in the
1704	           fallback URL . It is particularly important to make sure no
1705	           unescaped nulls (0x00) or angle brackets (0x3C and 0x3E)
1706	           appear.

1708	       2.  Do not reflect request header fields into the set of response
1709	           headers.

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

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

1721	7.  Privacy considerations
1722	7.1.  Visibility of resource requests

1724	   Normally, when a client follows a link from https://source.example/
1725	   page.html to "https://publisher.example/page.html",
1726	   "publisher.example" learns that the client is interested in the
1727	   resource. "source.example" also has several ways of discovering that
1728	   the client has clicked the link, including the use of Javascript to
1729	   record the click or having the link point to a URL that serves a 302
1730	   redirect to the real target.

1732	   If "publisher.example" signs "page.html" into "page.sxg",
1733	   "distributor.example" serves it as
1734	   "https://distributor.example/publisher/page.sxg", and the client
1735	   fetches it from there, then "distributor.example" learns that the
1736	   client is interested, and if the client executes some Javascript on
1737	   the page or makes subresource requests, that could also report the
1738	   client's interest back to "publisher.example".

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

1749	   If "source.example" and "distributor.example" are controlled by the
1750	   same entity, no extra information escapes here.  If they are run by
1751	   different entities, a similar amount of information escapes as if
1752	   "source.example" had implemented its click tracking by outsourcing to
1753	   a service like https://bit.ly/ (https://bit.ly/).

1755	   There has been discussion of allowing a publisher to restrict the set
1756	   of distributors that can host its signed content.  If that's added,
1757	   then the privacy situation becomes more similar to the situation with
1758	   CDNs, where a publisher chooses a CDN to serve their content, and the
1759	   CDN learns about all requests for that content.  Here the publisher
1760	   would choose one or more distributors, and the distributor(s) would
1761	   learn about requests for the content.

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

1767	7.2.  User ID transfer

1769	   If a request for "https://distributor.example/publisher/page.sxg"
1770	   comes with the source's or distributor's user ID for the user, either
1771	   because it's sent with the distributor's cookies or because the
1772	   source stashes an encoded user ID into either the request's path or a
1773	   subdomain, the distributor has a few ways to pass that user ID on to
1774	   the publisher that signed the page:

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

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

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

1790	8.  IANA considerations

1792	   TODO: possibly register the validity-url format.

1794	8.1.  Signature Header Field Registration

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

1799	   Header field name: "Signature"

1801	   Applicable protocol: http

1803	   Status: standard

1805	   Author/Change controller: IETF

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

1809	8.2.  Accept-Signature Header Field Registration

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

1814	   Header field name: "Accept-Signature"
1815	   Applicable protocol: http

1817	   Status: standard

1819	   Author/Change controller: IETF

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

1823	8.3.  Signed-Headers Header Field Registration

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

1828	   Header field name: "Signed-Headers"

1830	   Applicable protocol: http

1832	   Status: standard

1834	   Author/Change controller: IETF

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

1838	8.4.  HTTP/2 Settings

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

1843	   Name: ENABLE_CROSS_ORIGIN_PUSH

1845	   Code: 0xSETTING-TBD

1847	   Initial Value: 0

1849	   Specification: This document

1851	8.5.  HTTP/2 Error code

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

1856	   Name: NO_TRUSTED_EXCHANGE_SIGNATURE

1858	   Code: 0xERROR-TBD

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

1863	   Specification: This document

1865	8.6.  Internet Media Type application/signed-exchange

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

1871	   Type name: application

1873	   Subtype name: signed-exchange

1875	   Required parameters:

1877	   *  v: A string denoting the version of the file format.  ([RFC5234]
1878	      ABNF: "version = DIGIT/%x61-7A") The version defined in this
1879	      specification is "1".  When used with the "Accept" header field
1880	      (Section 5.3.2 of [RFC7231]), this parameter can be a comma
1881	      (,)-separated list of version strings.  ([RFC5234] ABNF: "version-
1882	      list = version *( "," version )") The server is then expected to
1883	      reply with a resource using a particular version from that list.

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

1893	   Optional parameters: N/A

1895	   Encoding considerations: binary

1897	   Security considerations: see Section 6.6

1899	   Interoperability considerations: N/A

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

1903	   Applications that use this media type: N/A

1905	   Fragment identifier considerations: N/A

1907	   Additional information:

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

1912	   File extension(s): .sxg

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

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

1919	   Intended usage: COMMON

1921	   Restrictions on usage: N/A

1923	   Author: See Authors' Addresses section.

1925	   Change controller: IESG

1927	   Provisional registration?  Yes

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

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

1935	   Type name: application

1937	   Subtype name: cert-chain+cbor

1939	   Required parameters: N/A

1941	   Optional parameters: N/A

1943	   Encoding considerations: binary

1945	   Security considerations: N/A

1947	   Interoperability considerations: N/A

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

1951	   Applications that use this media type: N/A

1953	   Fragment identifier considerations: N/A

1955	   Additional information:

1957	   Deprecated alias names for this type: N/A
1958	   Magic number(s): 1*9(??) 67 F0 9F 93 9C E2 9B 93

1960	   File extension(s): N/A

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

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

1967	   Intended usage: COMMON

1969	   Restrictions on usage: N/A

1971	   Author: See Authors' Addresses section.

1973	   Change controller: IESG

1975	   Provisional registration?  Yes

1977	8.8.  The cansignhttpexchanges CAA Parameter

1979	   There are no IANA considerations for this parameter.

1981	9.  References

1983	9.1.  Normative References

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

1991	   [FETCH]    WHATWG, "Fetch", July 2020,
1992	              <https://fetch.spec.whatwg.org/>.

1994	   [I-D.ietf-httpbis-header-structure]
1995	              Nottingham, M. and P. Kamp, "Structured Field Values for
1996	              HTTP", Work in Progress, Internet-Draft, draft-ietf-
1997	              httpbis-header-structure-19, 3 June 2020,
1998	              <http://www.ietf.org/internet-drafts/draft-ietf-httpbis-
1999	              header-structure-19.txt>.

2001	   [I-D.ietf-httpbis-variants]
2002	              Nottingham, M., "HTTP Representation Variants", Work in
2003	              Progress, Internet-Draft, draft-ietf-httpbis-variants-06,
2004	              3 November 2019, <http://www.ietf.org/internet-drafts/
2005	              draft-ietf-httpbis-variants-06.txt>.

2007	   [I-D.thomson-http-mice]
2008	              Thomson, M. and J. Yasskin, "Merkle Integrity Content
2009	              Encoding", Work in Progress, Internet-Draft, draft-
2010	              thomson-http-mice-03, 13 August 2018,
2011	              <http://www.ietf.org/internet-drafts/draft-thomson-http-
2012	              mice-03.txt>.

2014	   [IANA.media-types]
2015	              IANA, "Media Types",
2016	              <http://www.iana.org/assignments/media-types>.

2018	   [POSIX]    IEEE and The Open Group, "The Open Group Base
2019	              Specifications Issue 7", value 1003.1-2008, 2016 Edition,
2020	              name IEEE, 2016,
2021	              <http://pubs.opengroup.org/onlinepubs/9699919799/
2022	              basedefs/>.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2101	   [URL]      WHATWG, "URL", July 2020, <https://url.spec.whatwg.org/>.

2103	9.2.  Informative References

2105	   [BRs]      CA/Browser Forum, "Baseline Requirements for the Issuance
2106	              and Management of Publicly-Trusted Certificates", 10
2107	              December 2018,
2108	              <https://cabforum.org/baseline-requirements-documents/>.

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

2114	   [I-D.bishop-httpbis-origin-fed-up]
2115	              Bishop, M. and E. Nygren, "DNS Security with HTTP/2
2116	              ORIGIN", Work in Progress, Internet-Draft, draft-bishop-
2117	              httpbis-origin-fed-up-00, 8 January 2019,
2118	              <http://www.ietf.org/internet-drafts/draft-bishop-httpbis-
2119	              origin-fed-up-00.txt>.

2121	   [I-D.burke-content-signature]
2122	              Burke, B., "HTTP Header for digital signatures", Work in
2123	              Progress, Internet-Draft, draft-burke-content-signature-
2124	              00, 7 March 2011, <http://www.ietf.org/internet-drafts/
2125	              draft-burke-content-signature-00.txt>.

2127	   [I-D.cavage-http-signatures]
2128	              Cavage, M. and M. Sporny, "Signing HTTP Messages", Work in
2129	              Progress, Internet-Draft, draft-cavage-http-signatures-12,
2130	              21 October 2019, <http://www.ietf.org/internet-drafts/
2131	              draft-cavage-http-signatures-12.txt>.

2133	   [I-D.ietf-httpbis-cache]
2134	              Fielding, R., Nottingham, M., and J. Reschke, "HTTP
2135	              Caching", Work in Progress, Internet-Draft, draft-ietf-
2136	              httpbis-cache-10, 12 July 2020, <http://www.ietf.org/
2137	              internet-drafts/draft-ietf-httpbis-cache-10.txt>.

2139	   [I-D.ietf-httpbis-http2-secondary-certs]
2140	              Bishop, M., Sullivan, N., and M. Thomson, "Secondary
2141	              Certificate Authentication in HTTP/2", Work in Progress,
2142	              Internet-Draft, draft-ietf-httpbis-http2-secondary-certs-
2143	              06, 14 May 2020, <http://www.ietf.org/internet-drafts/
2144	              draft-ietf-httpbis-http2-secondary-certs-06.txt>.

2146	   [I-D.thomson-http-content-signature]
2147	              Thomson, M., "Content-Signature Header Field for HTTP",
2148	              Work in Progress, Internet-Draft, draft-thomson-http-
2149	              content-signature-00, 2 July 2015, <http://www.ietf.org/
2150	              internet-drafts/draft-thomson-http-content-signature-
2151	              00.txt>.

2153	   [I-D.yasskin-httpbis-origin-signed-exchanges-impl]
2154	              Yasskin, J. and K. Ueno, "Signed HTTP Exchanges
2155	              Implementation Checkpoints", Work in Progress, Internet-
2156	              Draft, draft-yasskin-httpbis-origin-signed-exchanges-impl-
2157	              03, 25 July 2019, <http://www.ietf.org/internet-drafts/
2158	              draft-yasskin-httpbis-origin-signed-exchanges-impl-
2159	              03.txt>.

2161	   [I-D.yasskin-wpack-use-cases]
2162	              Yasskin, J., "Use Cases and Requirements for Web
2163	              Packages", Work in Progress, Internet-Draft, draft-
2164	              yasskin-wpack-use-cases-00, 30 October 2019,
2165	              <http://www.ietf.org/internet-drafts/draft-yasskin-wpack-
2166	              use-cases-00.txt>.

2168	   [OneCrl]   Goodwin, M., "Revoking Intermediate Certificates:
2169	              Introducing OneCRL", 3 March 2015,
2170	              <https://blog.mozilla.org/security/2015/03/03/revoking-
2171	              intermediate-certificates-introducing-onecrl/>.

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

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

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

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

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

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

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

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

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

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

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

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

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

2232	   [SRI]      Akhawe, D., Braun, F., Marier, F., and J. Weinberger,
2233	              "Subresource Integrity", World Wide Web Consortium
2234	              Recommendation REC-SRI-20160623, 23 June 2016,
2235	              <http://www.w3.org/TR/2016/REC-SRI-20160623>.

2237	   [W3C.NOTE-OPS-OverHTTP]
2238	              Hensley, P., Metral, M., Shardanand, U., Converse, D., and
2239	              M. Myers, "Implementation of OPS Over HTTP", W3C NOTE
2240	              NOTE-OPS-OverHTTP, 2 June 1997,
2241	              <http://www.w3.org/TR/NOTE-OPS-OverHTTP>.

2243	   [W3C.WD-clear-site-data-20171130]
2244	              West, M., "Clear Site Data", World Wide Web Consortium WD
2245	              WD-clear-site-data-20171130, 30 November 2017,
2246	              <https://www.w3.org/TR/2017/WD-clear-site-data-20171130>.

2248	Appendix A.  Use cases

2250	A.1.  PUSHed subresources

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

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

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

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

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

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

2277	   <img logicalsrc="https://O.com/img.png"
2278	        physicalsrc="https://distributor.com/O.com/img.png">

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

2284	   <dist-img src="https://O.com/img.png"></dist-img>
2285	   where the "<dist-img>" implementation generates an appropriate
2286	   "<img>" based on, for example, a "<meta name="dist-base">" tag
2287	   elsewhere in the page.  However, this has the downside that the
2288	   preloader (https://calendar.perfplanet.com/2013/big-bad-preloader/)
2289	   can no longer see the physical source to download it.  The resulting
2290	   delay might cancel out the benefit of using a distributor.

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

2295	   To implement this with the current proposal, the distributor would
2296	   respond to the physical request to "https://distributor.com/O.com/
2297	   img.png" with first a signed PUSH_PROMISE for "https://O.com/img.png"
2298	   and then a redirect to "https://O.com/img.png".

2300	A.3.  Subresource Integrity

2302	   The W3C WebAppSec group is investigating using signatures
2303	   (https://github.com/mikewest/signature-based-sri) in [SRI].  They
2304	   need a way to transmit the signature with the response, which this
2305	   proposal provides.

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

2312	   The "ed25519key" signature parameter supports this simpler way of
2313	   attaching a key.

2315	   The current proposal for signature-based SRI describes signing only
2316	   the content of a resource, while this specification requires them to
2317	   sign the request URI as well.  This issue is tracked in
2318	   https://github.com/mikewest/signature-based-sri/issues/5
2319	   (https://github.com/mikewest/signature-based-sri/issues/5).  The
2320	   details of what they need to sign will affect whether and how they
2321	   can use this proposal.

2323	A.4.  Binary Transparency

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

2332	   Certificate Transparency depends on Signed Certificate Timestamps
2333	   that prove a log contained a particular certificate at a particular
2334	   time.  To build the same thing for Binary Transparency logs
2335	   containing HTTP resources or full websites, we'll need a way to
2336	   provide signatures of those resources, which signed exchanges
2337	   provides.

2339	A.5.  Static Analysis

2341	   Native app stores like the Apple App Store
2342	   (https://www.apple.com/ios/app-store/) and the Android Play Store
2343	   (https://play.google.com/store) grant their contents powerful
2344	   abilities, which they attempt to make safe by analyzing the
2345	   applications before offering them to people.  The web has no
2346	   equivalent way for people to wait to run an update of a web
2347	   application until a trusted authority has vouched for it.

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

2354	A.6.  Offline websites

2356	   Fully-offline websites can be represented as bundles of signed
2357	   exchanges, although an optimization to reduce the number of signature
2358	   verifications may be needed.  Work on this is in progress in the
2359	   https://github.com/WICG/webpackage (https://github.com/WICG/
2360	   webpackage) repository.

2362	Appendix B.  Requirements

2364	B.1.  Proof of origin

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

2372	B.1.1.  Certificate constraints

2374	   If we re-use existing TLS server certificates, we incur the risks
2375	   that:

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

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

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

2391	B.1.2.  Signature constraints

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

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

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

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

2411	B.1.3.  Retrieving the certificate

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

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

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

2436	B.2.  How much to sign

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

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

2457	B.2.1.  Conveying the signed headers

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

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

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

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

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

2486	B.3.  Response lifespan

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

2495	B.3.1.  Certificate revocation

2497	   Certificates are mis-issued and private keys are stolen, and in
2498	   response clients need to be able to stop trusting these certificates
2499	   as promptly as possible.  Online revocation checks don't work
2500	   (https://www.imperialviolet.org/2012/02/05/crlsets.html), so the
2501	   industry has moved to pushed revocation lists and stapled OCSP
2502	   responses [RFC6066].

2504	   Pushed revocation lists work as-is to block trust in the certificate
2505	   signing an exchange, but the signatures need an explicit strategy to
2506	   staple OCSP responses.  One option is to extend the certificate
2507	   download (Appendix B.1.3) to include the OCSP response too, perhaps
2508	   in the TLS 1.3 CertificateEntry (https://tlswg.github.io/tls13-spec/
2509	   draft-ietf-tls-tls13.html#ocsp-and-sct) format.

2511	B.3.2.  Response downgrade attacks

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

2521	   These assertions could be structured as:

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

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

2534	   3.  A replacement for the exchange's signature and an update for the
2535	       embedded "expires" and related cache-control HTTP headers
2536	       [RFC7234].  This naturally extends publishers' intuitions about
2537	       cache expiration and the existing cache revalidation behavior to
2538	       signed exchanges.  This is sketched and its downsides explored in
2539	       Appendix C.

2541	   The signature also needs to include instructions to intermediates for
2542	   how to fetch updated validity assertions.

2544	B.4.  Low implementation complexity

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

2550	B.4.1.  Limited choices

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

2556	B.4.2.  Bounded-buffering integrity checking

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

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

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

2576	Appendix C.  Determining validity using cache control

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

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

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

2594	   Validity updates (Section 3.6) would include a list of replacement
2595	   response header fields.  For each header field name in this list, the
2596	   client would remove matching header fields from the stored exchange's
2597	   response header fields.  Then the client would append the replacement
2598	   header fields to the stored exchange's response header fields.

2600	C.1.  Example of updating cache control

2602	   For example, given a stored exchange of:

2604	   GET  / HTTP/1.1
2605	   Host: example.com
2606	   Accept: */*

2608	   HTTP/1.1 200
2609	   Date: Mon, 20 Nov 2017 10:00:00 UTC
2610	   Content-Type: text/html
2611	   Date: Tue, 21 Nov 2017 10:00:00 UTC
2612	   Expires: Sun, 26 Nov 2017 10:00:00 UTC

2614	   <!doctype html>
2615	   <html>
2616	   ...

2618	   And an update listing the following headers:

2620	   Expires: Fri, 1 Dec 2017 10:00:00 UTC
2621	   Date: Sat, 25 Nov 2017 10:00:00 UTC

2623	   The resulting stored exchange would be:

2625	   GET / HTTP/1.1
2626	   Host: example.com
2627	   Accept: */*

2629	   HTTP/1.1 200
2630	   Content-Type: text/html
2631	   Expires: Fri, 1 Dec 2017 10:00:00 UTC
2632	   Date: Sat, 25 Nov 2017 10:00:00 UTC

2634	   <!doctype html>
2635	   <html>
2636	   ...

2638	C.2.  Downsides of updating cache control

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

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

2651	Appendix D.  Change Log

2653	   RFC EDITOR PLEASE DELETE THIS SECTION.

2655	   draft-09

2657	   *  No change

2659	   draft-08

2661	   *  Improve the privacy considerations.

2663	   draft-07
2664	   *  Provisionally register application/signed-exchange and
2665	      application/cert-chain+cbor.

2667	   draft-06

2669	   *  Add a security consideration for future-dated OCSP responses and
2670	      for stolen private keys.

2672	   *  Define a CAA parameter to opt into certificate issuance.

2674	   *  Limit certificate lifetimes to 90 days.

2676	   *  UTF-8 decode the fallback URL.

2678	   draft-05

2680	   *  Define absolute URLs, and limit the schemes each instance can use.

2682	   *  Fill in TBD size limits.

2684	   *  Update to mice-03 including the Digest header.

2686	   *  Refer to draft-yasskin-httpbis-origin-signed-exchanges-impl for
2687	      draft version numbers.

2689	   *  Require "exchange"'s response to be cachable by a shared cache.

2691	   *  Define the "integrity" field of the Signature header to include
2692	      subfields of the main integrity-protecting header, including the
2693	      digest algorithm.

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

2700	   *  Remove the rest of the request headers from the signed data, in
2701	      favor of representing content negotiation with the "Variants"
2702	      response header.

2704	   *  Make the signed message format a concatenation of byte sequences,
2705	      which helps implementations avoid re-serializing the exchange's
2706	      request and response metadata and headers.

2708	   *  Explicitly check the response payload's integrity instead of
2709	      assuming the client did it elsewhere in processing the response.

2711	   *  Reject uncached header fields.

2713	   *  Update to draft-ietf-httpbis-header-structure-09.

2715	   *  Update to the final TLS 1.3 RFC.

2717	   draft-04

2719	   *  Update to draft-ietf-httpbis-header-structure-06.

2721	   *  Replace the application/http-exchange+cbor format with a simpler
2722	      application/signed-exchange format that:

2724	      -  Doesn't require a streaming CBOR parser parse it from a network
2725	         stream.

2727	      -  Doesn't allow request payloads or response trailers, which
2728	         don't fit into the signature model.

2730	      -  Allows checking the signature before parsing the exchange
2731	         headers.

2733	   *  Require absolute URLs.

2735	   *  Make all identifiers in headers lower-case, as required by
2736	      Structured Headers.

2738	   *  Switch back to the TLS 1.3 signature format.

2740	   *  Include the version and draft number in the signature context
2741	      string.

2743	   *  Remove support for integrity protection using the Digest header
2744	      field.

2746	   *  Limit the record size in the mi-sha256 encoding.

2748	   *  Forbid RSA keys, and only require clients to support secp256r1
2749	      keys.

2751	   *  Add a test OID for the CanSignHttpExchanges X.509 extension.

2753	   draft-03

2755	   *  Allow each method of transferring an exchange to define which
2756	      headers are signed, have the cross-origin methods use all headers,
2757	      and remove the "allResponseHeaders" flag.

2759	   *  Describe footguns around signing private content, and block
2760	      certain headers to make it less likely.

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

2768	   *  Require an X.509 extension for the signing certificate.

2770	   draft-02

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

2775	   *  The validityUrl is signed.

2777	   *  Use CBOR maps where appropriate, and define how they're
2778	      canonicalized.

2780	   *  Remove the update.url field from signature validity updates, in
2781	      favor of just re-fetching the original request URL.

2783	   *  Define an HTTP/2 extension to use a setting to enable cross-origin
2784	      Server Push.

2786	   *  Define an "Accept-Signature" header to negotiate whether to send
2787	      Signatures and which ones.

2789	   *  Define an "application/http-exchange+cbor" format to fetch signed
2790	      exchanges without HTTP/2 Push.

2792	   *  2 new use cases.

2794	Appendix E.  Acknowledgements

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

2800	Author's Address

2802	   Jeffrey Yasskin
2803	   Google

2805	   Email: jyasskin@chromium.org