idnits 2.17.1 

draft-yasskin-httpbis-origin-signed-exchanges-impl-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 5 instances of too long lines in the document, the longest one
     being 38 characters in excess of 72.

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


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

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

  -- The document date (September 04, 2018) is 2060 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 1320

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

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

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

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

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

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

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

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

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

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

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

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

  == Outdated reference: A later version (-09) exists of
     draft-yasskin-http-origin-signed-responses-04

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

  ** 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)

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

  == Outdated reference: A later version (-09) exists of
     draft-yasskin-http-origin-signed-responses-03

  -- Duplicate reference: draft-yasskin-http-origin-signed-responses,
     mentioned in 'I-D.yasskin-http-origin-signed-responses-03', was also
     mentioned in 'I-D.yasskin-http-origin-signed-responses'.

  == Outdated reference: A later version (-09) exists of
     draft-yasskin-http-origin-signed-responses-04

  -- Duplicate reference: draft-yasskin-http-origin-signed-responses,
     mentioned in 'I-D.yasskin-http-origin-signed-responses-04', was also
     mentioned in 'I-D.yasskin-http-origin-signed-responses-03'.

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

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

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


     Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 19 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

--------------------------------------------------------------------------------


2	Network Working Group                                         J. Yasskin
3	Internet-Draft                                                   K. Ueno
4	Intended status: Standards Track                                  Google
5	Expires: March 8, 2019                                September 04, 2018

7	            Signed HTTP Exchanges Implementation Checkpoints
8	         draft-yasskin-httpbis-origin-signed-exchanges-impl-02

10	Abstract

12	   This document describes checkpoints of draft-yasskin-http-origin-
13	   signed-responses to synchronize implementation between clients,
14	   intermediates, and publishers.

16	Note to Readers

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

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

25	Status of This Memo

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

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

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

40	   This Internet-Draft will expire on March 8, 2019.

42	Copyright Notice

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

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

57	Table of Contents

59	   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
60	   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
61	   3.  Signing an exchange . . . . . . . . . . . . . . . . . . . . .   4
62	     3.1.  The Signature Header  . . . . . . . . . . . . . . . . . .   4
63	       3.1.1.  Examples  . . . . . . . . . . . . . . . . . . . . . .   5
64	     3.2.  CBOR representation of exchange headers . . . . . . . . .   6
65	       3.2.1.  Example . . . . . . . . . . . . . . . . . . . . . . .   7
66	     3.3.  Loading a certificate chain . . . . . . . . . . . . . . .   7
67	     3.4.  Canonical CBOR serialization  . . . . . . . . . . . . . .   8
68	     3.5.  Signature validity  . . . . . . . . . . . . . . . . . . .   9
69	     3.6.  Updating signature validity . . . . . . . . . . . . . . .  12
70	       3.6.1.  Examples  . . . . . . . . . . . . . . . . . . . . . .  13
71	     3.7.  The Accept-Signature header . . . . . . . . . . . . . . .  14
72	       3.7.1.  Integrity identifiers . . . . . . . . . . . . . . . .  15
73	       3.7.2.  Key type identifiers  . . . . . . . . . . . . . . . .  15
74	       3.7.3.  Key value identifiers . . . . . . . . . . . . . . . .  16
75	       3.7.4.  Examples  . . . . . . . . . . . . . . . . . . . . . .  16
76	   4.  Cross-origin trust  . . . . . . . . . . . . . . . . . . . . .  17
77	     4.1.  Stateful header fields  . . . . . . . . . . . . . . . . .  18
78	     4.2.  Certificate Requirements  . . . . . . . . . . . . . . . .  19
79	   5.  Transferring a signed exchange  . . . . . . . . . . . . . . .  20
80	     5.1.  Same-origin response  . . . . . . . . . . . . . . . . . .  20
81	       5.1.1.  Serialized headers for a same-origin response . . . .  21
82	       5.1.2.  The Signed-Headers Header . . . . . . . . . . . . . .  21
83	     5.2.  HTTP/2 extension for cross-origin Server Push . . . . . .  22
84	     5.3.  application/signed-exchange format  . . . . . . . . . . .  22
85	       5.3.1.  Cross-origin trust in application/signed-exchange . .  23
86	       5.3.2.  Example . . . . . . . . . . . . . . . . . . . . . . .  23
87	   6.  Security considerations . . . . . . . . . . . . . . . . . . .  24
88	   7.  Privacy considerations  . . . . . . . . . . . . . . . . . . .  24
89	   8.  IANA considerations . . . . . . . . . . . . . . . . . . . . .  25
90	     8.1.  Internet Media Type application/signed-exchange . . . . .  25
91	   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  25
92	     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  25
93	     9.2.  Informative References  . . . . . . . . . . . . . . . . .  27
94	     9.3.  URIs  . . . . . . . . . . . . . . . . . . . . . . . . . .  28
95	   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .  29
96	   Appendix B.  Acknowledgements . . . . . . . . . . . . . . . . . .  31
97	   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  31

