idnits 2.17.1 

draft-yasskin-http-origin-signed-responses-05.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 (January 23, 2019) is 1920 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 2035

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  -- 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 6962 (Obsoleted by RFC 9162)

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

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

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

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

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

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

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

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

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

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

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

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

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 July 27, 2019.

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  . . . . . . . . . . . . . . . . . . .   8
72	     3.2.  CBOR representation of exchange response headers  . . . .   9
73	       3.2.1.  Example . . . . . . . . . . . . . . . . . . . . . . .   9
74	     3.3.  Loading a certificate chain . . . . . . . . . . . . . . .  10
75	     3.4.  Canonical CBOR serialization  . . . . . . . . . . . . . .  11
76	     3.5.  Signature validity  . . . . . . . . . . . . . . . . . . .  11
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 . . . . . . . . . . . . . . .  18
81	       3.7.1.  Integrity identifiers . . . . . . . . . . . . . . . .  19
82	       3.7.2.  Key type identifiers  . . . . . . . . . . . . . . . .  19
83	       3.7.3.  Key value identifiers . . . . . . . . . . . . . . . .  20
84	       3.7.4.  Examples  . . . . . . . . . . . . . . . . . . . . . .  20
85	       3.7.5.  Open Questions  . . . . . . . . . . . . . . . . . . .  21
86	   4.  Cross-origin trust  . . . . . . . . . . . . . . . . . . . . .  21
87	     4.1.  Uncached header fields  . . . . . . . . . . . . . . . . .  23
88	       4.1.1.  Stateful header fields  . . . . . . . . . . . . . . .  23
89	     4.2.  Certificate Requirements  . . . . . . . . . . . . . . . .  24
90	   5.  Transferring a signed exchange  . . . . . . . . . . . . . . .  25
91	     5.1.  Same-origin response  . . . . . . . . . . . . . . . . . .  25
92	       5.1.1.  Serialized headers for a same-origin response . . . .  26
93	       5.1.2.  The Signed-Headers Header . . . . . . . . . . . . . .  26
94	     5.2.  HTTP/2 extension for cross-origin Server Push . . . . . .  27
95	       5.2.1.  Indicating support for cross-origin Server Push . . .  27
96	       5.2.2.  NO_TRUSTED_EXCHANGE_SIGNATURE error code  . . . . . .  27
97	       5.2.3.  Validating a cross-origin Push  . . . . . . . . . . .  28
98	     5.3.  application/signed-exchange format  . . . . . . . . . . .  29
99	       5.3.1.  Cross-origin trust in application/signed-exchange . .  30
100	       5.3.2.  Example . . . . . . . . . . . . . . . . . . . . . . .  30
101	       5.3.3.  Open Questions  . . . . . . . . . . . . . . . . . . .  30
102	   6.  Security considerations . . . . . . . . . . . . . . . . . . .  31
103	     6.1.  Over-signing  . . . . . . . . . . . . . . . . . . . . . .  31
104	       6.1.1.  Session fixation  . . . . . . . . . . . . . . . . . .  31
105	       6.1.2.  Misleading content  . . . . . . . . . . . . . . . . .  31
106	     6.2.  Off-path attackers  . . . . . . . . . . . . . . . . . . .  32
107	     6.3.  Downgrades  . . . . . . . . . . . . . . . . . . . . . . .  32
108	     6.4.  Signing oracles are permanent . . . . . . . . . . . . . .  32
109	     6.5.  Unsigned headers  . . . . . . . . . . . . . . . . . . . .  32
110	     6.6.  application/signed-exchange . . . . . . . . . . . . . . .  33
111	     6.7.  Key re-use with TLS . . . . . . . . . . . . . . . . . . .  33
112	     6.8.  Content sniffing  . . . . . . . . . . . . . . . . . . . .  34
113	   7.  Privacy considerations  . . . . . . . . . . . . . . . . . . .  35
114	   8.  IANA considerations . . . . . . . . . . . . . . . . . . . . .  35
115	     8.1.  Signature Header Field Registration . . . . . . . . . . .  35
116	     8.2.  Accept-Signature Header Field Registration  . . . . . . .  36
117	     8.3.  Signed-Headers Header Field Registration  . . . . . . . .  36
118	     8.4.  HTTP/2 Settings . . . . . . . . . . . . . . . . . . . . .  36
119	     8.5.  HTTP/2 Error code . . . . . . . . . . . . . . . . . . . .  37
120	     8.6.  Internet Media Type application/signed-exchange . . . . .  37
121	     8.7.  Internet Media Type application/cert-chain+cbor . . . . .  38
122	   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  39
123	     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  39
124	     9.2.  Informative References  . . . . . . . . . . . . . . . . .  41
125	     9.3.  URIs  . . . . . . . . . . . . . . . . . . . . . . . . . .  44
126	   Appendix A.  Use cases  . . . . . . . . . . . . . . . . . . . . .  44
127	     A.1.  PUSHed subresources . . . . . . . . . . . . . . . . . . .  44
128	     A.2.  Explicit use of a content distributor for subresources  .  45
129	     A.3.  Subresource Integrity . . . . . . . . . . . . . . . . . .  46
130	     A.4.  Binary Transparency . . . . . . . . . . . . . . . . . . .  46
131	     A.5.  Static Analysis . . . . . . . . . . . . . . . . . . . . .  46
132	     A.6.  Offline websites  . . . . . . . . . . . . . . . . . . . .  47
133	   Appendix B.  Requirements . . . . . . . . . . . . . . . . . . . .  47
134	     B.1.  Proof of origin . . . . . . . . . . . . . . . . . . . . .  47
135	       B.1.1.  Certificate constraints . . . . . . . . . . . . . . .  47
136	       B.1.2.  Signature constraints . . . . . . . . . . . . . . . .  47
137	       B.1.3.  Retrieving the certificate  . . . . . . . . . . . . .  48
138	     B.2.  How much to sign  . . . . . . . . . . . . . . . . . . . .  48
139	       B.2.1.  Conveying the signed headers  . . . . . . . . . . . .  49
140	     B.3.  Response lifespan . . . . . . . . . . . . . . . . . . . .  49
141	       B.3.1.  Certificate revocation  . . . . . . . . . . . . . . .  50
142	       B.3.2.  Response downgrade attacks  . . . . . . . . . . . . .  50
143	     B.4.  Low implementation complexity . . . . . . . . . . . . . .  51
144	       B.4.1.  Limited choices . . . . . . . . . . . . . . . . . . .  51
145	       B.4.2.  Bounded-buffering integrity checking  . . . . . . . .  51
146	   Appendix C.  Determining validity using cache control . . . . . .  51
147	     C.1.  Example of updating cache control . . . . . . . . . . . .  52
148	     C.2.  Downsides of updating cache control . . . . . . . . . . .  53
149	   Appendix D.  Change Log . . . . . . . . . . . . . . . . . . . . .  53
150	   Appendix E.  Acknowledgements . . . . . . . . . . . . . . . . . .  55
151	   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  56

