idnits 2.17.1 

draft-yasskin-http-origin-signed-responses-02.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 11 instances of too long lines in the document, the longest
     one being 35 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 26, 2018) is 2283 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 1505

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  == Outdated reference: A later version (-28) exists of
     draft-ietf-tls-tls13-23

  == Outdated reference: A later version (-03) exists of
     draft-thomson-http-mice-02

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

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

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

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

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

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

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

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

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

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

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

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


     Summary: 10 errors (**), 0 flaws (~~), 10 warnings (==), 24 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 26, 2018
5	Expires: July 30, 2018

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

10	Abstract

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

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

23	Note to Readers

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

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

32	Status of This Memo

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

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

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

47	   This Internet-Draft will expire on July 30, 2018.

49	Copyright Notice

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

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

64	Table of Contents

66	   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
67	   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
68	   3.  Signing an exchange . . . . . . . . . . . . . . . . . . . . .   5
69	     3.1.  The Signed-Headers Header . . . . . . . . . . . . . . . .   5
70	     3.2.  The Signature Header  . . . . . . . . . . . . . . . . . .   6
71	       3.2.1.  Examples  . . . . . . . . . . . . . . . . . . . . . .   7
72	       3.2.2.  Open Questions  . . . . . . . . . . . . . . . . . . .   8
73	     3.3.  Significant headers of an exchange  . . . . . . . . . . .   9
74	       3.3.1.  Open Questions  . . . . . . . . . . . . . . . . . . .   9
75	     3.4.  CBOR representation of exchange headers . . . . . . . . .   9
76	       3.4.1.  Example . . . . . . . . . . . . . . . . . . . . . . .  10
77	     3.5.  Canonical CBOR serialization  . . . . . . . . . . . . . .  10
78	     3.6.  Signature validity  . . . . . . . . . . . . . . . . . . .  11
79	       3.6.1.  Open Questions  . . . . . . . . . . . . . . . . . . .  15
80	     3.7.  Updating signature validity . . . . . . . . . . . . . . .  15
81	       3.7.1.  Examples  . . . . . . . . . . . . . . . . . . . . . .  16
82	     3.8.  The Accept-Signature header . . . . . . . . . . . . . . .  18
83	       3.8.1.  Integrity labels  . . . . . . . . . . . . . . . . . .  19
84	       3.8.2.  Key type labels . . . . . . . . . . . . . . . . . . .  19
85	       3.8.3.  Key value labels  . . . . . . . . . . . . . . . . . .  19
86	       3.8.4.  Examples  . . . . . . . . . . . . . . . . . . . . . .  20
87	       3.8.5.  Open Questions  . . . . . . . . . . . . . . . . . . .  20
88	   4.  HTTP/2 extension for cross-origin Server Push . . . . . . . .  21
89	     4.1.  Indicating support for cross-origin Server Push . . . . .  21
90	     4.2.  NO_TRUSTED_EXCHANGE_SIGNATURE error code  . . . . . . . .  21
91	       4.2.1.  Open Questions  . . . . . . . . . . . . . . . . . . .  22
92	     4.3.  Validating a cross-origin Push  . . . . . . . . . . . . .  22
93	       4.3.1.  Validating a certificate chain for an authority . . .  22
94	       4.3.2.  Open Questions  . . . . . . . . . . . . . . . . . . .  23
95	   5.  application/http-exchange+cbor format for HTTP/1
96	       compatibility . . . . . . . . . . . . . . . . . . . . . . . .  23

98	     5.1.  Example . . . . . . . . . . . . . . . . . . . . . . . . .  25
99	     5.2.  Open Questions  . . . . . . . . . . . . . . . . . . . . .  25
100	   6.  Security considerations . . . . . . . . . . . . . . . . . . .  25
101	     6.1.  Confidential data . . . . . . . . . . . . . . . . . . . .  25
102	     6.2.  Off-path attackers  . . . . . . . . . . . . . . . . . . .  25
103	     6.3.  Downgrades  . . . . . . . . . . . . . . . . . . . . . . .  26
104	     6.4.  Signing oracles are permanent . . . . . . . . . . . . . .  26
105	     6.5.  Unsigned headers  . . . . . . . . . . . . . . . . . . . .  26
106	     6.6.  application/http-exchange+cbor  . . . . . . . . . . . . .  27
107	   7.  Privacy considerations  . . . . . . . . . . . . . . . . . . .  27
108	   8.  IANA considerations . . . . . . . . . . . . . . . . . . . . .  27
109	     8.1.  Signature Header Field Registration . . . . . . . . . . .  28
110	     8.2.  HTTP/2 Settings . . . . . . . . . . . . . . . . . . . . .  28
111	     8.3.  HTTP/2 Error code . . . . . . . . . . . . . . . . . . . .  28
112	     8.4.  Internet Media Type application/http-exchange+cbor  . . .  28
113	   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  29
114	     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  29
115	     9.2.  Informative References  . . . . . . . . . . . . . . . . .  31
116	     9.3.  URIs  . . . . . . . . . . . . . . . . . . . . . . . . . .  33
117	   Appendix A.  Use cases  . . . . . . . . . . . . . . . . . . . . .  33
118	     A.1.  PUSHed subresources . . . . . . . . . . . . . . . . . . .  33
119	     A.2.  Explicit use of a content distributor for subresources  .  34
120	     A.3.  Subresource Integrity . . . . . . . . . . . . . . . . . .  35
121	     A.4.  Binary Transparency . . . . . . . . . . . . . . . . . . .  35
122	     A.5.  Static Analysis . . . . . . . . . . . . . . . . . . . . .  35
123	     A.6.  Offline websites  . . . . . . . . . . . . . . . . . . . .  36
124	   Appendix B.  Requirements . . . . . . . . . . . . . . . . . . . .  36
125	     B.1.  Proof of origin . . . . . . . . . . . . . . . . . . . . .  36
126	       B.1.1.  Certificate constraints . . . . . . . . . . . . . . .  36
127	       B.1.2.  Signature constraints . . . . . . . . . . . . . . . .  37
128	       B.1.3.  Retrieving the certificate  . . . . . . . . . . . . .  37
129	     B.2.  How much to sign  . . . . . . . . . . . . . . . . . . . .  37
130	       B.2.1.  Conveying the signed headers  . . . . . . . . . . . .  38
131	     B.3.  Response lifespan . . . . . . . . . . . . . . . . . . . .  39
132	       B.3.1.  Certificate revocation  . . . . . . . . . . . . . . .  39
133	       B.3.2.  Response downgrade attacks  . . . . . . . . . . . . .  39
134	   Appendix C.  Determining validity using cache control . . . . . .  40
135	     C.1.  Example of updating cache control . . . . . . . . . . . .  40
136	     C.2.  Downsides of updating cache control . . . . . . . . . . .  41
137	   Appendix D.  Change Log . . . . . . . . . . . . . . . . . . . . .  42
138	   Appendix E.  Acknowledgements . . . . . . . . . . . . . . . . . .  42
139	   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  42

