idnits 2.17.1 draft-yasskin-httpbis-origin-signed-exchanges-impl-03.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 4 instances of too long lines in the document, the longest one being 38 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 24, 2019) is 1732 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 '' and '' 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 1231 -- Looks like a reference, but probably isn't: '2' on line 1233 -- Looks like a reference, but probably isn't: '3' on line 1235 -- Looks like a reference, but probably isn't: '4' on line 1237 -- Looks like a reference, but probably isn't: '5' on line 1239 -- Looks like a reference, but probably isn't: '100' on line 373 == Missing Reference: '-1' is mentioned on line 375, but not defined -- Looks like a reference, but probably isn't: '6' on line 1242 -- Looks like a reference, but probably isn't: '7' on line 1244 -- Possible downref: Non-RFC (?) normative reference: ref. 'FETCH' == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-header-structure-10 == Outdated reference: A later version (-06) exists of draft-ietf-httpbis-variants-05 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-httpbis-variants-05' == Outdated reference: A later version (-09) exists of draft-yasskin-http-origin-signed-responses-06 -- Possible downref: Non-RFC (?) normative reference: ref. 'POSIX' ** Obsolete normative reference: RFC 6844 (Obsoleted by RFC 8659) ** Obsolete normative reference: RFC 6962 (Obsoleted by RFC 9162) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) -- Possible downref: Non-RFC (?) normative reference: ref. 'URL' == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-cache-05 == 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'. == Outdated reference: A later version (-09) exists of draft-yasskin-http-origin-signed-responses-05 -- Duplicate reference: draft-yasskin-http-origin-signed-responses, mentioned in 'I-D.yasskin-http-origin-signed-responses-05', was also mentioned in 'I-D.yasskin-http-origin-signed-responses-04'. -- 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 7540 (Obsoleted by RFC 9113) -- Obsolete informational reference (is this intentional?): RFC 7615 (Obsoleted by RFC 9110) Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 21 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: January 25, 2020 July 24, 2019 7 Signed HTTP Exchanges Implementation Checkpoints 8 draft-yasskin-httpbis-origin-signed-exchanges-impl-03 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 January 25, 2020. 42 Copyright Notice 44 Copyright (c) 2019 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 response headers . . . . 6 65 3.2.1. Example . . . . . . . . . . . . . . . . . . . . . . . 6 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 4. Cross-origin trust . . . . . . . . . . . . . . . . . . . . . 14 73 4.1. Uncached header fields . . . . . . . . . . . . . . . . . 16 74 4.1.1. Stateful header fields . . . . . . . . . . . . . . . 17 75 4.2. Certificate Requirements . . . . . . . . . . . . . . . . 17 76 4.2.1. Extensions to the CAA Record: cansignhttpexchanges 77 Parameter . . . . . . . . . . . . . . . . . . . . . . 19 78 5. Transferring a signed exchange . . . . . . . . . . . . . . . 19 79 5.1. Same-origin response . . . . . . . . . . . . . . . . . . 19 80 5.2. HTTP/2 extension for cross-origin Server Push . . . . . . 19 81 5.3. application/signed-exchange format . . . . . . . . . . . 19 82 5.3.1. Cross-origin trust in application/signed-exchange . . 20 83 5.3.2. Content negotiation . . . . . . . . . . . . . . . . . 21 84 5.3.3. Example . . . . . . . . . . . . . . . . . . . . . . . 21 85 6. Security considerations . . . . . . . . . . . . . . . . . . . 21 86 7. Privacy considerations . . . . . . . . . . . . . . . . . . . 21 87 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 22 88 8.1. Internet Media Type application/signed-exchange . . . . . 22 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 90 9.1. Normative References . . . . . . . . . . . . . . . . . . 23 91 9.2. Informative References . . . . . . . . . . . . . . . . . 25 92 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 26 93 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 27 94 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 29 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 97 1. Introduction 99 Each version of this document describes a checkpoint of 100 [I-D.yasskin-http-origin-signed-responses] that can be implemented in 101 sync by clients, intermediates, and publishers. It defines a 102 technique to detect which version each party has implemented so that 103 mismatches can be detected up-front. 105 2. Terminology 107 Absolute URL A string for which the URL parser [3] ([URL]), when run 108 without a base URL, returns a URL rather than a failure, and for 109 which that URL has a null fragment. This is similar to the 110 absolute-URL string [4] concept defined by ([URL]) but might not 111 include exactly the same strings. 113 Author The entity that wrote the content in a particular resource. 114 This specification deals with publishers rather than authors. 116 Publisher The entity that controls the server for a particular 117 origin [RFC6454]. The publisher can get a CA to issue 118 certificates for their private keys and can run a TLS server for 119 their origin. 121 Exchange (noun) An HTTP request URL, content negotiation 122 information, and an HTTP response. This are encoded into the 123 dedicated format in Section 5.3, which uses 124 [I-D.ietf-httpbis-variants-05] to encode the content negotiation 125 information. This is not quite the same meaning as defined by 126 Section 8 of [RFC7540], which assumes the content negotiation 127 information is embedded into HTTP request headers. 129 Intermediate An entity that fetches signed HTTP exchanges from a 130 publisher or another intermediate and forwards them to another 131 intermediate or a client. 133 Client An entity that uses a signed HTTP exchange and needs to be 134 able to prove that the publisher vouched for it as coming from its 135 claimed origin. 137 Unix time Defined by [POSIX] section 4.16 [5]. 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 141 "OPTIONAL" in this document are to be interpreted as described in BCP 142 14 [RFC2119] [RFC8174] when, and only when, they appear in all 143 capitals, as shown here. 145 3. Signing an exchange 147 In the response of an HTTP exchange the server MAY include a 148 "Signature" header field (Section 3.1) holding a list of one or more 149 parameterised signatures that vouch for the content of the exchange. 150 Exactly which content the signature vouches for can depend on how the 151 exchange is transferred (Section 5). 153 The client categorizes each signature as "valid" or "invalid" by 154 validating that signature with its certificate or public key and 155 other metadata against the exchange's URL, response headers, and 156 content (Section 3.5). This validity then informs higher-level 157 protocols. 159 Each signature is parameterised with information to let a client 160 fetch assurance that a signed exchange is still valid, in the face of 161 revoked certificates and newly-discovered vulnerabilities. This 162 assurance can be bundled back into the signed exchange and forwarded 163 to another client, which won't have to re-fetch this validity 164 information for some period of time. 166 3.1. The Signature Header 168 The "Signature" header field conveys a single signature for an 169 exchange, accompanied by information about how to determine the 170 authority of and refresh that signature. Each signature directly 171 signs the exchange's URL and response headers and identifies one of 172 those headers that enforces the integrity of the exchange's payload. 174 The "Signature" header is a Structured Header as defined by 175 [I-D.ietf-httpbis-header-structure-10]. Its value MUST be a 176 parameterised list (Section 3.4 of 177 [I-D.ietf-httpbis-header-structure-10]), and the list MUST contain 178 exactly one element. Its ABNF is: 180 Signature = sh-param-list 182 The parameterised identifier in the list MUST have parameters named 183 "sig", "integrity", "validity-url", "date", "expires", "cert-url", 184 and "cert-sha256". This specification gives no meaning to the 185 identifier itself, which can be used as a human-readable identifier 186 for the signature. The present parameters MUST have the following 187 values: 189 "sig" Byte sequence (Section 3.10 of 190 [I-D.ietf-httpbis-header-structure-10]) holding the signature of 191 most of these parameters and the exchange's URL and response 192 headers. 194 "integrity" A string (Section 3.8 of 195 [I-D.ietf-httpbis-header-structure-10]) containing a "/"-separated 196 sequence of names starting with the lowercase name of the response 197 header field that guards the response payload's integrity. The 198 meaning of subsequent names depends on the response header field, 199 but for the "digest" header field, the single following name is 200 the name of the digest algorithm that guards the payload's 201 integrity. 203 "cert-url" A string (Section 3.8 of 204 [I-D.ietf-httpbis-header-structure-10]) containing an absolute URL 205 (Section 2) with a scheme of "https" or "data". 207 "cert-sha256" Byte sequence (Section 3.10 of 208 [I-D.ietf-httpbis-header-structure-10]) holding the SHA-256 hash 209 of the first certificate found at "cert-url". 211 "validity-url" A string (Section 3.8 of 212 [I-D.ietf-httpbis-header-structure-10]) containing an absolute URL 213 (Section 2) with a scheme of "https". 215 "date" and "expires" An integer (Section 3.6 of 216 [I-D.ietf-httpbis-header-structure-10]) representing a Unix time. 218 The "cert-url" parameter is _not_ signed, so intermediates can update 219 it with a pointer to a cached version. 221 3.1.1. Examples 223 The following header is included in the response for an exchange with 224 effective request URI "https://example.com/resource.html". Newlines 225 are added for readability. 227 Signature: 228 sig1; 229 sig=*MEUCIQDXlI2gN3RNBlgFiuRNFpZXcDIaUpX6HIEwcZEc0cZYLAIga9DsVOMM+g5YpwEBdGW3sS+bvnmAJJiSMwhuBdqp5UY=*; 230 integrity="digest/mi-sha256-03"; 231 validity-url="https://example.com/resource.validity.1511128380"; 232 cert-url="https://example.com/oldcerts"; 233 cert-sha256=*W7uB969dFW3Mb5ZefPS9Tq5ZbH5iSmOILpjv2qEArmI=*; 234 date=1511128380; expires=1511733180 236 The signature uses a secp256r1 certificate within 237 "https://example.com/". 239 It relies on the "Digest" response header with the mi-sha256-03 240 digest algorithm to guard the integrity of the response payload. 242 The signature includes a "validity-url" that includes the first time 243 the resource was seen. This allows multiple versions of a resource 244 at the same URL to be updated with new signatures, which allows 245 clients to avoid transferring extra data while the old versions don't 246 have known security bugs. 248 The certificate at "https://example.com/certs" has a "subjectAltName" 249 of "example.com", meaning that if it and its signature validate, the 250 exchange can be trusted as having an origin of 251 "https://example.com/". 253 3.2. CBOR representation of exchange response headers 255 To sign an exchange's response headers, they need to be serialized 256 into a byte string. Since intermediaries and distributors might 257 rearrange, add, or just reserialize headers, we can't use the literal 258 bytes of the headers as this serialization. Instead, this section 259 defines a CBOR representation that can be embedded into other CBOR, 260 canonically serialized (Section 3.4), and then signed. 262 The CBOR representation of a set of response metadata and headers is 263 the CBOR ([RFC7049]) map with the following mappings: 265 o The byte string ':status' to the byte string containing the 266 response's 3-digit status code, and 268 o For each response header field, the header field's lowercase name 269 as a byte string to the header field's value as a byte string. 271 3.2.1. Example 273 Given the HTTP exchange: 275 GET / HTTP/1.1 276 Host: example.com 277 Accept: */* 279 HTTP/1.1 200 280 Content-Type: text/html 281 Digest: mi-sha256-03=dcRDgR2GM35DluAV13PzgnG6+pvQwPywfFvAu1UeFrs= 282 Signed-Headers: "content-type", "digest" 284 285 286 ... 288 The cbor representation consists of the following item, represented 289 using the extended diagnostic notation from [CDDL] appendix G: 291 { 292 'digest': 'mi-sha256-03=dcRDgR2GM35DluAV13PzgnG6+pvQwPywfFvAu1UeFrs=', 293 ':status': '200', 294 'content-type': 'text/html' 295 } 297 3.3. Loading a certificate chain 299 The resource at a signature's "cert-url" MUST have the "application/ 300 cert-chain+cbor" content type, MUST be canonically-encoded CBOR 301 (Section 3.4), and MUST match the following CDDL: 303 cert-chain = [ 304 "📜⛓", ; U+1F4DC U+26D3 305 + { 306 cert: bytes, 307 ? ocsp: bytes, 308 ? sct: bytes, 309 * tstr => any, 310 } 311 ] 313 The first map (second item) in the CBOR array is treated as the end- 314 entity certificate, and the client will attempt to build a path 315 ([RFC5280]) to it from a trusted root using the other certificates in 316 the chain. 318 1. Each "cert" value MUST be a DER-encoded X.509v3 certificate 319 ([RFC5280]). Other key/value pairs in the same array item define 320 properties of this certificate. 322 2. The first certificate's "ocsp" value MUST be a complete, DER- 323 encoded OCSP response for that certificate (using the ASN.1 type 324 "OCSPResponse" defined in [RFC6960]). Subsequent certificates 325 MUST NOT have an "ocsp" value. 327 3. Each certificate's "sct" value if any MUST be a 328 "SignedCertificateTimestampList" for that certificate as defined 329 by Section 3.3 of [RFC6962]. 331 Loading a "cert-url" takes a "forceFetch" flag. The client MUST: 333 1. Let "raw-chain" be the result of fetching ([FETCH]) "cert-url". 334 If "forceFetch" is _not_ set, the fetch can be fulfilled from a 335 cache using normal HTTP semantics [RFC7234]. If this fetch 336 fails, return "invalid". 338 2. Let "certificate-chain" be the array of certificates and 339 properties produced by parsing "raw-chain" using the CDDL above. 340 If any of the requirements above aren't satisfied, return 341 "invalid". Note that this validation requirement might be 342 impractical to completely achieve due to certificate validation 343 implementations that don't enforce DER encoding or other standard 344 constraints. 346 3. Return "certificate-chain". 348 3.4. Canonical CBOR serialization 350 Within this specification, the canonical serialization of a CBOR item 351 uses the following rules derived from Section 3.9 of [RFC7049] with 352 erratum 4964 applied: 354 o Integers and the lengths of arrays, maps, and strings MUST use the 355 smallest possible encoding. 357 o Items MUST NOT be encoded with indefinite length. 359 o The keys in every map MUST be sorted in the bytewise lexicographic 360 order of their canonical encodings. For example, the following 361 keys are correctly sorted: 363 1. 10, encoded as 0A. 365 2. 100, encoded as 18 64. 367 3. -1, encoded as 20. 369 4. "z", encoded as 61 7A. 371 5. "aa", encoded as 62 61 61. 373 6. [100], encoded as 81 18 64. 375 7. [-1], encoded as 81 20. 377 8. false, encoded as F4. 379 Note: this specification does not use floating point, tags, or other 380 more complex data types, so it doesn't need rules to canonicalize 381 those. 383 3.5. Signature validity 385 The client MUST parse the "Signature" header field as the 386 parameterised list (Section 4.2.5 of 387 [I-D.ietf-httpbis-header-structure-10]) described in Section 3.1. If 388 an error is thrown during this parsing or any of the requirements 389 described there aren't satisfied, the exchange has no valid 390 signatures. Otherwise, each member of this list represents a 391 signature with parameters. 393 The client MUST use the following algorithm to determine whether each 394 signature with parameters is invalid or potentially-valid for an 395 exchange's 397 o "requestUrl", a byte sequence that can be parsed into the 398 exchange's effective request URI (Section 5.5 of [RFC7230]), 400 o "responseHeaders", a byte sequence holding the canonical 401 serialization (Section 3.4) of the CBOR representation 402 (Section 3.2) of the exchange's response metadata and headers, and 404 o "payload", a stream of bytes constituting the exchange's payload 405 body (Section 3.3 of [RFC7230]). Note that the payload body is 406 the message body with any transfer encodings removed. 408 Potentially-valid results include: 410 o The signed headers of the exchange so that higher-level protocols 411 can avoid relying on unsigned headers, and 413 o Either a certificate chain or a public key so that a higher-level 414 protocol can determine whether it's actually valid. 416 This algorithm accepts a "forceFetch" flag that avoids the cache when 417 fetching URLs. A client that determines that a potentially-valid 418 certificate chain is actually invalid due to an expired OCSP response 419 MAY retry with "forceFetch" set to retrieve an updated OCSP from the 420 original server. 422 1. Let: 424 * "signature" be the signature (byte sequence in the 425 parameterised identifier's "sig" parameter). 427 * "integrity" be the signature's "integrity" parameter. 429 * "validity-url" be the signature's "validity-url" parameter. 431 * "cert-url" be the signature's "cert-url" parameter, if any. 433 * "cert-sha256" be the signature's "cert-sha256" parameter, if 434 any. 436 * "date" be the signature's "date" parameter, interpreted as a 437 Unix time. 439 * "expires" be the signature's "expires" parameter, interpreted 440 as a Unix time. 442 2. Set "publicKey" and "signing-alg" depending on which key fields 443 are present: 445 1. Assert: "cert-url" is present. 447 1. Let "certificate-chain" be the result of loading the 448 certificate chain at "cert-url" passing the "forceFetch" 449 flag (Section 3.3). If this returns "invalid", return 450 "invalid". 452 2. Let "main-certificate" be the first certificate in 453 "certificate-chain". 455 3. Set "publicKey" to "main-certificate"'s public key. 457 4. If "publicKey" is an RSA key, return "invalid". 459 5. If "publicKey" is a key using the secp256r1 elliptic 460 curve, set "signing-alg" to ecdsa_secp256r1_sha256 as 461 defined in Section 4.2.3 of [TLS1.3]. 463 6. Otherwise, return "invalid". 465 3. If "expires" is more than 7 days (604800 seconds) after "date", 466 return "invalid". 468 4. If the current time is before "date" or after "expires", return 469 "invalid". 471 5. Let "message" be the concatenation of the following byte 472 strings. This matches the [TLS1.3] format to avoid cross- 473 protocol attacks if anyone uses the same key in a TLS 474 certificate and an exchange-signing certificate. 476 1. A string that consists of octet 32 (0x20) repeated 64 times. 478 2. A context string: the ASCII encoding of "HTTP Exchange 1 479 b3". 481 Note: As this is a snapshot of a draft of 482 [I-D.yasskin-http-origin-signed-responses], it uses a 483 distinct context string. 485 3. A single 0 byte which serves as a separator. 487 4. If "cert-sha256" is set, a byte holding the value 32 488 followed by the 32 bytes of the value of "cert-sha256". 489 Otherwise a 0 byte. 491 5. The 8-byte big-endian encoding of the length in bytes of 492 "validity-url", followed by the bytes of "validity-url". 494 6. The 8-byte big-endian encoding of "date". 496 7. The 8-byte big-endian encoding of "expires". 498 8. The 8-byte big-endian encoding of the length in bytes of 499 "requestUrl", followed by the bytes of "requestUrl". 501 9. The 8-byte big-endian encoding of the length in bytes of 502 "responseHeaders", followed by the bytes of 503 "responseHeaders". 505 6. If "cert-url" is present and the SHA-256 hash of "main- 506 certificate"'s "cert_data" is not equal to "cert-sha256" (whose 507 presence was checked when the "Signature" header field was 508 parsed), return "invalid". 510 Note that this intentionally differs from TLS 1.3, which signs 511 the entire certificate chain in its Certificate Verify 512 (Section 4.4.3 of [TLS1.3]), in order to allow updating the 513 stapled OCSP response without updating signatures at the same 514 time. 516 7. If "signature" is not a valid signature of "message" by 517 "publicKey" using "signing-alg", return "invalid". 519 8. If "headers", interpreted according to Section 3.2, does not 520 contain a "Content-Type" response header field (Section 3.1.1.5 521 of [RFC7231]), return "invalid". 523 Clients MUST interpret the signed payload as this specified 524 media type instead of trying to sniff a media type from the 525 bytes of the payload, for example by attaching an "X-Content- 526 Type-Options: nosniff" header field ([FETCH]) to the extracted 527 response. 529 9. If "integrity" does not match "digest/mi-sha256-03", return 530 "invalid". 532 10. If "payload" doesn't match the integrity information in the 533 header described by "integrity", return "invalid". 535 11. Return "potentially-valid" with "certificate-chain". 537 Note that the above algorithm can determine that an exchange's 538 headers are potentially-valid before the exchange's payload is 539 received. Similarly, if "integrity" identifies a header field and 540 parameter like "Digest: mi-sha256-03" ([I-D.thomson-http-mice]) that 541 can incrementally validate the payload, early parts of the payload 542 can be determined to be potentially-valid before later parts of the 543 payload. Higher-level protocols MAY process parts of the exchange 544 that have been determined to be potentially-valid as soon as that 545 determination is made but MUST NOT process parts of the exchange that 546 are not yet potentially-valid. Similarly, as the higher-level 547 protocol determines that parts of the exchange are actually valid, 548 the client MAY process those parts of the exchange and MUST wait to 549 process other parts of the exchange until they too are determined to 550 be valid. 552 3.6. Updating signature validity 554 Both OCSP responses and signatures are designed to expire a short 555 time after they're signed, so that revoked certificates and signed 556 exchanges with known vulnerabilities are distrusted promptly. 558 This specification provides no way to update OCSP responses by 559 themselves. Instead, clients need to re-fetch the "cert-url" 560 (Section 3.5, Paragraph 6) to get a chain including a newer OCSP 561 response. 563 The "validity-url" parameter (Paragraph 5) of the signatures provides 564 a way to fetch new signatures or learn where to fetch a complete 565 updated exchange. 567 Each version of a signed exchange SHOULD have its own validity URLs, 568 since each version needs different signatures and becomes obsolete at 569 different times. 571 The resource at a "validity-url" is "validity data", a CBOR map 572 matching the following CDDL ([CDDL]): 574 validity = { 575 ? signatures: [ + bytes ] 576 ? update: { 577 ? size: uint, 578 } 579 ] 581 The elements of the "signatures" array are parameterised identifiers 582 (Section 4.2.6 of [I-D.ietf-httpbis-header-structure-10]) meant to 583 replace the signatures within the "Signature" header field pointing 584 to this validity data. If the signed exchange contains a bug severe 585 enough that clients need to stop using the content, the "signatures" 586 array MUST NOT be present. 588 If the the "update" map is present, that indicates that a new version 589 of the signed exchange is available at its effective request URI 590 (Section 5.5 of [RFC7230]) and can give an estimate of the size of 591 the updated exchange ("update.size"). If the signed exchange is 592 currently the most recent version, the "update" SHOULD NOT be 593 present. 595 If both the "signatures" and "update" fields are present, clients can 596 use the estimated size to decide whether to update the whole resource 597 or just its signatures. 599 3.6.1. Examples 601 For example, say a signed exchange whose URL is "https://example.com/ 602 resource" has the following "Signature" header field (with line 603 breaks included and irrelevant fields omitted for ease of reading). 605 Signature: 606 sig1; 607 sig=*MEUCIQ...*; 608 ... 609 validity-url="https://example.com/resource.validity.1511157180"; 610 cert-url="https://example.com/oldcerts"; 611 date=1511128380; expires=1511733180 613 At 2017-11-27 11:02 UTC, "sig1" has expired, so the client needs to 614 fetch "https://example.com/resource.validity.1511157180" (the 615 "validity-url" of "sig1") if it wishes to update that signature. 616 This URL might contain: 618 { 619 "signatures": [ 620 'sig1; ' 621 'sig=*MEQCIC/I9Q+7BZFP6cSDsWx43pBAL0ujTbON/+7RwKVk+ba5AiB3FSFLZqpzmDJ0NumNwN04pqgJZE99fcK86UjkPbj4jw==*; ' 622 'validity-url="https://example.com/resource.validity.1511157180"; ' 623 'integrity="digest/mi-sha256-03"; ' 624 'cert-url="https://example.com/newcerts"; ' 625 'cert-sha256=*J/lEm9kNRODdCmINbvitpvdYKNQ+YgBj99DlYp4fEXw=*; ' 626 'date=1511733180; expires=1512337980' 627 ], 628 "update": { 629 "size": 5557452 630 } 631 } 633 This indicates that the client could fetch a newer version at 634 "https://example.com/resource" (the original URL of the exchange), or 635 that the validity period of the old version can be extended by 636 replacing the original signature with the new signature provided. 637 The signature of the updated signed exchange would be: 639 Signature: 640 sig1; 641 sig=*MEQCIC...*; 642 ... 643 validity-url="https://example.com/resource.validity.1511157180"; 644 cert-url="https://example.com/newcerts"; 645 date=1511733180; expires=1512337980 647 3.7. The Accept-Signature header 649 The "Accept-Signature" request header is not used. 651 4. Cross-origin trust 653 To determine whether to trust a cross-origin exchange, the client 654 takes a "Signature" header field (Section 3.1) and the exchange's 656 o "requestUrl", a byte sequence that can be parsed into the 657 exchange's effective request URI (Section 5.5 of [RFC7230]), 659 o "responseHeaders", a byte sequence holding the canonical 660 serialization (Section 3.4) of the CBOR representation 661 (Section 3.2) of the exchange's response metadata and headers, and 663 o "payload", a stream of bytes constituting the exchange's payload 664 body (Section 3.3 of [RFC7230]). 666 The client MUST parse the "Signature" header into a list of 667 signatures according to the instructions in Section 3.5, and run the 668 following algorithm for each signature, stopping at the first one 669 that returns "valid". If any signature returns "valid", return 670 "valid". Otherwise, return "invalid". 672 1. If the signature's "validity-url" parameter (Paragraph 5) is not 673 same-origin [6] with "requestUrl", return "invalid". 675 2. Use Section 3.5 to determine the signature's validity for 676 "requestUrl", "responseHeaders", and "payload", getting 677 "certificate-chain" back. If this returned "invalid" or didn't 678 return a certificate chain, return "invalid". 680 3. Let "response" be the response metadata and headers parsed out of 681 "responseHeaders". 683 4. If Section 3 of [RFC7234] forbids a shared cache from storing 684 "response", return "invalid". 686 5. If "response"'s headers contain an uncached header field, as 687 defined in Section 4.1, return "invalid". 689 6. Let "authority" be the host component of "requestUrl". 691 7. Validate the "certificate-chain" using the following substeps. 692 If any of them fail, re-run Section 3.5 once over the signature 693 with the "forceFetch" flag set, and restart from step 2. If a 694 substep fails again, return "invalid". 696 1. Use "certificate-chain" to validate that its first entry, 697 "main-certificate" is trusted as "authority"'s server 698 certificate ([RFC5280] and other undocumented conventions). 699 Let "path" be the path that was used from the "main- 700 certificate" to a trusted root, including the "main- 701 certificate" but excluding the root. 703 2. Validate that "main-certificate" has the CanSignHttpExchanges 704 extension (Section 4.2). 706 3. Validate that either "main-certificate" has a Validity Period 707 no longer than 90 days, or that the current date is 708 2019-08-01 or before and "main-certificate" was issued on 709 2019-05-01 or before. 711 4. Validate that "main-certificate" has an "ocsp" property 712 (Section 3.3) with a valid OCSP response whose lifetime 713 ("nextUpdate - thisUpdate") is less than 7 days ([RFC6960]). 715 Note that this does not check for revocation of intermediate 716 certificates, and clients SHOULD implement another mechanism 717 for that. 719 5. Validate that valid SCTs from trusted logs are available from 720 any of: 722 + The "SignedCertificateTimestampList" in "main- 723 certificate"'s "sct" property (Section 3.3), 725 + An OCSP extension in the OCSP response in "main- 726 certificate"'s "ocsp" property, or 728 + An X.509 extension in the certificate in "main- 729 certificate"'s "cert" property, 731 as described by Section 3.3 of [RFC6962]. 733 8. Return "valid". 735 4.1. Uncached header fields 737 Hop-by-hop and other uncached headers MUST NOT appear in a signed 738 exchange. These will eventually be listed in 739 [I-D.ietf-httpbis-cache], but for now they're listed here: 741 o Hop-by-hop header fields listed in the Connection header field 742 (Section 6.1 of [RFC7230]). 744 o Header fields listed in the no-cache response directive in the 745 Cache-Control header field (Section 5.2.2.2 of [RFC7234]). 747 o Header fields defined as hop-by-hop: 749 * Connection 751 * Keep-Alive 753 * Proxy-Connection 755 * Trailer 757 * Transfer-Encoding 759 * Upgrade 761 o Stateful headers as defined below. 763 4.1.1. Stateful header fields 765 As described in Section 6.1 of 766 [I-D.yasskin-http-origin-signed-responses], a publisher can cause 767 problems if they sign an exchange that includes private information. 768 There's no way for a client to be sure an exchange does or does not 769 include private information, but header fields that store or convey 770 stored state in the client are a good sign. 772 A stateful response header field modifies state, including 773 authentication status, in the client. The HTTP cache is not 774 considered part of this state. These include but are not limited to: 776 o "Authentication-Control", [RFC8053] 778 o "Authentication-Info", [RFC7615] 780 o "Clear-Site-Data", [W3C.WD-clear-site-data-20171130] 782 o "Optional-WWW-Authenticate", [RFC8053] 784 o "Proxy-Authenticate", [RFC7235] 786 o "Proxy-Authentication-Info", [RFC7615] 788 o "Public-Key-Pins", [RFC7469] 790 o "Sec-WebSocket-Accept", [RFC6455] 792 o "Set-Cookie", [RFC6265] 794 o "Set-Cookie2", [RFC2965] 796 o "SetProfile", [W3C.NOTE-OPS-OverHTTP] 798 o "Strict-Transport-Security", [RFC6797] 800 o "WWW-Authenticate", [RFC7235] 802 4.2. Certificate Requirements 804 We define a new X.509 extension, CanSignHttpExchanges to be used in 805 the certificate when the certificate permits the usage of signed 806 exchanges. When this extension is not present the client MUST NOT 807 accept a signature from the certificate as proof that a signed 808 exchange is authoritative for a domain covered by the certificate. 809 When it is present, the client MUST follow the validation procedure 810 in Section 4. 812 CanSignHttpExchanges ::= NULL 814 Note that this extension contains an ASN.1 NULL (bytes "05 00") 815 because some implementations have bugs with empty extensions. 817 Leaf certificates without this extension need to be revoked if the 818 private key is exposed to an unauthorized entity, but they generally 819 don't need to be revoked if a signing oracle is exposed and then 820 removed. 822 CA certificates, by contrast, need to be revoked if an unauthorized 823 entity is able to make even one unauthorized signature. 825 Certificates with this extension MUST be revoked if an unauthorized 826 entity is able to make even one unauthorized signature. 828 Starting 2019-05-01, certificates with this extension MUST have a 829 Validity Period no greater than 90 days. 831 Conforming CAs MUST NOT mark this extension as critical. 833 Starting 2019-05-01, a conforming CA MUST NOT issue certificates with 834 this extension unless, for each dNSName in the subjectAltName 835 extension of the certificate to be issued: 837 1. An "issue" or "issuewild" CAA property ([RFC6844]) exists that 838 authorizes the CA to issue the certificate; and 840 2. The "cansignhttpexchanges" parameter (Section 4.2.1) is present 841 on the property and is equal to "yes" 843 Clients MUST NOT accept certificates with this extension in TLS 844 connections (Section 4.4.2.2 of [TLS1.3]). 846 This draft of the specification identifies the CanSignHttpExchanges 847 extension with the id-ce-canSignHttpExchangesDraft OID: 849 id-ce-google OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 11129 } 850 id-ce-canSignHttpExchangesDraft OBJECT IDENTIFIER ::= { id-ce-google 2 1 22 } 852 This OID might or might not be used as the final OID for the 853 extension, so certificates including it might need to be reissued 854 once the final RFC is published. 856 Some certificates have already been issued with this extension and 857 with validity periods longer than 90 days. These certificates will 858 not immediately be treated as invalid. Instead: 860 o Clients MUST reject certificates with this extension that were 861 issued after 2019-05-01 and have a Validity Period longer than 90 862 days. 864 o After 2019-08-01, clients MUST reject all certificates with this 865 extension that have a Validity Period longer than 90 days. 867 4.2.1. Extensions to the CAA Record: cansignhttpexchanges Parameter 869 A CAA parameter "cansignhttpexchanges" is defined for the "issue" and 870 "issuewild" properties defined by [RFC6844]. The value of this 871 parameter, if specified, MUST be "yes". 873 5. Transferring a signed exchange 875 A signed exchange can be transferred in several ways, of which three 876 are described here. 878 5.1. Same-origin response 880 Same-origin responses are not implemented. 882 5.2. HTTP/2 extension for cross-origin Server Push 884 Cross origin push is not implemented. 886 5.3. application/signed-exchange format 888 To allow signed exchanges to be the targets of "" 889 tags, we define the "application/signed-exchange" content type that 890 represents a signed HTTP exchange, including a request URL, response 891 metadata and header fields, and a response payload. 893 When served over HTTP, a response containing an "application/signed- 894 exchange" payload MUST include at least the following response header 895 fields, to reduce content sniffing vulnerabilities: 897 o Content-Type: application/signed-exchange;v=_version_ 899 o X-Content-Type-Options: nosniff 901 This content type consists of the concatenation of the following 902 items: 904 1. 8 bytes consisting of the ASCII characters "sxg1-b3" followed by 905 a 0 byte, to serve as a file signature. This is redundant with 906 the MIME type, and recipients that receive both MUST check that 907 they match and, if they don't, either stop parsing or redirect to 908 the "fallbackUrl" in the next two entries. 910 Note: As this is a snapshot of a draft of 911 [I-D.yasskin-http-origin-signed-responses], it uses a distinct 912 file signature. 914 2. 2 bytes storing a big-endian integer "fallbackUrlLength". 916 3. "fallbackUrlLength" bytes holding a "fallbackUrl", which MUST 917 UTF-8 decode to an absolute URL with a scheme of "https". 919 Note: The byte location of the fallback URL is intended to remain 920 invariant across versions of the "application/signed-exchange" 921 format so that parsers encountering unknown versions can always 922 find a URL to redirect to. 924 4. 3 bytes storing a big-endian integer "sigLength". If this is 925 larger than 16384 (16*1024), parsing MUST fail. 927 5. 3 bytes storing a big-endian integer "headerLength". If this is 928 larger than 524288 (512*1024), parsing MUST fail. 930 6. "sigLength" bytes holding the "Signature" header field's value 931 (Section 3.1). 933 7. "headerLength" bytes holding "signedHeaders", the canonical 934 serialization (Section 3.4) of the CBOR representation of the 935 response headers of the exchange represented by the "application/ 936 signed-exchange" resource (Section 3.2), excluding the 937 "Signature" header field. 939 8. The payload body (Section 3.3 of [RFC7230]) of the exchange 940 represented by the "application/signed-exchange" resource. 942 Note that the use of the payload body here means that a 943 "Transfer-Encoding" header field inside the "application/signed- 944 exchange" header block has no effect. A "Transfer-Encoding" 945 header field on the outer HTTP response that transfers this 946 resource still has its normal effect. 948 5.3.1. Cross-origin trust in application/signed-exchange 950 To determine whether to trust a cross-origin exchange stored in an 951 "application/signed-exchange" resource, pass the "Signature" header 952 field's value, "fallbackUrl" as the effective request URI, 953 "signedHeaders", and the payload body to the algorithm in Section 4. 955 5.3.2. Content negotiation 957 If the signed response headers include a "Variants-04" header field, 958 the client MUST use the cache behavior algorithm in Section 4 of 959 [I-D.ietf-httpbis-variants-05] to check that the signed response is 960 an appropriate representation for the request the client is trying to 961 fulfil. If the response is not an appropriate representation, the 962 client MUST treat the signature as invalid. Note the mismatch 963 between the name of the header field and the version of the Variants 964 draft. 966 5.3.3. Example 968 An example "application/signed-exchange" file representing a possible 969 signed exchange with https://example.com/ [7] follows, with lengths 970 represented by descriptions in "<>"s, CBOR represented in the 971 extended diagnostic format defined in Appendix G of [CDDL], and most 972 of the "Signature" header field and payload elided with a ...: 974 sxg1-b3\0<2-byte length of the following url string> 975 https://example.com/<3-byte length of the following header 976 value><3-byte length of the encoding of the 977 following map>sig1; sig=*...; integrity="digest/mi-sha256-03"; ...{ 978 ':status': '200', 979 'content-type': 'text/html' 980 }\r\n... 982 6. Security considerations 984 All of the security considerations from Section 6 of 985 [I-D.yasskin-http-origin-signed-responses] apply. 987 7. Privacy considerations 989 Normally, when a client fetches "https://o1.com/resource.js", 990 "o1.com" learns that the client is interested in the resource. If 991 "o1.com" signs "resource.js", "o2.com" serves it as "https://o2.com/ 992 o1resource.js", and the client fetches it from there, then "o2.com" 993 learns that the client is interested, and if the client executes the 994 Javascript, that could also report the client's interest back to 995 "o1.com". 997 Often, "o2.com" already knew about the client's interest, because 998 it's the entity that directed the client to "o1resource.js", but 999 there may be cases where this leaks extra information. 1001 For non-executable resource types, a signed response can improve the 1002 privacy situation by hiding the client's interest from the original 1003 publisher. 1005 To prevent network operators other than "o1.com" or "o2.com" from 1006 learning which exchanges were read, clients SHOULD only load 1007 exchanges fetched over a transport that's protected from 1008 eavesdroppers. This can be difficult to determine when the exchange 1009 is being loaded from local disk, but when the client itself requested 1010 the exchange over a network it SHOULD require TLS ([TLS1.3]) or a 1011 successor transport layer, and MUST NOT accept exchanges transferred 1012 over plain HTTP without TLS. 1014 8. IANA considerations 1016 This depends on the following IANA registrations in 1017 [I-D.yasskin-http-origin-signed-responses]: 1019 o The "Signature" header field 1021 o The application/cert-chain+cbor media type 1023 This document also modifies the registration for: 1025 8.1. Internet Media Type application/signed-exchange 1027 Type name: application 1029 Subtype name: signed-exchange 1031 Required parameters: 1033 o v: A string denoting the version of the file format. ([RFC5234] 1034 ABNF: "version = DIGIT/%x61-7A") The version defined in this 1035 specification is "b3". When used with the "Accept" header field 1036 (Section 5.3.1 of [RFC7231]), this parameter can be a comma 1037 (,)-separated list of version strings. ([RFC5234] ABNF: "version- 1038 list = version *( "," version )") The server is then expected to 1039 reply with a resource using a particular version from that list. 1041 Note: As this is a snapshot of a draft of 1042 [I-D.yasskin-http-origin-signed-responses], it uses a distinct 1043 version number. 1045 Magic number(s): 73 78 67 31 2D 62 33 00 1047 The other fields are the same as the registration in 1048 [I-D.yasskin-http-origin-signed-responses]. 1050 9. References 1052 9.1. Normative References 1054 [CDDL] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 1055 Definition Language (CDDL): A Notational Convention to 1056 Express Concise Binary Object Representation (CBOR) and 1057 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 1058 June 2019, . 1060 [FETCH] WHATWG, "Fetch", July 2019, 1061 . 1063 [I-D.ietf-httpbis-header-structure-10] 1064 Nottingham, M. and P. Kamp, "Structured Headers for HTTP", 1065 draft-ietf-httpbis-header-structure-10 (work in progress), 1066 April 2019, . 1069 [I-D.ietf-httpbis-variants-05] 1070 Nottingham, M., "HTTP Representation Variants", draft- 1071 ietf-httpbis-variants-05 (work in progress), March 2019, 1072 . 1074 [I-D.yasskin-http-origin-signed-responses] 1075 Yasskin, J., "Signed HTTP Exchanges", draft-yasskin-http- 1076 origin-signed-responses-06 (work in progress), July 2019. 1078 [POSIX] IEEE and The Open Group, "The Open Group Base 1079 Specifications Issue 7", name IEEE, value 1003.1-2008, 1080 2016 Edition, 2016, 1081 . 1084 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1085 Requirement Levels", BCP 14, RFC 2119, 1086 DOI 10.17487/RFC2119, March 1997, 1087 . 1089 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1090 Specifications: ABNF", STD 68, RFC 5234, 1091 DOI 10.17487/RFC5234, January 2008, 1092 . 1094 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1095 Housley, R., and W. Polk, "Internet X.509 Public Key 1096 Infrastructure Certificate and Certificate Revocation List 1097 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1098 . 1100 [RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification 1101 Authority Authorization (CAA) Resource Record", RFC 6844, 1102 DOI 10.17487/RFC6844, January 2013, 1103 . 1105 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 1106 Galperin, S., and C. Adams, "X.509 Internet Public Key 1107 Infrastructure Online Certificate Status Protocol - OCSP", 1108 RFC 6960, DOI 10.17487/RFC6960, June 2013, 1109 . 1111 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 1112 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 1113 . 1115 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1116 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1117 October 2013, . 1119 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1120 Protocol (HTTP/1.1): Message Syntax and Routing", 1121 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1122 . 1124 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1125 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1126 DOI 10.17487/RFC7231, June 2014, 1127 . 1129 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 1130 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 1131 RFC 7234, DOI 10.17487/RFC7234, June 2014, 1132 . 1134 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1135 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1136 May 2017, . 1138 [TLS1.3] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1139 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1140 . 1142 [URL] WHATWG, "URL", July 2019, . 1144 9.2. Informative References 1146 [I-D.ietf-httpbis-cache] 1147 Fielding, R., Nottingham, M., and J. Reschke, "HTTP 1148 Caching", draft-ietf-httpbis-cache-05 (work in progress), 1149 July 2019. 1151 [I-D.thomson-http-mice] 1152 Thomson, M. and J. Yasskin, "Merkle Integrity Content 1153 Encoding", draft-thomson-http-mice-03 (work in progress), 1154 August 2018. 1156 [I-D.yasskin-http-origin-signed-responses-03] 1157 Yasskin, J., "Signed HTTP Exchanges", draft-yasskin-http- 1158 origin-signed-responses-03 (work in progress), March 2018, 1159 . 1162 [I-D.yasskin-http-origin-signed-responses-04] 1163 Yasskin, J., "Signed HTTP Exchanges", draft-yasskin-http- 1164 origin-signed-responses-04 (work in progress), June 2018, 1165 . 1168 [I-D.yasskin-http-origin-signed-responses-05] 1169 Yasskin, J., "Signed HTTP Exchanges", draft-yasskin-http- 1170 origin-signed-responses-05 (work in progress), January 1171 2019, . 1174 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 1175 Mechanism", RFC 2965, DOI 10.17487/RFC2965, October 2000, 1176 . 1178 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1179 DOI 10.17487/RFC6265, April 2011, 1180 . 1182 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 1183 DOI 10.17487/RFC6454, December 2011, 1184 . 1186 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 1187 RFC 6455, DOI 10.17487/RFC6455, December 2011, 1188 . 1190 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 1191 Transport Security (HSTS)", RFC 6797, 1192 DOI 10.17487/RFC6797, November 2012, 1193 . 1195 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1196 Protocol (HTTP/1.1): Authentication", RFC 7235, 1197 DOI 10.17487/RFC7235, June 2014, 1198 . 1200 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 1201 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 1202 2015, . 1204 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1205 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1206 DOI 10.17487/RFC7540, May 2015, 1207 . 1209 [RFC7615] Reschke, J., "HTTP Authentication-Info and Proxy- 1210 Authentication-Info Response Header Fields", RFC 7615, 1211 DOI 10.17487/RFC7615, September 2015, 1212 . 1214 [RFC8053] Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi, 1215 T., and Y. Ioku, "HTTP Authentication Extensions for 1216 Interactive Clients", RFC 8053, DOI 10.17487/RFC8053, 1217 January 2017, . 1219 [W3C.NOTE-OPS-OverHTTP] 1220 Hensley, P., Metral, M., Shardanand, U., Converse, D., and 1221 M. Myers, "Implementation of OPS Over HTTP", W3C NOTE 1222 NOTE-OPS-OverHTTP, June 1997. 1224 [W3C.WD-clear-site-data-20171130] 1225 West, M., "Clear Site Data", World Wide Web Consortium WD 1226 WD-clear-site-data-20171130, November 2017, 1227 . 1229 9.3. URIs 1231 [1] https://lists.w3.org/Archives/Public/ietf-http-wg/ 1233 [2] https://github.com/WICG/webpackage 1235 [3] https://url.spec.whatwg.org/#concept-url-parser 1237 [4] https://url.spec.whatwg.org/#absolute-url-string 1239 [5] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/ 1240 V1_chap04.html#tag_04_16 1242 [6] https://html.spec.whatwg.org/multipage/origin.html#same-origin 1244 [7] https://example.com/ 1246 Appendix A. Change Log 1248 draft-03 1250 Vs. draft-02 1252 o Updates to match [I-D.yasskin-http-origin-signed-responses-05]. 1254 o UTF-8 decode the fallback URL. 1256 o Define a CAA parameter to opt into certificate issuance, which CAs 1257 need to enforce after May 1. 1259 o Limit lifetimes of certificates issued after May 1 to 90 days. 1261 o Accept-Signature and same-origin responses are removed. 1263 Vs. [I-D.yasskin-http-origin-signed-responses-05]: 1265 o Versions in file signatures and context strings are "b3". 1267 o Signed exchanges can only be transmitted in the application/ 1268 signed-exchange format, not HTTP/2 Push or plain HTTP request/ 1269 response pairs. 1271 o The Accept-Signature request header isn't used. 1273 o Removed non-normative sections. 1275 o Only 1 signature is supported. 1277 o Removed support for ed25519 signatures. 1279 o The above UTF-8 decoding. 1281 o The above CAA parameter and certificate lifetimes. 1283 o Versioned the Variants header field at draft-ietf-httpbis- 1284 variants-05 (but spelled Variants-04) and the mi-sha256 digest 1285 algorithm at draft-thomson-http-mice-03. 1287 o Allow mismatches between the MIME type and file signature to 1288 redirect to the fallback URL. 1290 draft-02 1292 Vs. draft-01: 1294 o Define absolute URLs, and limit the schemes each instance can use. 1296 o Update to mice-03 including the Digest header. 1298 o Define the "integrity" field of the Signature header to include 1299 the digest algorithm. 1301 o Put a fallback URL at the beginning of the "application/signed- 1302 exchange" format, and remove ':url' key from the CBOR 1303 representation of the exchange's request and response metadata and 1304 headers. 1306 o The new signed message format which embeds the exact bytes of the 1307 CBOR representation of the exchange's request and response 1308 metadata and headers. 1310 o When validating the signature validity, move the "payload" 1311 integrity check steps to after verifying "header". 1313 o Versions in file signatures and context strings are "b2". 1315 draft-01 1317 Vs. [I-D.yasskin-http-origin-signed-responses-04]: 1319 o The MI header and mi-sha256 content-encoding are renamed to MI- 1320 Draft2 and mi-sha256-draft2 in case [I-D.thomson-http-mice] 1321 changes. 1323 o Signed exchanges cannot be transmitted using HTTP/2 Push. 1325 o Removed non-normative sections. 1327 o The mi-sha256 encoding must have records <= 16kB. 1329 o The signature must be <=16kB long. 1331 o The HTTP request and response headers together must be <=512kB. 1333 o Versions in file signatures and context strings are "b1". 1335 o Only 1 signature is supported. 1337 o Removed support for ed25519 signatures. 1339 draft-00 1341 Vs. [I-D.yasskin-http-origin-signed-responses-03]: 1343 o Removed non-normative sections. 1345 o Only 1 signature is supported. 1347 o Only 2048-bit RSA keys are supported. 1349 o The certificate chain resource uses the TLS 1.3 Certificate 1350 message format rather than a CBOR-based format. 1352 o OCSP responses and SCTs are not checked. 1354 o Certificates without the CanSignHttpExchanges extension are 1355 allowed. 1357 o The signature string starts with 64 0x20 octets like the TLS 1.3 1358 signature format. 1360 o The application/http-exchange+cbor format is replaced with a more 1361 specialized application/signed-exchange format. 1363 o Signed exchanges can only be transmitted using the application/ 1364 signed-exchange format, not HTTP/2 Push or plain HTTP request/ 1365 response pairs. 1367 o Only the MI payload-integrity header is supported. 1369 o The mi-sha256 encoding must have records <= 16kB. 1371 o The Accept-Signature header isn't used. 1373 o Require absolute URLs. 1375 Appendix B. Acknowledgements 1377 Thanks to Andrew Ayer, Devin Mullins, Ilari Liusvaara, Justin Schuh, 1378 Mark Nottingham, Mike Bishop, Ryan Sleevi, and Yoav Weiss for 1379 comments that improved this draft. 1381 Authors' Addresses 1383 Jeffrey Yasskin 1384 Google 1386 Email: jyasskin@chromium.org 1388 Kouhei Ueno 1389 Google 1391 Email: kouhei@chromium.org