idnits 2.17.1 

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

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

     No issues found here.

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

     No issues found here.

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

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

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


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

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

  -- The document date (July 08, 2019) is 1744 days in the past.  Is this
     intentional?

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  == Outdated reference: A later version (-03) exists of
     draft-yasskin-httpbis-origin-signed-exchanges-impl-02

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

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

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

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


     Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 28 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                           July 08, 2019
5	Expires: January 9, 2020

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

10	Abstract

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

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

23	Note to Readers

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

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

32	Status of This Memo

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

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

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

47	   This Internet-Draft will expire on January 9, 2020.

49	Copyright Notice

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

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

64	Table of Contents

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

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

159	1.  Introduction

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

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

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

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

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

187	2.  Terminology

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

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

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

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

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

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

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

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

229	3.  Signing an exchange

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

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

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

250	3.1.  The Signature Header

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

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

263	   Signature = sh-param-list

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

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

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

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

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

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

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

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

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

309	3.1.1.  Examples

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

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

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

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

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

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

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

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

376	3.1.2.  Open Questions

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

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

388	3.2.  CBOR representation of exchange response headers

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

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

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

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

407	3.2.1.  Example

409	   Given the HTTP exchange:

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

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

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

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

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

433	3.3.  Loading a certificate chain

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

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

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

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

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

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

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

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

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

483	   3.  Return "certificate-chain".

485	3.4.  Canonical CBOR serialization

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

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

494	   o  Items MUST NOT be encoded with indefinite length.

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

500	      1.  10, encoded as 0A.

502	      2.  100, encoded as 18 64.

504	      3.  -1, encoded as 20.

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

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

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

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

514	      8.  false, encoded as F4.

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

520	3.5.  Signature validity

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

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

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

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

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

545	   Potentially-valid results include:

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

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

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

559	   1.   Let:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

719	3.5.1.  Open Questions

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

724	3.6.  Updating signature validity

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

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

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

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

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

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

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

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

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

771	3.6.1.  Examples

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

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

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

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

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

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

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

845	3.7.  The Accept-Signature header

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

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

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

866	   Accept-Signature = sh-param-list

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

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

880	3.7.1.  Integrity identifiers

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

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

894	3.7.2.  Key type identifiers

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

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

904	3.7.3.  Key value identifiers

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

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

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

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

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

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

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

936	3.7.4.  Examples

938	   Accept-Signature: digest/mi-sha256

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

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

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

951	3.7.5.  Open Questions

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

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

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

965	4.  Cross-origin trust

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1040	           as described by Section 3.3 of [RFC6962].

1042	   8.  Return "valid".

1044	4.1.  Uncached header fields

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

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

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

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

1058	      *  Connection

1060	      *  Keep-Alive
1061	      *  Proxy-Connection

1063	      *  Trailer

1065	      *  Transfer-Encoding

1067	      *  Upgrade

1069	   o  Stateful headers as defined below.

1071	4.1.1.  Stateful header fields

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

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

1083	   o  "Authentication-Control", [RFC8053]

1085	   o  "Authentication-Info", [RFC7615]

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

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

1091	   o  "Proxy-Authenticate", [RFC7235]

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

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

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

1099	   o  "Set-Cookie", [RFC6265]

1101	   o  "Set-Cookie2", [RFC2965]

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

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

1107	   o  "WWW-Authenticate", [RFC7235]

1109	4.2.  Certificate Requirements

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

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

1121	      CanSignHttpExchanges ::= NULL

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

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

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

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

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

1140	   Conforming CAs MUST NOT mark this extension as critical.

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

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

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

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

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

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

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

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

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

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

1179	4.2.1.  Extensions to the CAA Record: cansignhttpexchanges Parameter

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

1185	5.  Transferring a signed exchange

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

1190	5.1.  Same-origin response

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

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

1206	   o  The serialized headers defined by Section 5.1.1, and

1208	   o  The response's payload.

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

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

1221	5.1.1.  Serialized headers for a same-origin response

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

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

1238	5.1.1.1.  Open Questions

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

1243	5.1.2.  The Signed-Headers Header

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

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

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

1264	   Signed-Headers = sh-list

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

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

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

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