99	1.  Introduction

101	   Each version of this document describes a checkpoint of
102	   [I-D.yasskin-http-origin-signed-responses] that can be implemented in
103	   sync by clients, intermediates, and publishers.  It defines a
104	   technique to detect which version each party has implemented so that
105	   mismatches can be detected up-front.

107	2.  Terminology

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

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

118	   Publisher  The entity that controls the server for a particular
119	      origin [RFC6454].  The publisher can get a CA to issue
120	      certificates for their private keys and can run a TLS server for
121	      their origin.

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

128	   Intermediate  An entity that fetches signed HTTP exchanges from a
129	      publisher or another intermediate and forwards them to another
130	      intermediate or a client.

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

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

138	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
139	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
140	   "OPTIONAL" in this document are to be interpreted as described in BCP
141	   14 [RFC2119] [RFC8174] when, and only when, they appear in all
142	   capitals, as shown here.

144	3.  Signing an exchange

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

152	   The client categorizes each signature as "valid" or "invalid" by
153	   validating that signature with its certificate or public key and
154	   other metadata against the exchange's headers and content
155	   (Section 3.5).  This validity then informs higher-level protocols.

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

164	3.1.  The Signature Header

166	   The "Signature" header field conveys a single signature for an
167	   exchange, accompanied by information about how to determine the
168	   authority of and refresh that signature.  Each signature directly
169	   signs the exchange's headers and identifies one of those headers that
170	   enforces the integrity of the exchange's payload.

172	   The "Signature" header is a Structured Header as defined by
173	   [I-D.ietf-httpbis-header-structure].  Its value MUST be a
174	   parameterised list (Section 3.3 of
175	   [I-D.ietf-httpbis-header-structure]), and the list MUST contain
176	   exactly one element.  Its ABNF is:

178	   Signature = sh-param-list

180	   The parameterised identifier in the list MUST have parameters named
181	   "sig", "integrity", "validity-url", "date", "expires", "cert-url",
182	   and "cert-sha256".  This specification gives no meaning to the
183	   identifier itself, which can be used as a human-readable identifier
184	   for the signature.  The present parameters MUST have the following
185	   values:

187	   "sig"  Binary content (Section 3.9 of
188	      [I-D.ietf-httpbis-header-structure]) holding the signature of most
189	      of these parameters and the exchange's headers.

191	   "integrity"  A string (Section 3.7 of
192	      [I-D.ietf-httpbis-header-structure]) containing a "/"-separated
193	      sequence of names starting with the lowercase name of the response
194	      header field that guards the response payload's integrity.  The
195	      meaning of subsequent names depends on the response header field,
196	      but for the "digest" header field, the single following name is
197	      the name of the digest algorithm that guards the payload's
198	      integrity.

200	   "cert-url"  A string (Section 3.7 of
201	      [I-D.ietf-httpbis-header-structure]) containing an absolute URL
202	      (Section 2) with a scheme of "https" or "data".

204	   "cert-sha256"  Binary content (Section 3.9 of
205	      [I-D.ietf-httpbis-header-structure]) holding the SHA-256 hash of
206	      the first certificate found at "cert-url".

208	   "validity-url"  A string (Section 3.7 of
209	      [I-D.ietf-httpbis-header-structure]) containing an absolute URL
210	      (Section 2) with a scheme of "https".

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

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

218	3.1.1.  Examples

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

224	Signature:
225	 sig1;
226	  sig=*MEUCIQDXlI2gN3RNBlgFiuRNFpZXcDIaUpX6HIEwcZEc0cZYLAIga9DsVOMM+g5YpwEBdGW3sS+bvnmAJJiSMwhuBdqp5UY=*;
227	  integrity="digest/mi-sha256-03";
228	  validity-url="https://example.com/resource.validity.1511128380";
229	  cert-url="https://example.com/oldcerts";
230	  cert-sha256=*W7uB969dFW3Mb5ZefPS9Tq5ZbH5iSmOILpjv2qEArmI=*;
231	  date=1511128380; expires=1511733180

233	   The signature uses a secp256r1 certificate within
234	   "https://example.com/".

236	   It relies on the "Digest" response header with the mi-sha256-03
237	   digest algorithm to guard the integrity of the response payload.

239	   The signature includes a "validity-url" that includes the first time
240	   the resource was seen.  This allows multiple versions of a resource
241	   at the same URL to be updated with new signatures, which allows
242	   clients to avoid transferring extra data while the old versions don't
243	   have known security bugs.

245	   The certificate at "https://example.com/certs" has a "subjectAltName"
246	   of "example.com", meaning that if it and its signature validate, the
247	   exchange can be trusted as having an origin of
248	   "https://example.com/".

250	3.2.  CBOR representation of exchange headers