141	1.  Introduction

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

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

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

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

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

169	2.  Terminology

171	   Author  The entity that controls the server for a particular origin
172	      [RFC6454].  The author can get a CA to issue certificates for
173	      their private keys and can run a TLS server for their origin.

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

180	   Intermediate  An entity that fetches signed HTTP exchanges from an
181	      author or another intermediate and forwards them to another
182	      intermediate or a client.

184	   Client  An entity that uses a signed HTTP exchange and needs to be
185	      able to prove that the author vouched for it as coming from its
186	      claimed origin.

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

190	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
191	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
192	   "OPTIONAL" in this document are to be interpreted as described in BCP
193	   14 [RFC2119] [RFC8174] when, and only when, they appear in all
194	   capitals, as shown here.

196	3.  Signing an exchange

198	   As a response to an HTTP request or as a Server Push (Section 8.2 of
199	   [RFC7540]) the server MAY include a "Signed-Headers" header field
200	   (Section 3.1) identifying significant (Section 3.3) header fields and
201	   a "Signature" header field (Section 3.2) holding a list of one or
202	   more parameterised signatures that vouch for the content of the
203	   response.

205	   The client categorizes each signature as "valid" or "invalid" by
206	   validating that signature with its certificate or public key and
207	   other metadata against the significant headers and content
208	   (Section 3.6).  This validity then informs higher-level protocols.

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

217	3.1.  The Signed-Headers Header

219	   The "Signed-Headers" header field identifies an ordered list of
220	   response header fields to include in a signature.  The request URL
221	   and response status are included unconditionally.  This allows a TLS-
222	   terminating intermediate to reorder headers without breaking the
223	   signature.  This _can_ also allow the intermediate to add headers
224	   that will be ignored by some higher-level protocols, but Section 3.6
225	   provides a hook to let other higher-level protocols reject such
226	   insecure headers.

228	   This header field appears once instead of being incorporated into the
229	   signatures' parameters because the significant header fields need to
230	   be consistent across all signatures of an exchange, to avoid forcing
231	   higher-level protocols to merge the header field lists of valid
232	   signatures.

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

237	   "Signed-Headers" is a Structured Header as defined by
238	   [I-D.ietf-httpbis-header-structure].  Its value MUST be a list
239	   (Section 4.8 of [I-D.ietf-httpbis-header-structure]) of lowercase
240	   strings (Section 4.2 of [I-D.ietf-httpbis-header-structure]) naming
241	   HTTP response header fields.  Pseudo-header field names
242	   (Section 8.1.2.1 of [RFC7540]) MUST NOT appear in this list.

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

247	3.2.  The Signature Header

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

255	   The "Signature" header is a Structured Header as defined by
256	   [I-D.ietf-httpbis-header-structure].  Its value MUST be a list
257	   (Section 4.8 of [I-D.ietf-httpbis-header-structure]) of parameterised
258	   labels (Section 4.4 of [I-D.ietf-httpbis-header-structure]).

260	   Each parameterised label MUST have parameters named "sig",
261	   "integrity", "validityUrl", "date", and "expires".  Each
262	   parameterised label MUST also have either "certUrl" and "certSha256"
263	   parameters or an "ed25519Key" parameter.  This specification gives no
264	   meaning to the label itself, which can be used as a human-readable
265	   identifier for the signature (see Section 3.2.2, Paragraph 1).  The
266	   present parameters MUST have the following values:

268	   "sig"  Binary content (Section 4.5 of
269	      [I-D.ietf-httpbis-header-structure]) holding the signature of most
270	      of these parameters and the significant headers of the exchange
271	      (Section 3.3).

273	   "integrity"  A string (Section 4.2 of
274	      [I-D.ietf-httpbis-header-structure]) containing the lowercase name
275	      of the response header field that guards the response payload's
276	      integrity.

278	   "certUrl"  A string (Section 4.2 of
279	      [I-D.ietf-httpbis-header-structure]) containing a valid URL string
280	      [4].

282	   "certSha256"  Binary content (Section 4.5 of
283	      [I-D.ietf-httpbis-header-structure]) holding the SHA-256 hash of
284	      the first certificate found at "certUrl".

286	   "ed25519Key"  Binary content (Section 4.5 of
287	      [I-D.ietf-httpbis-header-structure]) holding an Ed25519 public key
288	      ([RFC8032]).

290	   "validityUrl"  A string (Section 4.2 of
291	      [I-D.ietf-httpbis-header-structure]) containing a valid URL string
292	      [5].

294	   "date" and "expires"  An unsigned integer (Section 4.1 of
295	      [I-D.ietf-httpbis-header-structure]) representing a Unix time.

297	   The "certUrl" parameter is _not_ signed, so intermediates can update
298	   it with a pointer to a cached version.

300	3.2.1.  Examples

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

306	Signature:
307	 sig1;
308	  sig=*MEUCIQDXlI2gN3RNBlgFiuRNFpZXcDIaUpX6HIEwcZEc0cZYLAIga9DsVOMM+g5YpwEBdGW3sS+bvnmAJJiSMwhuBdqp5UY;
309	  integrity="mi";
310	  validityUrl="https://example.com/resource.validity.1511128380";
311	  certUrl="https://example.com/oldcerts";
312	  certSha256=*W7uB969dFW3Mb5ZefPS9Tq5ZbH5iSmOILpjv2qEArmI;
313	  date=1511128380; expires=1511733180,
314	 sig2;
315	  sig=*MEQCIGjZRqTRf9iKNkGFyzRMTFgwf/BrY2ZNIP/dykhUV0aYAiBTXg+8wujoT4n/W+cNgb7pGqQvIUGYZ8u8HZJ5YH26Qg;
316	  integrity="mi";
317	  validityUrl="https://example.com/resource.validity.1511128380";
318	  certUrl="https://example.com/newcerts";
319	  certSha256=*J/lEm9kNRODdCmINbvitpvdYKNQ+YgBj99DlYp4fEXw;
320	  date=1511128380; expires=1511733180,
321	 srisig;
322	  sig=*lGZVaJJM5f2oGczFlLmBdKTDL+QADza4BgeO494ggACYJOvrof6uh5OJCcwKrk7DK+LBch0jssDYPp5CLc1SDA
323	  integrity="mi";
324	  validityUrl="https://example.com/resource.validity.1511128380";
325	  ed25519Key=*zsSevyFsxyZHiUluVBDd4eypdRLTqyWRVOJuuKUz+A8
326	  date=1511128380; expires=1511733180,
327	 thirdpartysig;
328	  sig=*MEYCIQCNxJzn6Rh2fNxsobktir8TkiaJYQFhWTuWI1i4PewQaQIhAMs2TVjc4rTshDtXbgQEOwgj2mRXALhfXPztXgPupii+;
329	  integrity="mi";
330	  validityUrl="https://thirdparty.example.com/resource.validity.1511161860";
331	  certUrl="https://thirdparty.example.com/certs";
332	  certSha256=*UeOwUPkvxlGRTyvHcsMUN0A2oNsZbU8EUvg8A9ZAnNc;
333	  date=1511133060; expires=1511478660,

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