1281	5.2.1.  Indicating support for cross-origin Server Push

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

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

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

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

1303	5.2.2.  NO_TRUSTED_EXCHANGE_SIGNATURE error code

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

1312	5.2.2.1.  Open Questions

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

1316	5.2.3.  Validating a cross-origin Push

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

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

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

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

1336	   3.  Run the algorithm in Section 4 over:

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

1340	       *  The effective request URI from the PUSH_PROMISE.

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

1346	       *  The response's payload.

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

1354	5.2.3.1.  Open Questions

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

1361	5.3.  application/signed-exchange format

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

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

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

1374	   o  X-Content-Type-Options: nosniff

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1432	5.3.2.  Example

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

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

1448	5.3.3.  Open Questions

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

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

1455	6.  Security considerations

1457	6.1.  Over-signing

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

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

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

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

1479	6.1.1.  Session fixation

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

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

1492	6.1.2.  Misleading content

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

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

1506	6.2.  Off-path attackers

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

1518	6.2.1.  Mis-issued certificates

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

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

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

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

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

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

1556	6.2.2.  Stolen private keys

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

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

1572	6.3.  Downgrades

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

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

1587	6.4.  Signing oracles are permanent

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

1597	6.5.  Unsigned headers

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

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

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

1620	6.6.  application/signed-exchange

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

1628	6.7.  Key re-use with TLS

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

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

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

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

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

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

1658	6.8.  Content sniffing

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

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

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

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

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

1686	   3.  Do all of:

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

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

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

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

1708	7.  Privacy considerations

1710	   Normally, when a client fetches "https://o1.com/resource.js",
1711	   "o1.com" learns that the client is interested in the resource.  If
1712	   "o1.com" signs "resource.js", "o2.com" serves it as "https://o2.com/
1713	   o1resource.js", and the client fetches it from there, then "o2.com"
1714	   learns that the client is interested, and if the client executes the
1715	   Javascript, that could also report the client's interest back to
1716	   "o1.com".

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

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

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

1735	8.  IANA considerations

1737	   TODO: possibly register the validity-url format.

1739	8.1.  Signature Header Field Registration

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

1744	   Header field name: "Signature"

1746	   Applicable protocol: http

1748	   Status: standard

1750	   Author/Change controller: IETF

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

1754	8.2.  Accept-Signature Header Field Registration

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

1759	   Header field name: "Accept-Signature"

1761	   Applicable protocol: http

1763	   Status: standard

1765	   Author/Change controller: IETF

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

1769	8.3.  Signed-Headers Header Field Registration

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

1774	   Header field name: "Signed-Headers"

1776	   Applicable protocol: http

1778	   Status: standard

1780	   Author/Change controller: IETF

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

1784	8.4.  HTTP/2 Settings

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

1789	   Name: ENABLE_CROSS_ORIGIN_PUSH

1791	   Code: 0xSETTING-TBD

1793	   Initial Value: 0

1795	   Specification: This document

1797	8.5.  HTTP/2 Error code

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

1802	   Name: NO_TRUSTED_EXCHANGE_SIGNATURE

1804	   Code: 0xERROR-TBD

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

1809	   Specification: This document

1811	8.6.  Internet Media Type application/signed-exchange

1813	   Type name: application

1815	   Subtype name: signed-exchange
1816	   Required parameters:

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

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

1834	   Optional parameters: N/A

1836	   Encoding considerations: binary

1838	   Security considerations: see Section 6.6

1840	   Interoperability considerations: N/A

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

1844	   Applications that use this media type: N/A

1846	   Fragment identifier considerations: N/A

1848	   Additional information:

1850	   Deprecated alias names for this type: N/A

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

1854	   File extension(s): .sxg

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

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

1861	   Intended usage: COMMON

1863	   Restrictions on usage: N/A
1864	   Author: See Authors' Addresses section.

1866	   Change controller: IESG

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

1870	   Type name: application

1872	   Subtype name: cert-chain+cbor

1874	   Required parameters: N/A

1876	   Optional parameters: N/A

1878	   Encoding considerations: binary

1880	   Security considerations: N/A

1882	   Interoperability considerations: N/A

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

1886	   Applications that use this media type: N/A