153	1.  Introduction

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

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

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

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

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

181	2.  Terminology

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

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

192	   Publisher  The entity that controls the server for a particular
193	      origin [RFC6454].  The publisher can get a CA to issue
194	      certificates for their private keys and can run a TLS server for
195	      their origin.

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

207	   Intermediate  An entity that fetches signed HTTP exchanges from a
208	      publisher or another intermediate and forwards them to another
209	      intermediate or a client.

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

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

217	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
218	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
219	   "OPTIONAL" in this document are to be interpreted as described in BCP
220	   14 [RFC2119] [RFC8174] when, and only when, they appear in all
221	   capitals, as shown here.

223	3.  Signing an exchange

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

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

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

244	3.1.  The Signature Header

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

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

257	   Signature = sh-param-list

259	   Each parameterised identifier in the list MUST have parameters named
260	   "sig", "integrity", "validity-url", "date", and "expires".  Each
261	   parameterised identifier MUST also have either "cert-url" and "cert-
262	   sha256" parameters or an "ed25519key" parameter.  This specification
263	   gives no meaning to the identifier itself, which can be used as a
264	   human-readable identifier for the signature (see
265	   Section 3.1.2, Paragraph 1).  The present parameters MUST have the
266	   following values:

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

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

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

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

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

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

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

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

303	3.1.1.  Examples

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

309	Signature:
310	 sig1;
311	  sig=*MEUCIQDXlI2gN3RNBlgFiuRNFpZXcDIaUpX6HIEwcZEc0cZYLAIga9DsVOMM+g5YpwEBdGW3sS+bvnmAJJiSMwhuBdqp5UY=*;
312	  integrity="digest/mi-sha256";
313	  validity-url="https://example.com/resource.validity.1511128380";
314	  cert-url="https://example.com/oldcerts";
315	  cert-sha256=*W7uB969dFW3Mb5ZefPS9Tq5ZbH5iSmOILpjv2qEArmI=*;
316	  date=1511128380; expires=1511733180,
317	 sig2;
318	  sig=*MEQCIGjZRqTRf9iKNkGFyzRMTFgwf/BrY2ZNIP/dykhUV0aYAiBTXg+8wujoT4n/W+cNgb7pGqQvIUGYZ8u8HZJ5YH26Qg=*;
319	  integrity="digest/mi-sha256";
320	  validity-url="https://example.com/resource.validity.1511128380";
321	  cert-url="https://example.com/newcerts";
322	  cert-sha256=*J/lEm9kNRODdCmINbvitpvdYKNQ+YgBj99DlYp4fEXw=*;
323	  date=1511128380; expires=1511733180,
324	 srisig;
325	  sig=*lGZVaJJM5f2oGczFlLmBdKTDL+QADza4BgeO494ggACYJOvrof6uh5OJCcwKrk7DK+LBch0jssDYPp5CLc1SDA=*
326	  integrity="digest/mi-sha256";
327	  validity-url="https://example.com/resource.validity.1511128380";
328	  ed25519key=*zsSevyFsxyZHiUluVBDd4eypdRLTqyWRVOJuuKUz+A8=*
329	  date=1511128380; expires=1511733180,
330	 thirdpartysig;
331	  sig=*MEYCIQCNxJzn6Rh2fNxsobktir8TkiaJYQFhWTuWI1i4PewQaQIhAMs2TVjc4rTshDtXbgQEOwgj2mRXALhfXPztXgPupii+=*;
332	  integrity="digest/mi-sha256";
333	  validity-url="https://thirdparty.example.com/resource.validity.1511161860";
334	  cert-url="https://thirdparty.example.com/certs";
335	  cert-sha256=*UeOwUPkvxlGRTyvHcsMUN0A2oNsZbU8EUvg8A9ZAnNc=*;
336	  date=1511133060; expires=1511478660,
337	   There are 4 signatures: 2 from different secp256r1 certificates
338	   within "https://example.com/", one using a raw ed25519 public key
339	   that's also controlled by "example.com", and a fourth using a
340	   secp256r1 certificate owned by "thirdparty.example.com".