340	   All 4 signatures rely on the "MI" response header to guard the
341	   integrity of the response payload.  This isn't strictly required--
342	   some signatures could use "MI" while others use "Digest"--but there's
343	   not much benefit to mixing them.

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

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

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

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

368	3.2.2.  Open Questions

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

376	   Should the certUrl and validityUrl be lists so that intermediates can
377	   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.3.  Significant headers of an exchange

384	   The significant headers of an exchange are:

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

389	   o  The response status code (Section 6 of [RFC7231]) and the response
390	      header fields whose names are listed in that exchange's "Signed-
391	      Headers" header field (Section 3.1), in the order they appear in
392	      that header field.  If a response header field name from "Signed-
393	      Headers" does not appear in the exchange's response header fields,
394	      the exchange has no significant headers.

396	   If the exchange's "Signed-Headers" header field is not present,
397	   doesn't parse as a Structured Header
398	   ([I-D.ietf-httpbis-header-structure]) or doesn't follow the
399	   constraints on its value described in Section 3.1, the exchange has
400	   no significant headers.

402	3.3.1.  Open Questions

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

407	3.4.  CBOR representation of exchange headers

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

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

419	   1.  The map mapping:

421	       *  The byte string ':method' to the byte string containing
422	          "exchange"'s request's method.

424	       *  The byte string ':url' to the byte string containing
425	          "exchange"'s request's effective request URI.

427	   2.  The map mapping:

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

432	       *  for each response header field in "exchange", the header
433	          field's name as a byte string to the header field's value as a
434	          byte string.

436	3.4.1.  Example

438	   Given the HTTP exchange:

440	GET https://example.com/ HTTP/1.1
441	Accept: */*

443	HTTP/1.1 200
444	Content-Type: text/html
445	Digest: SHA-256=20addcf7368837f616d549f035bf6784ea6d4bf4817a3736cd2fc7a763897fe3
446	Signed-Headers: "content-type", "digest"

448	<!doctype html>
449	<html>
450	...

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

456	[
457	  {
458	    ':url': 'https://example.com/'
459	    ':method': 'GET',
460	  },
461	  {
462	    'digest': 'SHA-256=20addcf7368837f616d549f035bf6784ea6d4bf4817a3736cd2fc7a763897fe3',
463	    ':status': '200',
464	    'content-type': 'text/html'
465	  }
466	]

468	3.5.  Canonical CBOR serialization

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

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

477	   o  Items MUST NOT be encoded with indefinite length.

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

483	      1.  10, encoded as 0A.

485	      2.  100, encoded as 18 64.

487	      3.  -1, encoded as 20.

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

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

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

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

497	      8.  false, encoded as F4.

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

503	3.6.  Signature validity

505	   The client MUST parse the "Signature" header field as the list of
506	   parameterised values (Section 4.8.1 of
507	   [I-D.ietf-httpbis-header-structure]) described in Section 3.2.  If an
508	   error is thrown during this parsing or any of the requirements
509	   described there aren't satisfied, the exchange has no valid
510	   signatures.  Otherwise, each member of this list represents a
511	   signature with parameters.

513	   The client MUST use the following algorithm to determine whether each
514	   signature with parameters is invalid or potentially-valid.
515	   Potentially-valid results include:

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

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

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

529	   This algorithm also accepts an "allResponseHeaders" flag, which
530	   insists that there are no non-significant response header fields in
531	   the exchange.

533	   1.   Let "originalExchange" be the signature's exchange.

535	   2.   Let "headers" be the significant headers (Section 3.3) of
536	        "originalExchange".  If "originalExchange" has no significant
537	        headers, then return "invalid".

539	   3.   Let "payload" be the payload body (Section 3.3 of [RFC7230]) of
540	        "originalExchange".  Note that the payload body is the message
541	        body with any transfer encodings removed.

543	   4.   If "allResponseHeaders" is set and the response header fields in
544	        "originalExchange" are not equal to the response header fields
545	        in "headers", then return "invalid".

547	   5.   Let:

549	        *  "signature" be the signature (binary content in the
550	           parameterised label's "sig" parameter).

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

554	        *  "validityUrl" be the signature's "validityUrl" parameter.

556	        *  "certUrl" be the signature's "certUrl" parameter, if any.

558	        *  "certSha256" be the signature's "certSha256" parameter, if
559	           any.

561	        *  "ed25519Key" be the signature's "ed25519Key" parameter, if
562	           any.

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

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

570	   6.   If "integrity" names a header field that is not present in
571	        "headers" or which the client cannot use to check the integrity
572	        of "payload" (for example, the header field is new and hasn't
573	        been implemented yet), then return "invalid".  Clients MUST
574	        implement at least the "Digest" ([RFC3230]) and "MI"
575	        ([I-D.thomson-http-mice]) header fields.

577	   7.   If "integrity" is "digest", and the "Digest" header field in
578	        "headers" contains no digest-algorithms
579	        (https://www.iana.org/assignments/http-dig-alg/http-dig-
580	        alg.xhtml [6]) stronger than "SHA", then return "invalid".

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

585	        1.  If "certUrl" is present:

587	            1.  Let "certificate-chain" be the result of fetching
588	                ([FETCH]) "certUrl" and parsing it as a TLS 1.3
589	                Certificate message (Section 4.4.2 of
590	                [I-D.ietf-tls-tls13]) containing X.509v3 certificates.
591	                If "forceFetch" is _not_ set, the fetch can be fulfilled
592	                from a cache using normal HTTP semantics [RFC7234].  If
593	                this fetch or parse fails, return "invalid".

595	                Parsing notes: 1.  This does not include the 4-byte
596	                header that would appear in a Handshake message.  1.
597	                Since this fetch is not in response to a
598	                CertificateRequest, the certificate_request_context MUST
599	                be empty, and a non-empty value MUST cause the parse to
600	                fail.

602	            2.  Let "main-certificate" be the first certificate in
603	                "certificate-chain".

605	            3.  If the SHA-256 hash of "main-certificate"'s "cert_data"
606	                is not equal to "certSha256", return "invalid".  Note
607	                that this intentionally differs from TLS 1.3, which
608	                signs the entire certificate chain in its Certificate
609	                Verify (Section 4.4.3 of [I-D.ietf-tls-tls13]), in order
610	                to allow updating the stapled OCSP response without
611	                updating signatures at the same time.

613	            4.  Set "publicKey" to "main-certificate"'s public key

615	            5.  The client MUST define a partial function from public
616	                key types to signing algorithms, and this function must
617	                at the minimum include the following mappings:

619	                RSA, 2048 bits:  rsa_pss_sha256 as defined in
620	                   Section 4.2.3 of [I-D.ietf-tls-tls13].

622	                EC, with the secp256r1 curve:  ecdsa_secp256r1_sha256 as
623	                   defined in Section 4.2.3 of [I-D.ietf-tls-tls13].

625	                EC, with the secp384r1 curve:  ecdsa_secp384r1_sha384 as
626	                   defined in Section 4.2.3 of [I-D.ietf-tls-tls13].

628	                Set "signing-alg" to the result of applying this
629	                function to type of "main-certificate"'s public key.  If
630	                the function is undefined on this input, return
631	                "invalid".

633	        2.  If "ed25519Key" is present, set "publicKey" to "ed25519Key"
634	            and "signing-alg" to ed25519, as defined by [RFC8032]

636	   9.   If "expires" is more than 7 days (604800 seconds) after "date",
637	        return "invalid".

639	   10.  If the current time is before "date" or after "expires", return
640	        "invalid".

642	   11.  Let "message" be the concatenation of the following byte
643	        strings.  This matches the [I-D.ietf-tls-tls13] format to avoid
644	        cross-protocol attacks when TLS certificates are used to sign
645	        manifests.

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

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

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

653	        4.  The bytes of the canonical CBOR serialization (Section 3.5)
654	            of a CBOR map mapping:

656	            1.  If "certSha256" is set:

658	                1.  The text string "certSha256" to the byte string
659	                    value of "certSha256".

661	            2.  The text string "validityUrl" to the byte string value
662	                of "validityUrl".

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

666	            4.  The text string "expires" to the integer value of
667	                "expires".

669	            5.  The text string "headers" to the CBOR representation
670	                (Section 3.4) of "exchange"'s headers.

672	   12.  If "signature" is "message"'s signature by "main-certificate"'s
673	        public key using "signing-alg", return "potentially-valid" with
674	        "exchange" and whichever is present of "certificate-chain" or
675	        "ed25519Key".  Otherwise, return "invalid".

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

691	3.6.1.  Open Questions

693	   Should we ban RSA keys to avoid their vulnerability to Bleichenbacher
694	   attacks?

696	3.7.  Updating signature validity

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

702	   This specification provides no way to update OCSP responses by
703	   themselves.  Instead, clients need to re-fetch the "certUrl"
704	   (Section 3.6, Paragraph 4) to get a chain including a newer OCSP
705	   response.

707	   The "validityUrl" parameter (Paragraph 6) of the signatures provides
708	   a way to fetch new signatures or learn where to fetch a complete
709	   updated exchange.

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

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

718	   validity = {
719	     ? signatures: [ + bytes ]
720	     ? update: {
721	       ? size: uint,
722	     }
723	   ]

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

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

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

743	3.7.1.  Examples

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

749	Signature:
750	 sig1;
751	  sig=*MEUCIQ...;
752	  ...
753	  validityUrl="https://example.com/resource.validity.1511157180";
754	  certUrl="https://example.com/oldcerts";
755	  date=1511128380; expires=1511733180,
756	 sig2;
757	  sig=*MEQCIG...;
758	  ...
759	  validityUrl="https://example.com/resource.validity.1511157180";
760	  certUrl="https://example.com/newcerts";
761	  date=1511128380; expires=1511733180,
762	 thirdpartysig;
763	  sig=*MEYCIQ...;
764	  ...
765	  validityUrl="https://thirdparty.example.com/resource.validity.1511161860";
766	  certUrl="https://thirdparty.example.com/certs";
767	  date=1511478660; expires=1511824260

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

775	{
776	  "signatures": [
777	    'sig1; '
778	    'sig=*MEQCIC/I9Q+7BZFP6cSDsWx43pBAL0ujTbON/+7RwKVk+ba5AiB3FSFLZqpzmDJ0NumNwN04pqgJZE99fcK86UjkPbj4jw; '
779	    'validityUrl="https://example.com/resource.validity.1511157180"; '
780	    'integrity="mi"; '
781	    'certUrl="https://example.com/newcerts"; '
782	    'certSha256=*J/lEm9kNRODdCmINbvitpvdYKNQ+YgBj99DlYp4fEXw; '
783	    'date=1511733180; expires=1512337980'
784	  ],
785	  "update": {
786	    "size": 5557452
787	  }
788	}

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

799	Signature:
800	 sig1;
801	  sig=*MEQCIC...;
802	  ...
803	  validityUrl="https://example.com/resource.validity.1511157180";
804	  certUrl="https://example.com/newcerts";
805	  date=1511733180; expires=1512337980,
806	 thirdpartysig;
807	  sig=*MEYCIQ...;
808	  ...
809	  validityUrl="https://thirdparty.example.com/resource.validity.1511161860";
810	  certUrl="https://thirdparty.example.com/certs";
811	  date=1511478660; expires=1511824260

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

817	3.8.  The Accept-Signature header

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

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

833	   The "Accept-Signature" header field is a Structured Header as defined
834	   by [I-D.ietf-httpbis-header-structure].  Its value MUST be a list
835	   (Section 4.8 of [I-D.ietf-httpbis-header-structure]) of parameterised
836	   labels (Section 4.4 of [I-D.ietf-httpbis-header-structure]).  The
837	   order of labels in the "Accept-Signature" list is not significant.
838	   Labels, ignoring any initial "-" character, MUST NOT be duplicated.

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

848	3.8.1.  Integrity labels

850	   Labels starting with "digest/" indicate that the client supports the
851	   "Digest" header field ([RFC3230]) with the digest-algorithm from the
852	   https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml [7]
853	   registry named in lower-case by the rest of the label.  For example,
854	   "digest/sha-512" indicates support for the SHA-512 digest algorithm,
855	   and "-digest/sha-256" indicates non-support for the SHA-256 digest
856	   algorithm.

858	   Labels starting with "mi/" indicate that the client supports the "MI"
859	   header field ([I-D.thomson-http-mice]) with the parameter from the
860	   HTTP MI Parameter Registry registry named in lower-case by the rest
861	   of the label.  For example, "mi/mi-blake2" indicates support for
862	   Merkle integrity with the as-yet-unspecified mi-blake2 parameter, and
863	   "-digest/mi-sha256" indicates non-support for Merkle integrity with
864	   the mi-sha256 content encoding.

866	   If the "Accept-Signature" header field is present, servers SHOULD
867	   assume support for "digest/sha-256" and "mi/mi-sha256" unless the
868	   header field states otherwise.

870	3.8.2.  Key type labels

872	   Labels starting with "rsa/" indicate that the client supports
873	   certificates holding RSA public keys with a number of bits indicated
874	   by the digits after the "/".

876	   Labels starting with "ecdsa/" indicate that the client supports
877	   certificates holding ECDSA public keys on the curve named in lower-
878	   case by the rest of the label.

880	   If the "Accept-Signature" header field is present, servers SHOULD
881	   assume support for "rsa/2048", "ecdsa/secp256r1", and "ecdsa/
882	   secp384r1" unless the header field states otherwise.

884	3.8.3.  Key value labels

886	   The "ed25519key" label has parameters indicating the public keys that
887	   will be used to validate the returned signature.  Each parameter's
888	   name is re-interpreted as binary content (Section 4.5 of
889	   [I-D.ietf-httpbis-header-structure]) encoding a prefix of the public
890	   key.  For example, if the client will validate signatures using the
891	   public key whose base64 encoding is
892	   "11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo", valid "Accept-
893	   Signature" header fields include:

895	Accept-Signature: ..., ed25519key; *11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo
896	Accept-Signature: ..., ed25519key; *11qYAYKxCrfVS/7TyWQHOg
897	Accept-Signature: ..., ed25519key; *11qYAQ
898	Accept-Signature: ..., ed25519key; *

900	   but not

902	   Accept-Signature: ..., ed25519key; *11qYA

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

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

908	   because it doesn't start with the "*" that indicates binary content.

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

916	3.8.4.  Examples

918	   Accept-Signature: mi/mi-sha256

920	   states that the client will accept signatures with payload integrity
921	   assured by the "MI" header and "mi-sha256" content encoding and
922	   implies that the client will accept integrity assured by the "Digest:
923	   SHA-256" header and signatures from 2048-bit RSA keys and ECDSA keys
924	   on the secp256r1 and secp384r1 curves.

926	   Accept-Signature: -rsa/2048, rsa/4096

928	   states that the client will accept 4096-bit RSA keys but not 2048-bit
929	   RSA keys, and implies that the client will accept ECDSA keys on the
930	   secp256r1 and secp384r1 curves and payload integrity assured with the
931	   "MI: mi-sha256" and "Digest: SHA-256" header fields.

933	3.8.5.  Open Questions

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

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

944	   Do I have the right structure for the labels indicating feature
945	   support?

947	4.  HTTP/2 extension for cross-origin Server Push

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

954	4.1.  Indicating support for cross-origin Server Push

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

960	   An ENABLE_CROSS_ORIGIN_PUSH value of 0 indicates that the client does
961	   not support cross-origin Push.  A value of 1 indicates that the
962	   client does support cross-origin Push.

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

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

976	4.2.  NO_TRUSTED_EXCHANGE_SIGNATURE error code

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

985	4.2.1.  Open Questions

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

989	4.3.  Validating a cross-origin Push

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

997	   Instead, the client MUST validate such a PUSH_PROMISE and its
998	   response by parsing the "Signature" header into a list of signatures
999	   according to the instructions in Section 3.6, and searching that list
1000	   for a valid signature using the algorithm in Section 4.3.1.  If no
1001	   valid signature is found, the client MUST treat the response as a
1002	   stream error (Section 5.4.2 of [RFC7540]) of type
1003	   NO_TRUSTED_EXCHANGE_SIGNATURE.  Otherwise, the client MUST treat the
1004	   pushed response as if the server were authoritative for the
1005	   PUSH_PROMISE's authority.

1007	4.3.1.  Validating a certificate chain for an authority

1009	   1.  If the signature's "validityUrl" parameter (Paragraph 6) is not
1010	       same-origin [8] with the exchange's effective request URI
1011	       (Section 5.5 of [RFC7230]), return "invalid".

1013	   2.  Run Section 3.6 over the signature with the "allResponseHeaders"
1014	       flag set, getting "exchange" and "certificate-chain" back.  If
1015	       this returned "invalid" or didn't return a certificate chain,
1016	       return "invalid".

1018	   3.  Let "authority" be the host component of "exchange"'s effective
1019	       request URI.

1021	   4.  Validate the "certificate-chain" using the following substeps.
1022	       If any of them fail, re-run Section 3.6 once over the signature
1023	       with both the "forceFetch" flag and the "allResponseHeaders" flag
1024	       set, and restart from step 2.  If a substep fails again, return
1025	       "invalid".

1027	       1.  Use "certificate-chain" to validate that its first entry,
1028	           "main-certificate" is trusted as "authority"'s server
1029	           certificate ([RFC5280] and other undocumented conventions).
1030	           Let "path" be the path that was used from the "main-
1031	           certificate" to a trusted root, including the "main-
1032	           certificate" but excluding the root.

1034	       2.  Validate that "main-certificate" includes a "status_request"
1035	           extension with a valid OCSP response whose lifetime
1036	           ("nextUpdate - thisUpdate") is less than 7 days ([RFC6960]).
1037	           Note that this does not check for revocation of intermediate
1038	           certificates, and clients SHOULD implement another mechanism
1039	           for that.

1041	       3.  Validate that all certificates in "path" include
1042	           "signed_certificate_timestamp" extensions containing valid
1043	           SCTs from trusted logs.  ([RFC6962])

1045	   5.  Return "valid".

1047	4.3.2.  Open Questions

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

1054	5.  application/http-exchange+cbor format for HTTP/1 compatibility

1056	   To allow servers to serve cross-origin responses when either the
1057	   client or the server hasn't implemented HTTP/2 Push (Section 8.2 of
1058	   [RFC7540]) support yet, we define a format that represents an HTTP
1059	   exchange.

1061	   The "application/http-exchange+cbor" content type encodes an HTTP
1062	   exchange, including request metadata and header fields, optionally a
1063	   request body, response header fields and metadata, a payload body,
1064	   and optionally trailer header fields.

1066	   This content type consists of a canonically-serialized (Section 3.5)
1067	   CBOR array containing:

1069	   1.  The text string "htxg" to serve as a file signature, followed by

1071	   2.  Alternating member names encoded as text strings (Section 2.1 of
1072	       [RFC7049]) and member values, with each value consisting of a
1073	       single CBOR item with a type and meaning determined by the member
1074	       name.

1076	   This specification defines the following member names with their
1077	   associated values:

1079	   "request"  A map from request header field names to values, encoded
1080	      as byte strings ([RFC7049], section 2.1).  The request header
1081	      fields MUST include two pseudo-header fields (Section 8.1.2.1 of
1082	      [RFC7540]):

1084	      *  "':method'": The method of the request (Section 4 of
1085	         [RFC7231]).

1087	      *  "':url'": The effective request URI of the request (Section 5.5
1088	         of [RFC7230]).

1090	   "request payload"  A byte string ([RFC7049], section 2.1) containing
1091	      the request payload body (Section 3.3 of [RFC7230]).

1093	   "response"  A map from response header field names to values, encoded
1094	      as byte strings ([RFC7049], section 2.1).  The response header
1095	      fields MUST include one pseudo-header field (Section 8.1.2.1 of
1096	      [RFC7540]):

1098	      *  "':status'": The response's 3-digit status code (Section 6 of
1099	         [RFC7231]]).

1101	   "payload"  A byte string ([RFC7049], section 2.1) containing the
1102	      response payload body (Section 3.3 of [RFC7230]).

1104	   "trailer"  A map of trailer header field names to values, encoded as
1105	      byte strings (Section 2.1 of [RFC7049]).

1107	   A parser MAY return incremental information while parsing
1108	   "application/http-exchange+cbor" content.

1110	   Members "request", "response", and "payload" MUST be present.  If one
1111	   is missing, the parser MUST stop and report an error.

1113	   The member names MUST appear in the order:

1115	   1.  "request"

1117	   2.  "request payload"

1119	   3.  "response"

1121	   4.  "payload"

1123	   5.  "trailer"

1125	   If a member name is not a text string, appears out of order, or is
1126	   followed by a value not matching its description above, the parser
1127	   MUST stop and report an error.

1129	   If the parser encounters an unknown member name, it MUST skip the
1130	   following item and resume parsing at the next member name.

1132	5.1.  Example

1134	   An example "application/http-exchange+cbor" file representing a
1135	   possible exchange with https://example.com/ [9] follows, in the
1136	   extended diagnostic format defined in Appendix G of
1137	   [I-D.ietf-cbor-cddl]:

1139	   [
1140	     "htxg",
1141	     "request",
1142	     {
1143	       ':method': 'GET',
1144	       ':url': 'https://example.com/',
1145	       'accept', '*/*'
1146	     },
1147	     "response",
1148	     {
1149	       ':status': '200',
1150	       'content-type': 'text/html'
1151	     },
1152	     "payload",
1153	     '<!doctype html>\r\n<html>...'
1154	   ]