1888	   Fragment identifier considerations: N/A

1890	   Additional information:

1892	   Deprecated alias names for this type: N/A

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

1896	   File extension(s): N/A

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

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

1903	   Intended usage: COMMON

1905	   Restrictions on usage: N/A

1907	   Author: See Authors' Addresses section.

1909	   Change controller: IESG

1911	8.8.  The cansignhttpexchanges CAA Parameter

1913	   There are no IANA considerations for this parameter.

1915	9.  References

1917	9.1.  Normative References

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

1925	   [FETCH]    WHATWG, "Fetch", July 2019,
1926	              <https://fetch.spec.whatwg.org/>.

1928	   [I-D.ietf-httpbis-header-structure]
1929	              Nottingham, M. and P. Kamp, "Structured Headers for HTTP",
1930	              draft-ietf-httpbis-header-structure-10 (work in progress),
1931	              April 2019.

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

1937	   [I-D.thomson-http-mice]
1938	              Thomson, M. and J. Yasskin, "Merkle Integrity Content
1939	              Encoding", draft-thomson-http-mice-03 (work in progress),
1940	              August 2018.

1942	   [POSIX]    IEEE and The Open Group, "The Open Group Base
1943	              Specifications Issue 7", name IEEE, value 1003.1-2008,
1944	              2016 Edition, 2016,
1945	              <http://pubs.opengroup.org/onlinepubs/9699919799/
1946	              basedefs/>.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2027	9.2.  Informative References

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

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

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

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

2047	   [I-D.cavage-http-signatures]
2048	              Cavage, M. and M. Sporny, "Signing HTTP Messages", draft-
2049	              cavage-http-signatures-11 (work in progress), April 2019.

2051	   [I-D.ietf-httpbis-cache]
2052	              Fielding, R., Nottingham, M., and J. Reschke, "HTTP
2053	              Caching", draft-ietf-httpbis-cache-04 (work in progress),
2054	              March 2019.

2056	   [I-D.ietf-httpbis-http2-secondary-certs]
2057	              Bishop, M., Sullivan, N., and M. Thomson, "Secondary
2058	              Certificate Authentication in HTTP/2", draft-ietf-httpbis-
2059	              http2-secondary-certs-04 (work in progress), April 2019.

2061	   [I-D.thomson-http-content-signature]
2062	              Thomson, M., "Content-Signature Header Field for HTTP",
2063	              draft-thomson-http-content-signature-00 (work in
2064	              progress), July 2015.

2066	   [I-D.yasskin-httpbis-origin-signed-exchanges-impl]
2067	              Yasskin, J. and K. Ueno, "Signed HTTP Exchanges
2068	              Implementation Checkpoints", draft-yasskin-httpbis-origin-
2069	              signed-exchanges-impl-02 (work in progress), September
2070	              2018.

2072	   [I-D.yasskin-webpackage-use-cases]
2073	              Yasskin, J., "Use Cases and Requirements for Web
2074	              Packages", draft-yasskin-webpackage-use-cases-01 (work in
2075	              progress), March 2018.

2077	   [OneCrl]   Goodwin, M., "Revoking Intermediate Certificates:
2078	              Introducing OneCRL", March 2015,
2079	              <https://blog.mozilla.org/security/2015/03/03/
2080	              revoking-intermediate-certificates-introducing-onecrl/>.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2146	   [W3C.NOTE-OPS-OverHTTP]
2147	              Hensley, P., Metral, M., Shardanand, U., Converse, D., and
2148	              M. Myers, "Implementation of OPS Over HTTP", W3C NOTE
2149	              NOTE-OPS-OverHTTP, June 1997.

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

2156	9.3.  URIs

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

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

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

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

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

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

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

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

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

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

2179	   [11] https://calendar.perfplanet.com/2013/big-bad-preloader/

2181	   [12] https://github.com/mikewest/signature-based-sri

2183	   [13] https://github.com/mikewest/signature-based-sri/issues/5

2185	   [14] https://www.apple.com/ios/app-store/

2187	   [15] https://play.google.com/store

2189	   [16] https://github.com/WICG/webpackage

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

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

2196	Appendix A.  Use cases