342	   All 4 signatures rely on the "Digest" response header with the mi-
343	   sha256 digest algorithm to guard the integrity of the response
344	   payload.

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

352	   The certificates at "https://example.com/oldcerts" and
353	   "https://example.com/newcerts" have "subjectAltName"s of
354	   "example.com", meaning that if they and their signatures validate,
355	   the exchange can be trusted as having an origin of
356	   "https://example.com/".  The publisher might be using two
357	   certificates because their readers have disjoint sets of roots in
358	   their trust stores.

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

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

369	3.1.2.  Open Questions

371	   [I-D.ietf-httpbis-header-structure] provides a way to parameterise
372	   identifiers but not other supported types like byte sequences.  If
373	   the "Signature" header field is notionally a list of parameterised
374	   signatures, maybe we should add a "parameterised byte sequence" type.

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

382	3.2.  CBOR representation of exchange response headers

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

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

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

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

401	3.2.1.  Example

403	   Given the HTTP exchange:

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

409	   HTTP/1.1 200
410	   Content-Type: text/html
411	   Digest: mi-sha256=dcRDgR2GM35DluAV13PzgnG6+pvQwPywfFvAu1UeFrs=
412	   Signed-Headers: "content-type", "digest"

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

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

422	   {
423	     'digest': 'mi-sha256=dcRDgR2GM35DluAV13PzgnG6+pvQwPywfFvAu1UeFrs=',
424	     ':status': '200',
425	     'content-type': 'text/html'
426	   }

428	3.3.  Loading a certificate chain

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

434	   cert-chain = [
435	     "&#128220;&#9939;", ; U+1F4DC U+26D3
436	     + {
437	       cert: bytes,
438	       ? ocsp: bytes,
439	       ? sct: bytes,
440	       * tstr => any,
441	     }
442	   ]

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

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

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

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

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

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

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

477	   3.  Return "certificate-chain".

479	3.4.  Canonical CBOR serialization

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

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

488	   o  Items MUST NOT be encoded with indefinite length.

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

494	      1.  10, encoded as 0A.

496	      2.  100, encoded as 18 64.

498	      3.  -1, encoded as 20.

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

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

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

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

508	      8.  false, encoded as F4.

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

514	3.5.  Signature validity

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

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

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

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

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

539	   Potentially-valid results include:

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

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

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

553	   1.   Let:

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

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

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

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

564	        *  "cert-sha256" be the signature's "cert-sha256" parameter, if
565	           any.

567	        *  "ed25519key" be the signature's "ed25519key" parameter, if
568	           any.

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

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

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

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

581	            1.  Let "certificate-chain" be the result of loading the
582	                certificate chain at "cert-url" passing the "forceFetch"
583	                flag (Section 3.3).  If this returns "invalid", return
584	                "invalid".

586	            2.  Let "main-certificate" be the first certificate in
587	                "certificate-chain".

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

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

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

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

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

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

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

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

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

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

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

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

629	        4.  If "cert-sha256" is set, a byte holding the value 32
630	            followed by the 32 bytes of the value of "cert-sha256".
631	            Otherwise a 0 byte.

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

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

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

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

643	        9.  The 8-byte big-endian encoding of the length in bytes of
644	            "responseHeaders", followed by the bytes of
645	            "responseHeaders".

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

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

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

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

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

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

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

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

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

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

713	3.5.1.  Open Questions

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

718	3.6.  Updating signature validity

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

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

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

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

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

740	   validity = {
741	     ? signatures: [ + bytes ]
742	     ? update: {
743	       ? size: uint,
744	     }
745	   ]

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

754	   If the the "update" map is present, that indicates that a new version
755	   of the signed exchange is available at its effective request URI
756	   (Section 5.5 of [RFC7230]) and can give an estimate of the size of
757	   the updated exchange ("update.size").  If the signed exchange is
758	   currently the most recent version, the "update" SHOULD NOT be
759	   present.

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

765	3.6.1.  Examples

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

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

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

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

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

821	Signature:
822	 sig1;
823	  sig=*MEQCIC...*;
824	  ...
825	  validity-url="https://example.com/resource.validity.1511157180";
826	  cert-url="https://example.com/newcerts";
827	  date=1511733180; expires=1512337980,
828	 thirdpartysig;
829	  sig=*MEYCIQ...*;
830	  ...
831	  validity-url="https://thirdparty.example.com/resource.validity.1511161860";
832	  cert-url="https://thirdparty.example.com/certs";
833	  date=1511478660; expires=1511824260

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

839	3.7.  The Accept-Signature header

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