1156	5.2.  Open Questions

1158	   Should "application/http-exchange+cbor" support request payloads and
1159	   trailers, or only the aspects needed for signed exchanges?

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

1163	6.  Security considerations

1165	6.1.  Confidential data

1167	   Authors MUST NOT include confidential information in a signed
1168	   response that an untrusted intermediate could forward, since the
1169	   response is only signed and not encrypted.  Intermediates can read
1170	   the content.

1172	6.2.  Off-path attackers

1174	   Relaxing the requirement to consult DNS when determining authority
1175	   for an origin means that an attacker who possesses a valid
1176	   certificate no longer needs to be on-path to redirect traffic to
1177	   them; instead of modifying DNS, they need only convince the user to
1178	   visit another Web site in order to serve responses signed as the
1179	   target.  This consideration and mitigations for it are shared by the
1180	   combination of [I-D.ietf-httpbis-origin-frame] and
1181	   [I-D.ietf-httpbis-http2-secondary-certs].

1183	6.3.  Downgrades

1185	   Signing a bad response can affect more users than simply serving a
1186	   bad response, since a served response will only affect users who make
1187	   a request while the bad version is live, while an attacker can
1188	   forward a signed response until its signature expires.  Authors
1189	   should consider shorter signature expiration times than they use for
1190	   cache expiration times.