252	   To sign an exchange's headers, they need to be serialized into a byte
253	   string.  Since intermediaries and distributors might rearrange, add,
254	   or just reserialize headers, we can't use the literal bytes of the
255	   headers as this serialization.  Instead, this section defines a CBOR
256	   representation that can be embedded into other CBOR, canonically
257	   serialized (Section 3.4), and then signed.

259	   The CBOR representation of a set of request and response metadata and
260	   headers is the CBOR ([RFC7049]) array with the following content:

262	   1.  The map mapping:

264	       *  The byte string ':method' to the byte string containing the
265	          request's method.

267	       *  For each request header field except for the "Host" header
268	          field, the header field's lowercase name as a byte string to
269	          the header field's value as a byte string.

271	          Note: "Host" is excluded because it is part of the effective
272	          request URI, which is represented outside of this map.

274	   2.  The map mapping:

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

279	       *  For each response header field, the header field's lowercase
280	          name as a byte string to the header field's value as a byte
281	          string.

283	3.2.1.  Example

285	   Given the HTTP exchange:

287	   GET / HTTP/1.1
288	   Host: example.com
289	   Accept: */*

291	   HTTP/1.1 200
292	   Content-Type: text/html
293	   Digest: mi-sha256-03=dcRDgR2GM35DluAV13PzgnG6+pvQwPywfFvAu1UeFrs=
294	   Signed-Headers: "content-type", "digest"

296	   <!doctype html>
297	   <html>
298	   ...

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

304	[
305	  {
306	    'accept': '*/*',
307	    ':method': 'GET',
308	  },
309	  {
310	    'digest': 'mi-sha256-03=dcRDgR2GM35DluAV13PzgnG6+pvQwPywfFvAu1UeFrs=',
311	    ':status': '200',
312	    'content-type': 'text/html'
313	  }
314	]

316	3.3.  Loading a certificate chain

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

322	   cert-chain = [
323	     "&#128220;&#9939;", ; U+1F4DC U+26D3
324	     + {
325	       cert: bytes,
326	       ? ocsp: bytes,
327	       ? sct: bytes,
328	       * tstr => any,
329	     }
330	   ]
331	   The first map (second item) in the CBOR array is treated as the end-
332	   entity certificate, and the client will attempt to build a path
333	   ([RFC5280]) to it from a trusted root using the other certificates in
334	   the chain.

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

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

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

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

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

356	   2.  Let "certificate-chain" be the array of certificates and
357	       properties produced by parsing "raw-chain" using the CDDL above.
358	       If any of the requirements above aren't satisfied, return
359	       "invalid".  Note that this validation requirement might be
360	       impractical to completely achieve due to certificate validation
361	       implementations that don't enforce DER encoding or other standard
362	       constraints.

364	   3.  Return "certificate-chain".

366	3.4.  Canonical CBOR serialization

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

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

375	   o  Items MUST NOT be encoded with indefinite length.

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

381	      1.  10, encoded as 0A.

383	      2.  100, encoded as 18 64.

385	      3.  -1, encoded as 20.

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

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

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

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

395	      8.  false, encoded as F4.

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

401	3.5.  Signature validity

403	   The client MUST parse the "Signature" header field as the
404	   parameterised list (Section 4.2.3 of
405	   [I-D.ietf-httpbis-header-structure]) described in Section 3.1.  If an
406	   error is thrown during this parsing or any of the requirements
407	   described there aren't satisfied, the exchange has no valid
408	   signatures.  Otherwise, each member of this list represents a
409	   signature with parameters.

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

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

418	   o  "headers", a byte sequence holding the canonical serialization
419	      (Section 3.4) of the CBOR representation (Section 3.2) of the
420	      exchange's request and response metadata and headers, and

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

426	   Potentially-valid results include:

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

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

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

440	   1.   Let "payload" be the payload body (Section 3.3 of [RFC7230]) of
441	        "exchange".  Note that the payload body is the message body with
442	        any transfer encodings removed.

444	   2.   Let:

446	        *  "signature" be the signature (binary content in the
447	           parameterised identifier's "sig" parameter).

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

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

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

455	        *  "cert-sha256" be the signature's "cert-sha256" parameter, if
456	           any.

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

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

464	   3.   Set "publicKey" and "signing-alg" depending on which key fields
465	        are present:

467	        1.  Assert: "cert-url" is present.

469	            1.  Let "certificate-chain" be the result of loading the
470	                certificate chain at "cert-url" passing the "forceFetch"
471	                flag (Section 3.3).  If this returns "invalid", return
472	                "invalid".

474	            2.  Let "main-certificate" be the first certificate in
475	                "certificate-chain".

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

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

481	            5.  If "publicKey" is a key using the secp256r1 elliptic
482	                curve, set "signing-alg" to ecdsa_secp256r1_sha256 as
483	                defined in Section 4.2.3 of [I-D.ietf-tls-tls13].

485	            6.  Otherwise, return "invalid".

487	   4.   If "expires" is more than 7 days (604800 seconds) after "date",
488	        return "invalid".

490	   5.   If the current time is before "date" or after "expires", return
491	        "invalid".

493	   6.   Let "message" be the concatenation of the following byte
494	        strings.  This matches the [I-D.ietf-tls-tls13] format to avoid
495	        cross-protocol attacks if anyone uses the same key in a TLS
496	        certificate and an exchange-signing certificate.

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

500	        2.  A context string: the ASCII encoding of "HTTP Exchange 1
501	            b2".

503	            Note: As this is a snapshot of a draft of
504	            [I-D.yasskin-http-origin-signed-responses], it uses a
505	            distinct context string.

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

509	        4.  If "cert-sha256" is set, a byte holding the value 32
510	            followed by the 32 bytes of the value of "cert-sha256".
511	            Otherwise a 0 byte.

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

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

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

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

523	        9.  The 8-byte big-endian encoding of the length in bytes of
524	            "headers", followed by the bytes of "headers".

526	   7.   If "cert-url" is present and the SHA-256 hash of "main-
527	        certificate"'s "cert_data" is not equal to "cert-sha256" (whose
528	        presence was checked when the "Signature" header field was
529	        parsed), return "invalid".

531	        Note that this intentionally differs from TLS 1.3, which signs
532	        the entire certificate chain in its Certificate Verify
533	        (Section 4.4.3 of [I-D.ietf-tls-tls13]), in order to allow
534	        updating the stapled OCSP response without updating signatures
535	        at the same time.

537	   8.   If "signature" is not a valid signature of "message" by
538	        "publicKey" using "signing-alg", return "invalid".

540	   9.   If "integrity" does not match "digest/mi-sha256-03", return
541	        "invalid".

543	   10.  If "payload" doesn't match the integrity information in the
544	        header described by "integrity", return "invalid".

546	   Note that the above algorithm can determine that an exchange's
547	   headers are potentially-valid before the exchange's payload is
548	   received.  Similarly, if "integrity" identifies a header field and
549	   parameter like "Digest: mi-sha256-03" ([I-D.thomson-http-mice]) that
550	   can incrementally validate the payload, early parts of the payload
551	   can be determined to be potentially-valid before later parts of the
552	   payload.  Higher-level protocols MAY process parts of the exchange
553	   that have been determined to be potentially-valid as soon as that
554	   determination is made but MUST NOT process parts of the exchange that
555	   are not yet potentially-valid.  Similarly, as the higher-level
556	   protocol determines that parts of the exchange are actually valid,
557	   the client MAY process those parts of the exchange and MUST wait to
558	   process other parts of the exchange until they too are determined to
559	   be valid.

561	3.6.  Updating signature validity

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

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

572	   The "validity-url" parameter (Paragraph 5) of the signatures provides
573	   a way to fetch new signatures or learn where to fetch a complete
574	   updated exchange.

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

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

583	   validity = {
584	     ? signatures: [ + bytes ]
585	     ? update: {
586	       ? size: uint,
587	     }
588	   ]

590	   The elements of the "signatures" array are parameterised identifiers
591	   (Section 4.2.4 of [I-D.ietf-httpbis-header-structure]) meant to
592	   replace the signatures within the "Signature" header field pointing
593	   to this validity data.  If the signed exchange contains a bug severe
594	   enough that clients need to stop using the content, the "signatures"
595	   array MUST NOT be present.

597	   If the the "update" map is present, that indicates that a new version
598	   of the signed exchange is available at its effective request URI
599	   (Section 5.5 of [RFC7230]) and can give an estimate of the size of
600	   the updated exchange ("update.size").  If the signed exchange is
601	   currently the most recent version, the "update" SHOULD NOT be
602	   present.

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

608	3.6.1.  Examples

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

614	   Signature:
615	    sig1;
616	     sig=*MEUCIQ...*;
617	     ...
618	     validity-url="https://example.com/resource.validity.1511157180";
619	     cert-url="https://example.com/oldcerts";
620	     date=1511128380; expires=1511733180

622	   At 2017-11-27 11:02 UTC, "sig1" has expired, so the client needs to
623	   fetch "https://example.com/resource.validity.1511157180" (the
624	   "validity-url" of "sig1") if it wishes to update that signature.
625	   This URL might contain:

627	{
628	  "signatures": [
629	    'sig1; '
630	    'sig=*MEQCIC/I9Q+7BZFP6cSDsWx43pBAL0ujTbON/+7RwKVk+ba5AiB3FSFLZqpzmDJ0NumNwN04pqgJZE99fcK86UjkPbj4jw==*; '
631	    'validity-url="https://example.com/resource.validity.1511157180"; '
632	    'integrity="digest/mi-sha256-03"'
633	    'cert-url="https://example.com/newcerts"; '
634	    'cert-sha256=*J/lEm9kNRODdCmINbvitpvdYKNQ+YgBj99DlYp4fEXw=*; '
635	    'date=1511733180; expires=1512337980'
636	  ],
637	  "update": {
638	    "size": 5557452
639	  }
640	}