848	   When a server receives an "Accept-Signature" header field in a client
849	   request, it SHOULD reply with any available "Signature" header fields
850	   for its response that the "Accept-Signature" header field indicates
851	   the client supports.  However, if the "Accept-Signature" value
852	   violates a requirement in this section, the server MUST behave as if
853	   it hadn't received any "Accept-Signature" header at all.

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

860	   Accept-Signature = sh-param-list

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

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

874	3.7.1.  Integrity identifiers

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

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

888	3.7.2.  Key type identifiers

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

894	   If the "Accept-Signature" header field is present, servers SHOULD
895	   assume support for "ecdsa/secp256r1" unless the header field states
896	   otherwise.

898	3.7.3.  Key value identifiers

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

909	Accept-Signature: ..., ed25519key; *11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo=*
910	Accept-Signature: ..., ed25519key; *11qYAYKxCrfVS/7TyWQHOg==*
911	Accept-Signature: ..., ed25519key; *11qYAQ==*
912	Accept-Signature: ..., ed25519key; **

914	   but not

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

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

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

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

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

931	3.7.4.  Examples

933	   Accept-Signature: digest/mi-sha256

935	   states that the client will accept signatures with payload integrity
936	   assured by the "Digest" header and "mi-sha256" digest algorithm and
937	   implies that the client will accept signatures from ECDSA keys on the
938	   secp256r1 curve.

940	   Accept-Signature: -ecdsa/secp256r1, ecdsa/secp384r1
941	   states that the client will accept ECDSA keys on the secp384r1 curve
942	   but not the secp256r1 curve and payload integrity assured with the
943	   "Digest: mi-sha256" header field.

945	3.7.5.  Open Questions

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

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

956	   Do I have the right structure for the identifiers indicating feature
957	   support?

959	4.  Cross-origin trust

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

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

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

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

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

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

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

988	   3.  Let "response" be the response metadata and headers parsed out of
989	       "responseHeaders".

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

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

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

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

1004	       1.  Use "certificate-chain" to validate that its first entry,
1005	           "main-certificate" is trusted as "authority"'s server
1006	           certificate ([RFC5280] and other undocumented conventions).
1007	           Let "path" be the path that was used from the "main-
1008	           certificate" to a trusted root, including the "main-
1009	           certificate" but excluding the root.

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

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

1021	       4.  Validate that valid SCTs from trusted logs are available from
1022	           any of:

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

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

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

1033	           as described by Section 3.3 of [RFC6962].

1035	   8.  Return "valid".

1037	4.1.  Uncached header fields

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

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

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

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

1051	      *  Connection

1053	      *  Keep-Alive

1055	      *  Proxy-Connection

1057	      *  Trailer

1059	      *  Transfer-Encoding

1061	      *  Upgrade

1063	   o  Stateful headers as defined below.

1065	4.1.1.  Stateful header fields

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

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

1077	   o  "Authentication-Control", [RFC8053]

1079	   o  "Authentication-Info", [RFC7615]

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

1083	   o  "Optional-WWW-Authenticate", [RFC8053]
1084	   o  "Proxy-Authenticate", [RFC7235]

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

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

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

1092	   o  "Set-Cookie", [RFC6265]

1094	   o  "Set-Cookie2", [RFC2965]

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

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

1100	   o  "WWW-Authenticate", [RFC7235]

1102	4.2.  Certificate Requirements

1104	   We define a new X.509 extension, CanSignHttpExchanges to be used in
1105	   the certificate when the certificate permits the usage of signed
1106	   exchanges.  When this extension is not present the client MUST NOT
1107	   accept a signature from the certificate as proof that a signed
1108	   exchange is authoritative for a domain covered by the certificate.
1109	   When it is present, the client MUST follow the validation procedure
1110	   in Section 4.

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

1114	      CanSignHttpExchanges ::= NULL

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

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

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

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

1130	   Conforming CAs MUST NOT mark this extension as critical.

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

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

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

1140	   Implementations of drafts of this specification MAY recognize the
1141	   "id-ce-canSignHttpExchangesDraft" OID as identifying the
1142	   CanSignHttpExchanges extension.  This OID might or might not be used
1143	   as the final OID for the extension, so certificates including it
1144	   might need to be reissued once the final RFC is published.

1146	5.  Transferring a signed exchange

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

1151	5.1.  Same-origin response

1153	   The signature for a signed exchange can be included in a normal HTTP
1154	   response.  Because different clients send different request header
1155	   fields, clients don't know how the server's content negotiation
1156	   algorithm works, and intermediate servers add response header fields,
1157	   it can be impossible to have a signature for the exchange's exact
1158	   request, content negotiation, and response.  Therefore, when a client
1159	   calls the validation procedure in Section 3.5) to validate the
1160	   "Signature" header field for an exchange represented as a normal HTTP
1161	   request/response pair, it MUST pass:

1163	   o  The "Signature" header field,

1165	   o  The effective request URI (Section 5.5 of [RFC7230]) of the
1166	      request,

1168	   o  The serialized headers defined by Section 5.1.1, and

1170	   o  The response's payload.

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

1176	   If the signed response includes a "Variants" header field, the client
1177	   MUST use the cache behavior algorithm in Section 4 of
1178	   [I-D.ietf-httpbis-variants] to check that the signed response is an
1179	   appropriate representation for the request the client is trying to
1180	   fulfil.  If the response is not an appropriate representation, the
1181	   client MUST treat the signature as invalid.