1192	   Clients MAY also check the "validityUrl" (Paragraph 6) of an exchange
1193	   more often than the signature's expiration would require.  Doing so
1194	   for an exchange with an HTTPS request URI provides a TLS guarantee
1195	   that the exchange isn't out of date (as long as Section 4.3.2 is
1196	   resolved to keep the same-origin requirement).

1198	6.4.  Signing oracles are permanent

1200	   An attacker with temporary access to a signing oracle can sign "still
1201	   valid" assertions with arbitrary timestamps and expiration times.  As
1202	   a result, when a signing oracle is removed, the keys it provided
1203	   access to SHOULD be revoked so that, even if the attacker used them
1204	   to sign future-dated exchange validity assertions, the key's OCSP
1205	   assertion will expire, causing the exchange as a whole to become
1206	   untrusted.

1208	6.5.  Unsigned headers

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

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

1221	   Section 3.6 can succeed when some delivered headers aren't included
1222	   in the signed set.  This accommodates current TLS-terminating
1223	   intermediates and may be useful for SRI (Appendix A.3), but is risky
1224	   for trusting cross-origin responses (Appendix A.1, Appendix A.2, and
1225	   Appendix A.6).  Section 4 requires all headers to be included in the
1226	   signature before trusting cross-origin pushed resources, at Ryan
1227	   Sleevi's recommendation.

1229	6.6.  application/http-exchange+cbor

1231	   Clients MUST NOT trust an effective request URI claimed by an
1232	   "application/http-exchange+cbor" resource (Section 5) without either
1233	   ensuring the resource was transferred from a server that was
1234	   authoritative (Section 9.1 of [RFC7230]) for that URI's origin, or
1235	   validating the resource's signature using a procedure like the one
1236	   described in Section 4.3.1.

1238	7.  Privacy considerations

1240	   Normally, when a client fetches "https://o1.com/resource.js",
1241	   "o1.com" learns that the client is interested in the resource.  If
1242	   "o1.com" signs "resource.js", "o2.com" serves it as "https://o2.com/
1243	   o1resource.js", and the client fetches it from there, then "o2.com"
1244	   learns that the client is interested, and if the client executes the
1245	   Javascript, that could also report the client's interest back to
1246	   "o1.com".

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

1252	   For non-executable resource types, a signed response can improve the
1253	   privacy situation by hiding the client's interest from the original
1254	   author.

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

1265	8.  IANA considerations

1267	   TODO: possibly register the validityUrl format.

1269	8.1.  Signature Header Field Registration

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

1274	   Header field name: "Signature"

1276	   Applicable protocol: http

1278	   Status: standard

1280	   Author/Change controller: IETF

1282	   Specification document(s): Section 3.2 of this document

1284	8.2.  HTTP/2 Settings

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

1289	   Name: ENABLE_CROSS_ORIGIN_PUSH

1291	   Code: 0xSETTING-TBD

1293	   Initial Value: 0

1295	   Specification: This document

1297	8.3.  HTTP/2 Error code

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