642	   This indicates that the client could fetch a newer version at
643	   "https://example.com/resource" (the original URL of the exchange), or
644	   that the validity period of the old version can be extended by
645	   replacing the original signature with the new signature provided.
646	   The signature of the updated signed exchange would be:

648	   Signature:
649	    sig1;
650	     sig=*MEQCIC...*;
651	     ...
652	     validity-url="https://example.com/resource.validity.1511157180";
653	     cert-url="https://example.com/newcerts";
654	     date=1511733180; expires=1512337980

656	3.7.  The Accept-Signature header

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

665	   When a server receives an "Accept-Signature" header field in a client
666	   request, it SHOULD reply with any available "Signature" header fields
667	   for its response that the "Accept-Signature" header field indicates
668	   the client supports.  However, if the "Accept-Signature" value
669	   violates a requirement in this section, the server MUST behave as if
670	   it hadn't received any "Accept-Signature" header at all.

672	   The "Accept-Signature" header field is a Structured Header as defined
673	   by [I-D.ietf-httpbis-header-structure].  Its value MUST be a
674	   parameterised list (Section 3.3 of
675	   [I-D.ietf-httpbis-header-structure]).  Its ABNF is:

677	   Accept-Signature = sh-param-list

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

683	   Each identifier in the "Accept-Signature" header field's value
684	   indicates that a feature of the "Signature" header field
685	   (Section 3.1) is supported.  If the identifier begins with a "-"
686	   character, it instead indicates that the feature named by the rest of
687	   the identifier is not supported.  Unknown identifiers and parameters
688	   MUST be ignored because new identifiers and new parameters on
689	   existing identifiers may be defined by future specifications.

691	3.7.1.  Integrity identifiers

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

701	   If the "Accept-Signature" header field is present, servers SHOULD
702	   assume support for "digest/mi-sha256-03" unless the header field
703	   states otherwise.

705	3.7.2.  Key type identifiers

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

711	   If the "Accept-Signature" header field is present, servers SHOULD
712	   assume support for "ecdsa/secp256r1" unless the header field states
713	   otherwise.

715	3.7.3.  Key value identifiers

717	   The "ed25519key" identifier has parameters indicating the public keys
718	   that will be used to validate the returned signature.  Each
719	   parameter's name is re-interpreted as binary content (Section 3.9 of
720	   [I-D.ietf-httpbis-header-structure]) encoding a prefix of the public
721	   key.  For example, if the client will validate signatures using the
722	   public key whose base64 encoding is
723	   "11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo=", valid "Accept-
724	   Signature" header fields include:

726	Accept-Signature: ..., ed25519key; *11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo=*
727	Accept-Signature: ..., ed25519key; *11qYAYKxCrfVS/7TyWQHOg==*
728	Accept-Signature: ..., ed25519key; *11qYAQ==*
729	Accept-Signature: ..., ed25519key; **

731	   but not

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

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

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

739	   because it doesn't start or end with the "*"s that indicate binary
740	   content.

742	   Note that "ed25519key; **" is an empty prefix, which matches all
743	   public keys, so it's useful in subresource integrity cases like
744	   "<link rel=preload as=script href="...">" where the public key isn't
745	   known until the matching "<script src="..." integrity="...">" tag.

747	3.7.4.  Examples

749	   Accept-Signature: digest/mi-sha256-03

751	   states that the client will accept signatures with payload integrity
752	   assured by the "Digest" header and "mi-sha256-03" digest algorithm
753	   and implies that the client will accept signatures from ECDSA keys on
754	   the secp256r1 curve.

756	   Accept-Signature: -ecdsa/secp256r1, ecdsa/secp384r1
757	   states that the client will accept ECDSA keys on the secp384r1 curve
758	   but not the secp256r1 curve and payload integrity assured with the
759	   "Digest: mi-sha256-03" header field.

761	4.  Cross-origin trust

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

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

769	   o  "headers", a byte sequence holding the canonical serialization
770	      (Section 3.4) of the CBOR representation (Section 3.2) of the
771	      exchange's request and response metadata and headers, and

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

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

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

785	   2.  Use Section 3.5 to determine the signature's validity for
786	       "requestUrl", "headers", and "payload", getting "certificate-
787	       chain" back.  If this returned "invalid" or didn't return a
788	       certificate chain, return "invalid".

790	   3.  Let "exchange" be the exchange metadata and headers parsed out of
791	       "headers".

793	   4.  If "exchange"'s request method is not safe (Section 4.2.1 of
794	       [RFC7231]) or not cacheable (Section 4.2.3 of [RFC7231]), return
795	       "invalid".

797	   5.  If "exchange"'s headers contain a stateful header field, as
798	       defined in Section 4.1, return "invalid".

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

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