1183	5.1.1.  Serialized headers for a same-origin response

1185	   The serialized headers of an exchange represented as a normal HTTP
1186	   request/response pair (Section 2.1 of [RFC7230] or Section 8.1 of
1187	   [RFC7540]) are the canonical serialization (Section 3.4) of the CBOR
1188	   representation (Section 3.2) of the response status code (Section 6
1189	   of [RFC7231]) and the response header fields whose names are listed
1190	   in that response's "Signed-Headers" header field (Section 5.1.2).  If
1191	   a response header field name from "Signed-Headers" does not appear in
1192	   the response's header fields, the exchange has no serialized headers.

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

1200	5.1.1.1.  Open Questions

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

1205	5.1.2.  The Signed-Headers Header

1207	   The "Signed-Headers" header field identifies an ordered list of
1208	   response header fields to include in a signature.  The request URL
1209	   and response status are included unconditionally.  This allows a TLS-
1210	   terminating intermediate to reorder headers without breaking the
1211	   signature.  This _can_ also allow the intermediate to add headers
1212	   that will be ignored by some higher-level protocols, but Section 3.5
1213	   provides a hook to let other higher-level protocols reject such
1214	   insecure headers.

1216	   This header field appears once instead of being incorporated into the
1217	   signatures' parameters because the signed header fields need to be
1218	   consistent across all signatures of an exchange, to avoid forcing
1219	   higher-level protocols to merge the header field lists of valid
1220	   signatures.

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

1226	   Signed-Headers = sh-list
1227	   Each element of the "Signed-Headers" list must be a lowercase string
1228	   (Section 3.8 of [I-D.ietf-httpbis-header-structure]) naming an HTTP
1229	   response header field.  Pseudo-header field names (Section 8.1.2.1 of
1230	   [RFC7540]) MUST NOT appear in this list.

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

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

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

1242	5.2.1.  Indicating support for cross-origin Server Push

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

1248	   An ENABLE_CROSS_ORIGIN_PUSH value of 0 indicates that the client does
1249	   not support cross-origin Push.  A value of 1 indicates that the
1250	   client does support cross-origin Push.

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

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

1264	5.2.2.  NO_TRUSTED_EXCHANGE_SIGNATURE error code

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

1273	5.2.2.1.  Open Questions

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

1277	5.2.3.  Validating a cross-origin Push

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

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

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

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

1297	   3.  Run the algorithm in Section 4 over:

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

1301	       *  The effective request URI from the PUSH_PROMISE.

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

1307	       *  The response's payload.

1309	       If this returns "invalid", the client MUST treat the response as
1310	       a stream error (Section 5.4.2 of [RFC7540]) of type
1311	       NO_TRUSTED_EXCHANGE_SIGNATURE.  Otherwise, the client MUST treat
1312	       the pushed response as if the server were authoritative for the
1313	       PUSH_PROMISE's authority.

1315	5.2.3.1.  Open Questions

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

1322	5.3.  application/signed-exchange format

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

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

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

1335	   o  X-Content-Type-Options: nosniff

1337	   This content type consists of the concatenation of the following
1338	   items:

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

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

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

1352	   3.  "fallbackUrlLength" bytes holding a "fallbackUrl", which MUST be
1353	       an absolute URL with a scheme of "https".

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

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

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

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

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

1371	   7.  "headerLength" bytes holding "signedHeaders", the canonical
1372	       serialization (Section 3.4) of the CBOR representation of the
1373	       response headers of the exchange represented by the "application/
1374	       signed-exchange" resource (Section 3.2), excluding the
1375	       "Signature" header field.

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

1380	       Note that the use of the payload body here means that a
1381	       "Transfer-Encoding" header field inside the "application/signed-
1382	       exchange" header block has no effect.  A "Transfer-Encoding"
1383	       header field on the outer HTTP response that transfers this
1384	       resource still has its normal effect.

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

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

1393	5.3.2.  Example

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

1402	   sxg1\0\0\0\0<2-byte length of the following url string>
1403	   https://example.com/<3-byte length of the following header
1404	   value><3-byte length of the encoding of the
1405	   following map>sig1; sig=*...; integrity="digest/mi-sha256"; ...{
1406	     ':status': '200',
1407	     'content-type': 'text/html'
1408	   }<!doctype html>\r\n<html>...

1410	5.3.3.  Open Questions

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

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

1417	6.  Security considerations

1419	6.1.  Over-signing

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

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

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

1435	   2.  Only sign exchanges where the response includes a "Cache-Control:
1436	       public" header.  Clients are not required to fail signature-
1437	       checking for exchanges that omit this "Cache-Control" response
1438	       header field to reduce the risk that naive signing systems
1439	       blindly add it.

1441	6.1.1.  Session fixation

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

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

1454	6.1.2.  Misleading content

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

1461	   Stripping authentication information from requests before sending
1462	   them to backends is likely to prevent the backend from showing
1463	   attacker-specific information in the signed response.  It does not
1464	   prevent the attacker from showing their victim a signed-out page when
1465	   the victim is actually signed in, but while this is still misleading,
1466	   it seems less likely to be useful to the attacker.

1468	6.2.  Off-path attackers

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

1479	6.3.  Downgrades