2198	A.1.  PUSHed subresources

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

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

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

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

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

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

2225	   <img logicalsrc="https://O.com/img.png"
2226	        physicalsrc="https://distributor.com/O.com/img.png">

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

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

2234	   where the "<dist-img>" implementation generates an appropriate
2235	   "<img>" based on, for example, a "<meta name="dist-base">" tag
2236	   elsewhere in the page.  However, this has the downside that the
2237	   preloader [11] can no longer see the physical source to download it.
2238	   The resulting delay might cancel out the benefit of using a
2239	   distributor.

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

2244	   To implement this with the current proposal, the distributor would
2245	   respond to the physical request to "https://distributor.com/O.com/
2246	   img.png" with first a signed PUSH_PROMISE for "https://O.com/img.png"
2247	   and then a redirect to "https://O.com/img.png".

2249	A.3.  Subresource Integrity

2251	   The W3C WebAppSec group is investigating using signatures [12] in
2252	   [SRI].  They need a way to transmit the signature with the response,
2253	   which this proposal provides.

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

2260	   The "ed25519key" signature parameter supports this simpler way of
2261	   attaching a key.

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

2270	A.4.  Binary Transparency

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

2279	   Certificate Transparency depends on Signed Certificate Timestamps
2280	   that prove a log contained a particular certificate at a particular
2281	   time.  To build the same thing for Binary Transparency logs
2282	   containing HTTP resources or full websites, we'll need a way to
2283	   provide signatures of those resources, which signed exchanges
2284	   provides.

2286	A.5.  Static Analysis

2288	   Native app stores like the Apple App Store [14] and the Android Play
2289	   Store [15] grant their contents powerful abilities, which they
2290	   attempt to make safe by analyzing the applications before offering
2291	   them to people.  The web has no equivalent way for people to wait to
2292	   run an update of a web application until a trusted authority has
2293	   vouched for it.

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

2300	A.6.  Offline websites

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

2307	Appendix B.  Requirements

2309	B.1.  Proof of origin

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

2317	B.1.1.  Certificate constraints

2319	   If we re-use existing TLS server certificates, we incur the risks
2320	   that:

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

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

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

2336	B.1.2.  Signature constraints

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

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

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

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

2356	B.1.3.  Retrieving the certificate

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

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

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

2381	B.2.  How much to sign

2383	   The previous [I-D.thomson-http-content-signature] and
2384	   [I-D.burke-content-signature] schemes signed just the content, while
2385	   ([I-D.cavage-http-signatures] could also sign the response headers
2386	   and the request method and path.  However, the same path, response
2387	   headers, and content may mean something very different when retrieved
2388	   from a different server.  Section 5.1.1 currently includes the whole
2389	   request URL in the signature, but it's possible we need a more
2390	   flexible scheme to allow some higher-level protocols to accept a
2391	   less-signed URL.

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

2402	B.2.1.  Conveying the signed headers

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

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

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

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

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

2431	B.3.  Response lifespan

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

2440	B.3.1.  Certificate revocation

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

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

2454	B.3.2.  Response downgrade attacks

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

2464	   These assertions could be structured as:

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

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

2477	   3.  A replacement for the exchange's signature and an update for the
2478	       embedded "expires" and related cache-control HTTP headers
2479	       [RFC7234].  This naturally extends publishers' intuitions about
2480	       cache expiration and the existing cache revalidation behavior to
2481	       signed exchanges.  This is sketched and its downsides explored in
2482	       Appendix C.

2484	   The signature also needs to include instructions to intermediates for
2485	   how to fetch updated validity assertions.

2487	B.4.  Low implementation complexity

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

2493	B.4.1.  Limited choices

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

2499	B.4.2.  Bounded-buffering integrity checking

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

2508	   To allow the network layer to verify signed exchanges using a bounded
2509	   amount of memory, Section 5.3 requires the signature to be less than
2510	   16kB and the headers to be less than 512kB, and Section 3.5 requires
2511	   that the MI record size be less than 16kB.  This allows the network
2512	   layer to validate a bounded chunk at a time, and pass that chunk on
2513	   to a renderer, and then forget about that chunk before processing the
2514	   next one.

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

2519	Appendix C.  Determining validity using cache control

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

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

2529	   The validity-checking algorithm (Section 3.5) would initialize "date"
2530	   from the resource's "Date" header field (Section 7.1.1.2 of
2531	   [RFC7231]) and initialize "expires" from either the "Expires" header
2532	   field (Section 5.3 of [RFC7234]) or the "Cache-Control" header
2533	   field's "max-age" directive (Section 5.2.2.8 of [RFC7234]) (added to
2534	   "date"), whichever is present, preferring "max-age" (or failing) if
2535	   both are present.