807	       1.  Use "certificate-chain" to validate that its first entry,
808	           "main-certificate" is trusted as "authority"'s server
809	           certificate ([RFC5280] and other undocumented conventions).
810	           Let "path" be the path that was used from the "main-
811	           certificate" to a trusted root, including the "main-
812	           certificate" but excluding the root.

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

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

824	       4.  Validate that valid SCTs from trusted logs are available from
825	           any of:

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

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

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

836	           as described by Section 3.3 of [RFC6962].

838	   8.  Return "valid".

840	4.1.  Stateful header fields

842	   As described in Section 6.1 of
843	   [I-D.yasskin-http-origin-signed-responses], a publisher can cause
844	   problems if they sign an exchange that includes private information.
845	   There's no way for a client to be sure an exchange does or does not
846	   include private information, but header fields that store or convey
847	   stored state in the client are a good sign.

849	   A stateful request header field informs the server of per-client
850	   state.  These include but are not limited to:

852	   o  "Authorization", [RFC7235]

854	   o  "Cookie", [RFC6265]

856	   o  "Cookie2", [RFC2965]

858	   o  "Proxy-Authorization", [RFC7235]

860	   o  "Sec-WebSocket-Key", [RFC6455]

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

866	   o  "Authentication-Control", [RFC8053]

868	   o  "Authentication-Info", [RFC7615]

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

872	   o  "Proxy-Authenticate", [RFC7235]

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

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

878	   o  "Set-Cookie", [RFC6265]

880	   o  "Set-Cookie2", [RFC2965]

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

884	   o  "WWW-Authenticate", [RFC7235]

886	4.2.  Certificate Requirements

888	   We define a new X.509 extension, CanSignHttpExchanges to be used in
889	   the certificate when the certificate permits the usage of signed
890	   exchanges.  When this extension is not present the client MUST NOT
891	   accept a signature from the certificate as proof that a signed
892	   exchange is authoritative for a domain covered by the certificate.
893	   When it is present, the client MUST follow the validation procedure
894	   in Section 4.

896	      CanSignHttpExchanges ::= NULL

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

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

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

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

912	   Conforming CAs MUST NOT mark this extension as critical.

914	   Clients MUST NOT accept certificates with this extension in TLS
915	   connections (Section 4.4.2.2 of [I-D.ietf-tls-tls13]).

917	   This draft of the specification identifies the CanSignHttpExchanges
918	   extension with the id-ce-canSignHttpExchangesDraft OID:

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

923	   This OID might or might not be used as the final OID for the
924	   extension, so certificates including it might need to be reissued
925	   once the final RFC is published.

927	5.  Transferring a signed exchange

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

932	5.1.  Same-origin response

934	   The signature for a signed exchange can be included in a normal HTTP
935	   response.  Because different clients send different request header
936	   fields, and intermediate servers add response header fields, it can
937	   be impossible to have a signature for the exact request and response
938	   that the client sees.  Therefore, when a client calls the validation
939	   procedure in Section 3.5) to validate the "Signature" header field
940	   for an exchange represented as a normal HTTP request/response pair,
941	   it MUST pass:

943	   o  The "Signature" header field,

945	   o  The effective request URI (Section 5.5 of [RFC7230]) of the
946	      request,

948	   o  The serialized headers defined by Section 5.1.1, and
949	   o  The response's payload.

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

955	5.1.1.  Serialized headers for a same-origin response

957	   The serialized headers of an exchange represented as a normal HTTP
958	   request/response pair (Section 2.1 of [RFC7230] or Section 8.1 of
959	   [RFC7540]) are the canonical serialization (Section 3.4) of the CBOR
960	   representation (Section 3.2) of the following request and response
961	   metadata and headers:

963	   o  The method (Section 4 of [RFC7231]) of the request.

965	   o  The response status code (Section 6 of [RFC7231]) and the response
966	      header fields whose names are listed in that exchange's "Signed-
967	      Headers" header field (Section 5.1.2).  If a response header field
968	      name from "Signed-Headers" does not appear in the exchange's
969	      response header fields, the exchange has no serialized headers.

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

977	5.1.2.  The Signed-Headers Header

979	   The "Signed-Headers" header field identifies an ordered list of
980	   response header fields to include in a signature.  The request URL
981	   and response status are included unconditionally.  This allows a TLS-
982	   terminating intermediate to reorder headers without breaking the
983	   signature.  This _can_ also allow the intermediate to add headers
984	   that will be ignored by some higher-level protocols, but Section 3.5
985	   provides a hook to let other higher-level protocols reject such
986	   insecure headers.

988	   This header field appears once instead of being incorporated into the
989	   signatures' parameters because the signed header fields need to be
990	   consistent across all signatures of an exchange, to avoid forcing
991	   higher-level protocols to merge the header field lists of valid
992	   signatures.

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

998	   Signed-Headers = sh-list

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

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

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

1010	   Cross origin push is not implemented.

1012	5.3.  application/signed-exchange format