1481	   Signing a bad response can affect more users than simply serving a
1482	   bad response, since a served response will only affect users who make
1483	   a request while the bad version is live, while an attacker can
1484	   forward a signed response until its signature expires.  Publishers
1485	   should consider shorter signature expiration times than they use for
1486	   cache expiration times.

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

1494	6.4.  Signing oracles are permanent

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

1504	6.5.  Unsigned headers

1506	   The use of a single "Signed-Headers" header field prevents us from
1507	   signing aspects of the request other than its effective request URI
1508	   (Section 5.5 of [RFC7230]).  For example, if a publisher signs both
1509	   "Content-Encoding: br" and "Content-Encoding: gzip" variants of a
1510	   response, what's the impact if an attacker serves the brotli one for
1511	   a request with "Accept-Encoding: gzip"?  This is mitigated by using

1513	   [I-D.ietf-httpbis-variants] instead of request headers to describe
1514	   how the client should run content negotiation.

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

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

1528	6.6.  application/signed-exchange

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

1536	6.7.  Key re-use with TLS

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

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

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

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

1553	   We require that clients reject certificates with the
1554	   CanSignHttpExchanges extension when making TLS connections to
1555	   minimize the chance that servers will re-use keys like this.
1556	   Ideally, we would make the extension critical so that even clients
1557	   that don't understand it would reject such TLS connections, but this
1558	   proved impossible because certificate-validating libraries ship on
1559	   significantly different schedules from the clients that use them.

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

1566	6.8.  Content sniffing

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

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

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

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

1589	   2.  Generate signed exchanges "offline", that is, in response to a
1590	       trusted author submitting content or existing signatures reaching
1591	       a certain age, rather than in response to untrusted-reader
1592	       queries.

1594	   3.  Do all of:

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

1603	       2.  Do not reflect request header fields into the set of response
1604	           headers.

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

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

1616	7.  Privacy considerations

1618	   Normally, when a client fetches "https://o1.com/resource.js",
1619	   "o1.com" learns that the client is interested in the resource.  If
1620	   "o1.com" signs "resource.js", "o2.com" serves it as "https://o2.com/
1621	   o1resource.js", and the client fetches it from there, then "o2.com"
1622	   learns that the client is interested, and if the client executes the
1623	   Javascript, that could also report the client's interest back to
1624	   "o1.com".

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

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

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

1643	8.  IANA considerations

1645	   TODO: possibly register the validity-url format.

1647	8.1.  Signature Header Field Registration

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

1652	   Header field name: "Signature"

1654	   Applicable protocol: http

1656	   Status: standard
1657	   Author/Change controller: IETF

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

1661	8.2.  Accept-Signature Header Field Registration

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

1666	   Header field name: "Accept-Signature"

1668	   Applicable protocol: http

1670	   Status: standard

1672	   Author/Change controller: IETF

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

1676	8.3.  Signed-Headers Header Field Registration

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

1681	   Header field name: "Signed-Headers"

1683	   Applicable protocol: http

1685	   Status: standard

1687	   Author/Change controller: IETF

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

1691	8.4.  HTTP/2 Settings

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

1696	   Name: ENABLE_CROSS_ORIGIN_PUSH

1698	   Code: 0xSETTING-TBD

1700	   Initial Value: 0

1702	   Specification: This document

1704	8.5.  HTTP/2 Error code

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

1709	   Name: NO_TRUSTED_EXCHANGE_SIGNATURE

1711	   Code: 0xERROR-TBD

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

1716	   Specification: This document

1718	8.6.  Internet Media Type application/signed-exchange

1720	   Type name: application

1722	   Subtype name: signed-exchange

1724	   Required parameters:

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

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

1742	   Optional parameters: N/A

1744	   Encoding considerations: binary

1746	   Security considerations: see Section 6.6

1748	   Interoperability considerations: N/A

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

1752	   Applications that use this media type: N/A

1754	   Fragment identifier considerations: N/A

1756	   Additional information:

1758	   Deprecated alias names for this type: N/A

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

1762	   File extension(s): .sxg

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

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

1769	   Intended usage: COMMON

1771	   Restrictions on usage: N/A

1773	   Author: See Authors' Addresses section.

1775	   Change controller: IESG

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

1779	   Type name: application

1781	   Subtype name: cert-chain+cbor

1783	   Required parameters: N/A

1785	   Optional parameters: N/A

1787	   Encoding considerations: binary

1789	   Security considerations: N/A

1791	   Interoperability considerations: N/A

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

1795	   Applications that use this media type: N/A

1797	   Fragment identifier considerations: N/A

1799	   Additional information:

1801	   Deprecated alias names for this type: N/A

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

1805	   File extension(s): N/A

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

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

1812	   Intended usage: COMMON

1814	   Restrictions on usage: N/A

1816	   Author: See Authors' Addresses section.

1818	   Change controller: IESG

1820	9.  References

1822	9.1.  Normative References

1824	   [FETCH]    WHATWG, "Fetch", January 2019,
1825	              <https://fetch.spec.whatwg.org/>.

1827	   [I-D.ietf-cbor-cddl]
1828	              Birkholz, H., Vigano, C., and C. Bormann, "Concise data
1829	              definition language (CDDL): a notational convention to
1830	              express CBOR and JSON data structures", draft-ietf-cbor-
1831	              cddl-06 (work in progress), November 2018.