1302	   Name: NO_TRUSTED_EXCHANGE_SIGNATURE

1304	   Code: 0xERROR-TBD

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

1309	   Specification: This document

1311	8.4.  Internet Media Type application/http-exchange+cbor

1313	   Type name: application

1315	   Subtype name: http-exchange+cbor
1316	   Required parameters: N/A

1318	   Optional parameters: N/A

1320	   Encoding considerations: binary

1322	   Security considerations: see Section 6.6

1324	   Interoperability considerations: N/A

1326	   Published specification: This specification (see Section 5).

1328	   Applications that use this media type: N/A

1330	   Fragment identifier considerations: N/A

1332	   Additional information:

1334	   Deprecated alias names for this type: N/A

1336	   Magic number(s): 8? 64 68 74 78 67

1338	   File extension(s): .htxg

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

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

1345	   Intended usage: COMMON

1347	   Restrictions on usage: N/A

1349	   Author: See Authors' Addresses section.

1351	   Change controller: IESG

1353	9.  References

1355	9.1.  Normative References

1357	   [FETCH]    WHATWG, "Fetch", January 2018,
1358	              <https://fetch.spec.whatwg.org/>.

1360	   [HTML]     WHATWG, "HTML", January 2018,
1361	              <https://html.spec.whatwg.org/multipage>.

1363	   [I-D.ietf-cbor-cddl]
1364	              Birkholz, H., Vigano, C., and C. Bormann, "Concise data
1365	              definition language (CDDL): a notational convention to
1366	              express CBOR data structures", draft-ietf-cbor-cddl-00
1367	              (work in progress), July 2017.

1369	   [I-D.ietf-httpbis-header-structure]
1370	              Nottingham, M. and P. Kamp, "Structured Headers for HTTP",
1371	              draft-ietf-httpbis-header-structure-02 (work in progress),
1372	              November 2017.

1374	   [I-D.ietf-tls-tls13]
1375	              Rescorla, E., "The Transport Layer Security (TLS) Protocol
1376	              Version 1.3", draft-ietf-tls-tls13-23 (work in progress),
1377	              January 2018.

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

1383	   [POSIX]    IEEE and The Open Group, "The Open Group Base
1384	              Specifications Issue 7", name IEEE, value 1003.1-2008,
1385	              2016 Edition, 2016,
1386	              <http://pubs.opengroup.org/onlinepubs/9699919799/
1387	              basedefs/>.

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

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

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

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

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

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

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

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

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

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

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

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

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

1452	9.2.  Informative References

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

1458	   [I-D.cavage-http-signatures]
1459	              Cavage, M. and M. Sporny, "Signing HTTP Messages", draft-
1460	              cavage-http-signatures-09 (work in progress), November
1461	              2017.

1463	   [I-D.ietf-httpbis-http2-secondary-certs]
1464	              Bishop, M., Sullivan, N., and M. Thomson, "Secondary
1465	              Certificate Authentication in HTTP/2", draft-ietf-httpbis-
1466	              http2-secondary-certs-00 (work in progress), December
1467	              2017.

1469	   [I-D.ietf-httpbis-origin-frame]
1470	              Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame",
1471	              draft-ietf-httpbis-origin-frame-06 (work in progress),
1472	              January 2018.

1474	   [I-D.thomson-http-content-signature]
1475	              Thomson, M., "Content-Signature Header Field for HTTP",
1476	              draft-thomson-http-content-signature-00 (work in
1477	              progress), July 2015.

1479	   [I-D.yasskin-webpackage-use-cases]
1480	              Yasskin, J., "Use Cases and Requirements for Web
1481	              Packages", draft-yasskin-webpackage-use-cases-00 (work in
1482	              progress), August 2017.

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

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

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

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

1503	9.3.  URIs

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

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

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

1512	   [4] https://url.spec.whatwg.org/#valid-url-string

1514	   [5] https://url.spec.whatwg.org/#valid-url-string

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

1518	   [7] https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml

1520	   [8] https://html.spec.whatwg.org/multipage/origin.html#same-origin

1522	   [9] https://example.com/

1524	   [10] https://calendar.perfplanet.com/2013/big-bad-preloader/

1526	   [11] https://github.com/mikewest/signature-based-sri

1528	   [12] https://github.com/mikewest/signature-based-sri/issues/5

1530	   [13] https://www.apple.com/ios/app-store/

1532	   [14] https://play.google.com/store

1534	   [15] https://github.com/WICG/webpackage

1536	   [16] https://tools.ietf.org/html/rfc7540#section-8.2

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

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

1543	Appendix A.  Use cases

1545	A.1.  PUSHed subresources

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

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

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

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

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

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

1572	   <img logicalsrc="https://O.com/img.png"
1573	        physicalsrc="https://distributor.com/O.com/img.png">

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

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

1581	   where the "<dist-img>" implementation generates an appropriate
1582	   "<img>" based on, for example, a "<meta name="dist-base">" tag
1583	   elsewhere in the page.  However, this has the downside that the
1584	   preloader [10] can no longer see the physical source to download it.
1585	   The resulting delay might cancel out the benefit of using a
1586	   distributor.

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

1591	   To implement this with the current proposal, the distributor would
1592	   respond to the physical request to "https://distributor.com/O.com/
1593	   img.png" with first a signed PUSH_PROMISE for "https://O.com/img.png"
1594	   and then a redirect to "https://O.com/img.png".

1596	A.3.  Subresource Integrity

1598	   The W3C WebAppSec group is investigating using signatures [11] in
1599	   [SRI].  They need a way to transmit the signature with the response,
1600	   which this proposal provides.

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

1607	   The "ed25519Key" signature parameter supports this simpler way of
1608	   attaching a key.

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

1617	A.4.  Binary Transparency

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

1626	   Certificate Transparency depends on Signed Certificate Timestamps
1627	   that prove a log contained a particular certificate at a particular
1628	   time.  To build the same thing for Binary Transparency logs
1629	   containing HTTP resources or full websites, we'll need a way to
1630	   provide signatures of those resources, which signed exchanges
1631	   provides.

1633	A.5.  Static Analysis

1635	   Native app stores like the Apple App Store [13] and the Android Play
1636	   Store [14] grant their contents powerful abilities, which they
1637	   attempt to make safe by analyzing the applications before offering
1638	   them to people.  The web has no equivalent way for people to wait to
1639	   run an update of a web application until a trusted authority has
1640	   vouched for it.

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

1647	A.6.  Offline websites

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

1654	Appendix B.  Requirements

1656	B.1.  Proof of origin

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

1664	B.1.1.  Certificate constraints

1666	   If we re-use existing TLS server certificates, we incur the risks
1667	   that:

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

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