1014	   To allow signed exchanges to be the targets of "<link rel=prefetch>"
1015	   tags, we define the "application/signed-exchange" content type that
1016	   represents a signed HTTP exchange, including request metadata and
1017	   header fields, response metadata and header fields, and a response
1018	   payload.

1020	   This content type consists of the concatenation of the following
1021	   items:

1023	   1.  The ASCII characters "sxg1-b2" followed by a 0 byte, to serve as
1024	       a file signature.  This is redundant with the MIME type, and
1025	       recipients that receive both MUST check that they match and stop
1026	       parsing if they don't.

1028	       Note: As this is a snapshot of a draft of
1029	       [I-D.yasskin-http-origin-signed-responses], it uses a distinct
1030	       file signature.

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

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

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

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

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

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

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

1053	   7.  "headerLength" bytes holding "signedHeaders", the canonical
1054	       serialization (Section 3.4) of the CBOR representation of the
1055	       request and response headers of the exchange represented by the
1056	       "application/signed-exchange" resource (Section 3.2), excluding
1057	       the "Signature" header field.

1059	       Note that this is exactly the bytes used when checking signature
1060	       validity in Section 3.5.

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

1065	       Note that the use of the payload body here means that a
1066	       "Transfer-Encoding" header field inside the "application/signed-
1067	       exchange" header block has no effect.  A "Transfer-Encoding"
1068	       header field on the outer HTTP response that transfers this
1069	       resource still has its normal effect.

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

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

1078	5.3.2.  Example

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

1087	   sxg1-b2\0<2-byte length of the following url string>
1088	   https://example.com/<3-byte length of the following header
1089	   value><3-byte length of the encoding of the
1090	   following array>sig1; sig=*...; integrity="digest/mi-sha256-03"; ...[
1091	     {
1092	       ':method': 'GET',
1093	       'accept', '*/*'
1094	     },
1095	     {
1096	       ':status': '200',
1097	       'content-type': 'text/html'
1098	     }
1099	   ]<!doctype html>\r\n<html>...

1101	6.  Security considerations

1103	   All of the security considerations from Section 6 of
1104	   [I-D.yasskin-http-origin-signed-responses] apply.

1106	7.  Privacy considerations

1108	   Normally, when a client fetches "https://o1.com/resource.js",
1109	   "o1.com" learns that the client is interested in the resource.  If
1110	   "o1.com" signs "resource.js", "o2.com" serves it as "https://o2.com/
1111	   o1resource.js", and the client fetches it from there, then "o2.com"
1112	   learns that the client is interested, and if the client executes the
1113	   Javascript, that could also report the client's interest back to
1114	   "o1.com".

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

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

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

1133	8.  IANA considerations

1135	   This depends on the following IANA registrations in
1136	   [I-D.yasskin-http-origin-signed-responses]:

1138	   o  The "Signature" header field

1140	   o  The "Accept-Signature" header field

1142	   o  The "Signed-Headers" header field

1144	   o  The application/cert-chain+cbor media type

1146	   This document also modifies the registration for:

1148	8.1.  Internet Media Type application/signed-exchange

1150	   Type name: application

1152	   Subtype name: signed-exchange

1154	   Required parameters:

1156	   o  v: A string denoting the version of the file format.  ([RFC5234]
1157	      ABNF: "version = DIGIT/%x61-7A") The version defined in this
1158	      specification is "b2".  When used with the "Accept" header field
1159	      (Section 5.3.1 of [RFC7231]), this parameter can be a comma
1160	      (,)-separated list of version strings.  ([RFC5234] ABNF: "version-
1161	      list = version *( "," version )") The server is then expected to
1162	      reply with a resource using a particular version from that list.

1164	      Note: As this is a snapshot of a draft of
1165	      [I-D.yasskin-http-origin-signed-responses], it uses a distinct
1166	      version number.

1168	   Magic number(s): 73 78 67 31 2D 62 32 00

1170	   The other fields are the same as the registration in
1171	   [I-D.yasskin-http-origin-signed-responses].

1173	9.  References

1175	9.1.  Normative References

1177	   [FETCH]    WHATWG, "Fetch", September 2018,
1178	              <https://fetch.spec.whatwg.org/>.

1180	   [I-D.ietf-cbor-cddl]
1181	              Birkholz, H., Vigano, C., and C. Bormann, "Concise data
1182	              definition language (CDDL): a notational convention to
1183	              express CBOR and JSON data structures", draft-ietf-cbor-
1184	              cddl-05 (work in progress), August 2018.

1186	   [I-D.ietf-httpbis-header-structure]
1187	              Nottingham, M. and P. Kamp, "Structured Headers for HTTP",
1188	              draft-ietf-httpbis-header-structure-07 (work in progress),
1189	              July 2018.

1191	   [I-D.ietf-tls-tls13]
1192	              Rescorla, E., "The Transport Layer Security (TLS) Protocol
1193	              Version 1.3", draft-ietf-tls-tls13-28 (work in progress),
1194	              March 2018.

1196	   [I-D.yasskin-http-origin-signed-responses]
1197	              Yasskin, J., "Signed HTTP Exchanges", draft-yasskin-http-
1198	              origin-signed-responses-04 (work in progress), June 2018.

1200	   [POSIX]    IEEE and The Open Group, "The Open Group Base
1201	              Specifications Issue 7", name IEEE, value 1003.1-2008,
1202	              2016 Edition, 2016,
1203	              <http://pubs.opengroup.org/onlinepubs/9699919799/
1204	              basedefs/>.

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

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

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

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

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

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

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

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

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

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

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

1260	   [URL]      WHATWG, "URL", September 2018,
1261	              <https://url.spec.whatwg.org/>.

1263	9.2.  Informative References

1265	   [I-D.thomson-http-mice]
1266	              Thomson, M. and J. Yasskin, "Merkle Integrity Content
1267	              Encoding", draft-thomson-http-mice-03 (work in progress),
1268	              August 2018.

1270	   [I-D.yasskin-http-origin-signed-responses-03]
1271	              Yasskin, J., "Signed HTTP Exchanges", draft-yasskin-http-
1272	              origin-signed-responses-03 (work in progress), March 2018,
1273	              <https://tools.ietf.org/html/
1274	              draft-yasskin-http-origin-signed-responses-03>.

1276	   [I-D.yasskin-http-origin-signed-responses-04]
1277	              Yasskin, J., "Signed HTTP Exchanges", draft-yasskin-http-
1278	              origin-signed-responses-04 (work in progress), June 2018,
1279	              <https://tools.ietf.org/html/
1280	              draft-yasskin-http-origin-signed-responses-04>.

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

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

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

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

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

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

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

1313	   [W3C.NOTE-OPS-OverHTTP]
1314	              Hensley, P., Metral, M., Shardanand, U., Converse, D., and
1315	              M. Myers, "Implementation of OPS Over HTTP", W3C NOTE
1316	              NOTE-OPS-OverHTTP, June 1997.

1318	9.3.  URIs

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

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

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

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

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

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

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

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

1337	Appendix A.  Change Log

1339	   draft-02

1341	   Vs. draft-01:

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

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

1347	   o  Define the "integrity" field of the Signature header to include
1348	      the digest algorithm.

1350	   o  Put a fallback URL at the beginning of the "application/signed-
1351	      exchange" format, and remove ':url' key from the CBOR
1352	      representation of the exchange's request and response metadata and
1353	      headers.

1355	   o  The new signed message format which embeds the exact bytes of the
1356	      CBOR representation of the exchange's request and response
1357	      metadata and headers.

1359	   o  When validating the signature validity, move the "payload"
1360	      integrity check steps to after verifying "header".

1362	   o  Versions in file signatures and context strings are "b2".

1364	   draft-01

1366	   Vs.  [I-D.yasskin-http-origin-signed-responses-04]:

1368	   o  The MI header and mi-sha256 content-encoding are renamed to MI-
1369	      Draft2 and mi-sha256-draft2 in case [I-D.thomson-http-mice]
1370	      changes.

1372	   o  Signed exchanges cannot be transmitted using HTTP/2 Push.

1374	   o  Removed non-normative sections.

1376	   o  The mi-sha256 encoding must have records <= 16kB.

1378	   o  The signature must be <=16kB long.

1380	   o  The HTTP request and response headers together must be <=512kB.

1382	   o  Versions in file signatures and context strings are "b1".

1384	   o  Only 1 signature is supported.

1386	   o  Removed support for ed25519 signatures.

1388	   draft-00

1390	   Vs.  [I-D.yasskin-http-origin-signed-responses-03]:

1392	   o  Removed non-normative sections.

1394	   o  Only 1 signature is supported.

1396	   o  Only 2048-bit RSA keys are supported.

1398	   o  The certificate chain resource uses the TLS 1.3 Certificate
1399	      message format rather than a CBOR-based format.

1401	   o  OCSP responses and SCTs are not checked.

1403	   o  Certificates without the CanSignHttpExchanges extension are
1404	      allowed.

1406	   o  The signature string starts with 64 0x20 octets like the TLS 1.3
1407	      signature format.

1409	   o  The application/http-exchange+cbor format is replaced with a more
1410	      specialized application/signed-exchange format.

1412	   o  Signed exchanges can only be transmitted using the application/
1413	      signed-exchange format, not HTTP/2 Push or plain HTTP request/
1414	      response pairs.

1416	   o  Only the MI payload-integrity header is supported.

1418	   o  The mi-sha256 encoding must have records <= 16kB.

1420	   o  The Accept-Signature header isn't used.

1422	   o  Require absolute URLs.

1424	Appendix B.  Acknowledgements

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

1430	Authors' Addresses

1432	   Jeffrey Yasskin
1433	   Google

1435	   Email: jyasskin@chromium.org

1437	   Kouhei Ueno
1438	   Google

1440	   Email: kouhei@chromium.org