2537	   Validity updates (Section 3.6) would include a list of replacement
2538	   response header fields.  For each header field name in this list, the
2539	   client would remove matching header fields from the stored exchange's
2540	   response header fields.  Then the client would append the replacement
2541	   header fields to the stored exchange's response header fields.

2543	C.1.  Example of updating cache control

2545	   For example, given a stored exchange of:

2547	   GET  / HTTP/1.1
2548	   Host: example.com
2549	   Accept: */*

2551	   HTTP/1.1 200
2552	   Date: Mon, 20 Nov 2017 10:00:00 UTC
2553	   Content-Type: text/html
2554	   Date: Tue, 21 Nov 2017 10:00:00 UTC
2555	   Expires: Sun, 26 Nov 2017 10:00:00 UTC

2557	   <!doctype html>
2558	   <html>
2559	   ...

2561	   And an update listing the following headers:

2563	   Expires: Fri, 1 Dec 2017 10:00:00 UTC
2564	   Date: Sat, 25 Nov 2017 10:00:00 UTC

2566	   The resulting stored exchange would be:

2568	   GET / HTTP/1.1
2569	   Host: example.com
2570	   Accept: */*

2572	   HTTP/1.1 200
2573	   Content-Type: text/html
2574	   Expires: Fri, 1 Dec 2017 10:00:00 UTC
2575	   Date: Sat, 25 Nov 2017 10:00:00 UTC

2577	   <!doctype html>
2578	   <html>
2579	   ...

2581	C.2.  Downsides of updating cache control

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

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

2594	Appendix D.  Change Log

2596	   RFC EDITOR PLEASE DELETE THIS SECTION.

2598	   draft-06

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

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

2605	   o  Limit certificate lifetimes to 90 days.

2607	   o  UTF-8 decode the fallback URL.

2609	   draft-05

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

2613	   o  Fill in TBD size limits.

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

2617	   o  Refer to draft-yasskin-httpbis-origin-signed-exchanges-impl for
2618	      draft version numbers.

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

2622	   o  Define the "integrity" field of the Signature header to include
2623	      subfields of the main integrity-protecting header, including the
2624	      digest algorithm.

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

2631	   o  Remove the rest of the request headers from the signed data, in
2632	      favor of representing content negotiation with the "Variants"
2633	      response header.

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

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

2642	   o  Reject uncached header fields.

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

2646	   o  Update to the final TLS 1.3 RFC.

2648	   draft-04

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

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

2655	      *  Doesn't require a streaming CBOR parser parse it from a network
2656	         stream.

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

2661	      *  Allows checking the signature before parsing the exchange
2662	         headers.

2664	   o  Require absolute URLs.

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

2669	   o  Switch back to the TLS 1.3 signature format.

2671	   o  Include the version and draft number in the signature context
2672	      string.

2674	   o  Remove support for integrity protection using the Digest header
2675	      field.

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

2679	   o  Forbid RSA keys, and only require clients to support secp256r1
2680	      keys.

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

2684	   draft-03

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

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

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

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

2701	   draft-02

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

2706	   o  The validityUrl is signed.

2708	   o  Use CBOR maps where appropriate, and define how they're
2709	      canonicalized.

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

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

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

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

2723	   o  2 new use cases.

2725	Appendix E.  Acknowledgements

2727	   Thanks to Andrew Ayer, Devin Mullins, Ilari Liusvaara, Justin Schuh,
2728	   Mark Nottingham, Mike Bishop, Ryan Sleevi, and Yoav Weiss for
2729	   comments that improved this draft.

2731	Author's Address

2733	   Jeffrey Yasskin
2734	   Google

2736	   Email: jyasskin@chromium.org