1833	   [I-D.ietf-httpbis-header-structure]
1834	              Nottingham, M. and P. Kamp, "Structured Headers for HTTP",
1835	              draft-ietf-httpbis-header-structure-09 (work in progress),
1836	              December 2018.

1838	   [I-D.ietf-httpbis-variants]
1839	              Nottingham, M., "HTTP Representation Variants", draft-
1840	              ietf-httpbis-variants-04 (work in progress), October 2018.

1842	   [I-D.thomson-http-mice]
1843	              Thomson, M. and J. Yasskin, "Merkle Integrity Content
1844	              Encoding", draft-thomson-http-mice-03 (work in progress),
1845	              August 2018.

1847	   [POSIX]    IEEE and The Open Group, "The Open Group Base
1848	              Specifications Issue 7", name IEEE, value 1003.1-2008,
1849	              2016 Edition, 2016,
1850	              <http://pubs.opengroup.org/onlinepubs/9699919799/
1851	              basedefs/>.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1925	   [URL]      WHATWG, "URL", January 2019,
1926	              <https://url.spec.whatwg.org/>.

1928	9.2.  Informative References

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

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

1938	   [I-D.ietf-httpbis-cache]
1939	              Fielding, R., Nottingham, M., and J. Reschke, "HTTP
1940	              Caching", draft-ietf-httpbis-cache-03 (work in progress),
1941	              October 2018.

1943	   [I-D.ietf-httpbis-http2-secondary-certs]
1944	              Bishop, M., Sullivan, N., and M. Thomson, "Secondary
1945	              Certificate Authentication in HTTP/2", draft-ietf-httpbis-
1946	              http2-secondary-certs-03 (work in progress), October 2018.

1948	   [I-D.thomson-http-content-signature]
1949	              Thomson, M., "Content-Signature Header Field for HTTP",
1950	              draft-thomson-http-content-signature-00 (work in
1951	              progress), July 2015.

1953	   [I-D.yasskin-httpbis-origin-signed-exchanges-impl]
1954	              Yasskin, J. and K. Ueno, "Signed HTTP Exchanges
1955	              Implementation Checkpoints", draft-yasskin-httpbis-origin-
1956	              signed-exchanges-impl-02 (work in progress), September
1957	              2018.

1959	   [I-D.yasskin-webpackage-use-cases]
1960	              Yasskin, J., "Use Cases and Requirements for Web
1961	              Packages", draft-yasskin-webpackage-use-cases-01 (work in
1962	              progress), March 2018.

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

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

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

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

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

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

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

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

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

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

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

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

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

2023	   [W3C.NOTE-OPS-OverHTTP]
2024	              Hensley, P., Metral, M., Shardanand, U., Converse, D., and
2025	              M. Myers, "Implementation of OPS Over HTTP", W3C NOTE
2026	              NOTE-OPS-OverHTTP, June 1997.

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

2033	9.3.  URIs

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2073	Appendix A.  Use cases

2075	A.1.  PUSHed subresources

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

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

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

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

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

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

2102	   <img logicalsrc="https://O.com/img.png"
2103	        physicalsrc="https://distributor.com/O.com/img.png">

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

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

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

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

2121	   To implement this with the current proposal, the distributor would
2122	   respond to the physical request to "https://distributor.com/O.com/
2123	   img.png" with first a signed PUSH_PROMISE for "https://O.com/img.png"
2124	   and then a redirect to "https://O.com/img.png".

2126	A.3.  Subresource Integrity

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

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

2137	   The "ed25519key" signature parameter supports this simpler way of
2138	   attaching a key.

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

2147	A.4.  Binary Transparency

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

2156	   Certificate Transparency depends on Signed Certificate Timestamps
2157	   that prove a log contained a particular certificate at a particular
2158	   time.  To build the same thing for Binary Transparency logs
2159	   containing HTTP resources or full websites, we'll need a way to
2160	   provide signatures of those resources, which signed exchanges
2161	   provides.

2163	A.5.  Static Analysis

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

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

2177	A.6.  Offline websites

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

2184	Appendix B.  Requirements

2186	B.1.  Proof of origin

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

2194	B.1.1.  Certificate constraints

2196	   If we re-use existing TLS server certificates, we incur the risks
2197	   that:

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

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

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

2213	B.1.2.  Signature constraints

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

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

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

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

2233	B.1.3.  Retrieving the certificate

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

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

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

2258	B.2.  How much to sign