1678	   If these risks are too high, we could define a new Extended Key Usage
1679	   (Section 4.2.1.12 of [RFC5280]) that requires CAs to issue new keys
1680	   for this purpose or a new certificate extension to do the same.  A
1681	   new EKU would probably require CAs to also issue new intermediate
1682	   certificates because of how browsers trust EKUs.  Both an EKU and a
1683	   new extension take a long time to deploy and allow CAs to charge
1684	   exchange-signers more than normal server operators, which will reduce
1685	   adoption.

1687	   The rest of this document assumes we can re-use existing TLS server
1688	   certificates.

1690	B.1.2.  Signature constraints

1692	   In order to prevent an attacker who can convince the server to sign
1693	   some resource from causing those signed bytes to be interpreted as
1694	   something else, signatures here need to:

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

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

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

1708	B.1.3.  Retrieving the certificate

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

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

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

1733	B.2.  How much to sign

1735	   The previous [I-D.thomson-http-content-signature] and
1736	   [I-D.burke-content-signature] schemes signed just the content, while
1737	   ([I-D.cavage-http-signatures] could also sign the response headers
1738	   and the request method and path.  However, the same path, response
1739	   headers, and content may mean something very different when retrieved
1740	   from a different server.  Section 3.3 currently includes the whole
1741	   request URL in the signature, but it's possible we need a more
1742	   flexible scheme to allow some higher-level protocols to accept a
1743	   less-signed URL.

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

1752	   In order to allow multiple clients to consume the same signed
1753	   exchange, the exchange shouldn't include the exact request headers
1754	   that any particular client sends.  For example, a Japanese resource
1755	   wouldn't include

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

1759	   Instead, it would probably include just

1761	   accept-language: ja-JP, ja

1763	   and clients would use the same matching logic as for PUSH_PROMISE
1764	   [16] frame headers.

1766	B.2.1.  Conveying the signed headers

1768	   HTTP headers are traditionally munged by proxies, making it
1769	   impossible to guarantee that the client will see the same sequence of
1770	   bytes as the author wrote.  In the HTTPS world, we have more end-to-
1771	   end header integrity, but it's still likely that there are enough
1772	   TLS-terminating proxies that the author's signatures would tend to
1773	   break before getting to the client.

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

1781	   Since proxies are unlikely to modify unknown content types, we can
1782	   wrap the original exchange into an "application/http-exchange+cbor"
1783	   format (Section 5) and include the "Cache-Control: no-transform"
1784	   header when sending it.

1786	   To reduce the likelihood of accidental modification by proxies, the
1787	   "application/http-exchange+cbor" format includes a file signature
1788	   that doesn't collide with other known signatures.

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

1795	B.3.  Response lifespan

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

1804	B.3.1.  Certificate revocation

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

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

1818	B.3.2.  Response downgrade attacks

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

1828	   These assertions could be structured as:

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

1835	   2.  A replacement for the whole exchange's signature.  This requires
1836	       the author to separately re-sign each valid version and requires
1837	       each version to include a different update URL, but allows
1838	       intermediates to serve less data.  This is the approach taken in
1839	       Section 3.

1841	   3.  A replacement for the exchange's signature and an update for the
1842	       embedded "expires" and related cache-control HTTP headers
1843	       [RFC7234].  This naturally extends authors' intuitions about
1844	       cache expiration and the existing cache revalidation behavior to
1845	       signed exchanges.  This is sketched and its downsides explored in
1846	       Appendix C.

1848	   The signature also needs to include instructions to intermediates for
1849	   how to fetch updated validity assertions.

1851	Appendix C.  Determining validity using cache control

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

1858	   The signatures in the "Signature" header field (Section 3.2) would no
1859	   longer contain "date" or "expires" fields.

1861	   The validity-checking algorithm (Section 3.6) would initialize "date"
1862	   from the resource's "Date" header field (Section 7.1.1.2 of
1863	   [RFC7231]) and initialize "expires" from either the "Expires" header
1864	   field (Section 5.3 of [RFC7234]) or the "Cache-Control" header
1865	   field's "max-age" directive (Section 5.2.2.8 of [RFC7234]) (added to
1866	   "date"), whichever is present, preferring "max-age" (or failing) if
1867	   both are present.

1869	   Validity updates (Section 3.7) would include a list of replacement
1870	   response header fields.  For each header field name in this list, the
1871	   client would remove matching header fields from the stored exchange's
1872	   response header fields.  Then the client would append the replacement
1873	   header fields to the stored exchange's response header fields.

1875	C.1.  Example of updating cache control

1877	   For example, given a stored exchange of:

1879	   GET https://example.com/ HTTP/1.1
1880	   Accept: */*

1882	   HTTP/1.1 200
1883	   Date: Mon, 20 Nov 2017 10:00:00 UTC
1884	   Content-Type: text/html
1885	   Date: Tue, 21 Nov 2017 10:00:00 UTC
1886	   Expires: Sun, 26 Nov 2017 10:00:00 UTC

1888	   <!doctype html>
1889	   <html>
1890	   ...

1892	   And an update listing the following headers:

1894	   Expires: Fri, 1 Dec 2017 10:00:00 UTC
1895	   Date: Sat, 25 Nov 2017 10:00:00 UTC

1897	   The resulting stored exchange would be:

1899	   GET https://example.com/ HTTP/1.1
1900	   Accept: */*

1902	   HTTP/1.1 200
1903	   Content-Type: text/html
1904	   Expires: Fri, 1 Dec 2017 10:00:00 UTC
1905	   Date: Sat, 25 Nov 2017 10:00:00 UTC

1907	   <!doctype html>
1908	   <html>
1909	   ...

1911	C.2.  Downsides of updating cache control

1913	   In an exchange with multiple signatures, using cache control to
1914	   expire signatures forces all signatures to initially live for the
1915	   same period.  Worse, the update from one signature's "validityUrl"
1916	   might not match the update for another signature.  Clients would need
1917	   to maintain a current set of headers for each signature, and then
1918	   decide which set to use when actually parsing the resource itself.

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

1924	Appendix D.  Change Log

1926	   RFC EDITOR PLEASE DELETE THIS SECTION.

1928	   draft-02

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

1933	   o  The validityUrl is signed.

1935	   o  Use CBOR maps where appropriate, and define how they're
1936	      canonicalized.

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

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

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

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

1950	   o  2 new use cases.

1952	Appendix E.  Acknowledgements

1954	   Thanks to Ilari Liusvaara, Justin Schuh, Mark Nottingham, Mike
1955	   Bishop, Ryan Sleevi, and Yoav Weiss for comments that improved this
1956	   draft.

1958	Author's Address

1960	   Jeffrey Yasskin
1961	   Google

1963	   Email: jyasskin@chromium.org