2260	   The previous [I-D.thomson-http-content-signature] and
2261	   [I-D.burke-content-signature] schemes signed just the content, while
2262	   ([I-D.cavage-http-signatures] could also sign the response headers
2263	   and the request method and path.  However, the same path, response
2264	   headers, and content may mean something very different when retrieved
2265	   from a different server.  Section 5.1.1 currently includes the whole
2266	   request URL in the signature, but it's possible we need a more
2267	   flexible scheme to allow some higher-level protocols to accept a
2268	   less-signed URL.

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

2279	B.2.1.  Conveying the signed headers

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

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

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

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

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

2308	B.3.  Response lifespan

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

2317	B.3.1.  Certificate revocation

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

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

2331	B.3.2.  Response downgrade attacks

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

2341	   These assertions could be structured as:

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

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

2354	   3.  A replacement for the exchange's signature and an update for the
2355	       embedded "expires" and related cache-control HTTP headers
2356	       [RFC7234].  This naturally extends publishers' intuitions about
2357	       cache expiration and the existing cache revalidation behavior to
2358	       signed exchanges.  This is sketched and its downsides explored in
2359	       Appendix C.

2361	   The signature also needs to include instructions to intermediates for
2362	   how to fetch updated validity assertions.

2364	B.4.  Low implementation complexity

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

2370	B.4.1.  Limited choices

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

2376	B.4.2.  Bounded-buffering integrity checking

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

2385	   To allow the network layer to verify signed exchanges using a bounded
2386	   amount of memory, Section 5.3 requires the signature to be less than
2387	   16kB and the headers to be less than 512kB, and Section 3.5 requires
2388	   that the MI record size be less than 16kB.  This allows the network
2389	   layer to validate a bounded chunk at a time, and pass that chunk on
2390	   to a renderer, and then forget about that chunk before processing the
2391	   next one.

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

2396	Appendix C.  Determining validity using cache control

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

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

2406	   The validity-checking algorithm (Section 3.5) would initialize "date"
2407	   from the resource's "Date" header field (Section 7.1.1.2 of
2408	   [RFC7231]) and initialize "expires" from either the "Expires" header
2409	   field (Section 5.3 of [RFC7234]) or the "Cache-Control" header
2410	   field's "max-age" directive (Section 5.2.2.8 of [RFC7234]) (added to
2411	   "date"), whichever is present, preferring "max-age" (or failing) if
2412	   both are present.

2414	   Validity updates (Section 3.6) would include a list of replacement
2415	   response header fields.  For each header field name in this list, the
2416	   client would remove matching header fields from the stored exchange's
2417	   response header fields.  Then the client would append the replacement
2418	   header fields to the stored exchange's response header fields.

2420	C.1.  Example of updating cache control

2422	   For example, given a stored exchange of:

2424	   GET  / HTTP/1.1
2425	   Host: example.com
2426	   Accept: */*

2428	   HTTP/1.1 200
2429	   Date: Mon, 20 Nov 2017 10:00:00 UTC
2430	   Content-Type: text/html
2431	   Date: Tue, 21 Nov 2017 10:00:00 UTC
2432	   Expires: Sun, 26 Nov 2017 10:00:00 UTC

2434	   <!doctype html>
2435	   <html>
2436	   ...

2438	   And an update listing the following headers:

2440	   Expires: Fri, 1 Dec 2017 10:00:00 UTC
2441	   Date: Sat, 25 Nov 2017 10:00:00 UTC

2443	   The resulting stored exchange would be:

2445	   GET / HTTP/1.1
2446	   Host: example.com
2447	   Accept: */*

2449	   HTTP/1.1 200
2450	   Content-Type: text/html
2451	   Expires: Fri, 1 Dec 2017 10:00:00 UTC
2452	   Date: Sat, 25 Nov 2017 10:00:00 UTC

2454	   <!doctype html>
2455	   <html>
2456	   ...

2458	C.2.  Downsides of updating cache control

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

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

2471	Appendix D.  Change Log

2473	   RFC EDITOR PLEASE DELETE THIS SECTION.

2475	   draft-05

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

2479	   o  Fill in TBD size limits.

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

2483	   o  Refer to draft-yasskin-httpbis-origin-signed-exchanges-impl for
2484	      draft version numbers.

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

2488	   o  Define the "integrity" field of the Signature header to include
2489	      subfields of the main integrity-protecting header, including the
2490	      digest algorithm.

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

2497	   o  Remove the rest of the request headers from the signed data, in
2498	      favor of representing content negotiation with the "Variants"
2499	      response header.

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

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

2508	   o  Reject uncached header fields.

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

2512	   o  Update to the final TLS 1.3 RFC.

2514	   draft-04

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

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

2521	      *  Doesn't require a streaming CBOR parser parse it from a network
2522	         stream.

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

2527	      *  Allows checking the signature before parsing the exchange
2528	         headers.

2530	   o  Require absolute URLs.

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

2535	   o  Switch back to the TLS 1.3 signature format.

2537	   o  Include the version and draft number in the signature context
2538	      string.

2540	   o  Remove support for integrity protection using the Digest header
2541	      field.

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

2545	   o  Forbid RSA keys, and only require clients to support secp256r1
2546	      keys.

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

2550	   draft-03
2551	   o  Allow each method of transferring an exchange to define which
2552	      headers are signed, have the cross-origin methods use all headers,
2553	      and remove the "allResponseHeaders" flag.

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

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

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

2566	   draft-02

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

2571	   o  The validityUrl is signed.

2573	   o  Use CBOR maps where appropriate, and define how they're
2574	      canonicalized.

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

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

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

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

2588	   o  2 new use cases.

2590	Appendix E.  Acknowledgements

2592	   Thanks to Devin Mullins, Ilari Liusvaara, Justin Schuh, Mark
2593	   Nottingham, Mike Bishop, Ryan Sleevi, and Yoav Weiss for comments
2594	   that improved this draft.

2596	Author's Address

2598	   Jeffrey Yasskin
2599	   Google

2601	   Email: jyasskin@chromium.org