idnits 2.17.1 draft-yasskin-dispatch-web-packaging-00.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 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 30, 2017) is 2490 days in the past. Is this intentional? 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 752 -- Looks like a reference, but probably isn't: '2' on line 754 -- Looks like a reference, but probably isn't: '4' on line 756 == Unused Reference: 'HTML' is defined on line 680, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7049 (ref. 'CBOR') (Obsoleted by RFC 8949) == Outdated reference: A later version (-11) exists of draft-greevenbosch-appsawg-cbor-cddl-10 ** Downref: Normative reference to an Informational draft: draft-greevenbosch-appsawg-cbor-cddl (ref. 'CDDL') -- Possible downref: Non-RFC (?) normative reference: ref. 'HTML' ** Obsolete normative reference: RFC 7540 (ref. 'HTTP2') (Obsoleted by RFC 9113) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) -- Possible downref: Non-RFC (?) normative reference: ref. 'SRI' -- Obsolete informational reference (is this intentional?): RFC 7233 (Obsoleted by RFC 9110) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Dispatch J. Yasskin 3 Internet-Draft Google 4 Intended status: Standards Track June 30, 2017 5 Expires: January 1, 2018 7 Web Packaging 8 draft-yasskin-dispatch-web-packaging-00 10 Abstract 12 Web Packages provide a way to bundle up groups of web resources to 13 transmit them together. These bundles can then be signed to 14 establish their authenticity. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on January 1, 2018. 33 Copyright Notice 35 Copyright (c) 2017 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1.1. Offline Installation . . . . . . . . . . . . . . . . 3 53 1.1.2. Snapshot packages . . . . . . . . . . . . . . . . . . 3 54 1.1.3. CDNs . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1.4. ... . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.2. Why not ZIP? . . . . . . . . . . . . . . . . . . . . . . 3 57 1.3. The Need for Standardization . . . . . . . . . . . . . . 3 58 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Mode of specification . . . . . . . . . . . . . . . . . . 4 61 2.2. Top-level structure . . . . . . . . . . . . . . . . . . . 4 62 2.2.1. From the end . . . . . . . . . . . . . . . . . . . . 5 63 2.2.2. From the beginning . . . . . . . . . . . . . . . . . 5 64 2.3. Parsing the index . . . . . . . . . . . . . . . . . . . . 6 65 2.4. Parsing the manifest . . . . . . . . . . . . . . . . . . 7 66 2.4.1. Sub-packages . . . . . . . . . . . . . . . . . . . . 10 67 2.5. Parsing a resource . . . . . . . . . . . . . . . . . . . 11 68 3. Guidelines for package authors . . . . . . . . . . . . . . . 13 69 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 70 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 71 5.1. Internet Media Type Registration . . . . . . . . . . . . 14 72 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 6.1. Normative References . . . . . . . . . . . . . . . . . . 15 74 6.2. Informative References . . . . . . . . . . . . . . . . . 16 75 6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 17 76 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 79 1. Introduction 81 People would like to use content offline and in other situations 82 where there isn't a direct connection to the server where the content 83 originates. However, it's difficult to distribute and verify the 84 authenticity of applications and content without a connection to the 85 network. The W3C has addressed running applications offline with 86 Service Workers ([ServiceWorkers]), but not the problem of 87 distribution. 89 We've started work on this problem in , but we suspect that the IETF may be the right place to 91 standardize the overall format. More details can be found in that 92 repository. 94 1.1. Use Cases 96 1.1.1. Offline Installation 98 People with expensive or intermittent internet connections are used 99 to sharing files via P2P links and shared SD cards. They should be 100 able to install web applications they received this way. Installing 101 a web application requires a TLS-type guarantee that it came from and 102 can use data owned by a particular origin. 104 1.1.2. Snapshot packages 106 Verification of the origin of the content isn't always necessary. 107 For example, users currently share screenshots and MHTML documents 108 with their peers, with no guarantee that the shared content is 109 authentic. However, these formats have low fidelity (screenshots) 110 and/or aren't interoperable (MHTML). We'd like an interoperable 111 format that lets both publishers and readers package such content for 112 use in an untrusted mode. 114 1.1.3. CDNs 116 CDNs want to re-publish other origins' content so readers can access 117 it more quickly or more privately. Currently, to attribute that 118 content to the original origin, they need the full ability to publish 119 arbitrary content under that origin's name. There should be a way to 120 let them attribute only the exact content that the original origin 121 published. 123 1.1.4. ... 125 1.2. Why not ZIP? 127 WICG/webpackage#45 [1] 129 1.3. The Need for Standardization 131 Publishers and readers should be able to generate a package once, and 132 have it usable by all browsers. 134 1.4. Terminology 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 138 "OPTIONAL" in this document are to be interpreted as described in BCP 139 14 [RFC2119] [RFC8174] when, and only when, they appear in all 140 capitals, as shown here. 142 2. Format 144 2.1. Mode of specification 146 This specification defines how conformant web package parsers convert 147 a sequence of bytes into the semantics of a web package. It does not 148 constrain how web package encoders produce such a package: although 149 there are some guidelines in Section 3, encoders MAY produce any 150 sequence of bytes that a conformant parser would parse into the 151 intended semantics. 153 In places, this specification says the parser "MAY return" some data. 154 This indicates that the described data is complete enough that later 155 parsing failures do not need to discard it. 157 In places, this specification says the parser "MUST fail". The 158 parser MAY report these failures to its caller in any way, but MUST 159 NOT return any data it has parsed so far that wasn't mentioned in a 160 "MAY return" statement. 162 This specification creates local variables with the phrase "Let 163 _variable-name_ be ...". Use of a variable before it's created is a 164 defect in this specification. 166 2.2. Top-level structure 168 The package is roughly a CBOR item with the following CDDL schema, 169 but package parsers are required to successfully parse some byte 170 strings that aren't valid CBOR. For example, sections may have 171 padding between them, or even overlap, as long as the embedded 172 relative offsets cause the parsing algorithm in this specification to 173 return data. 175 webpackage = [ 176 magic1: h'F0 9F 8C 90 F0 9F 93 A6', ; 🌐📦 in UTF-8. 177 section-offsets: { * (($section-name .within tstr) => uint) }, 178 sections: [ *$section ], 179 length: uint, ; Total number of bytes in the package. 180 magic2: h'F0 9F 8C 90 F0 9F 93 A6', ; 🌐📦 in UTF-8. 181 ] 183 The parser MAY begin parsing at either the beginning (Section 2.2.2) 184 or end (Section 2.2.1) of the byte string representing the package. 185 Parsing from the end is useful when the package is embedded in 186 another format such as a self-extracting executable, while parsing 187 from the beginning is useful when loading from a stream. 189 2.2.1. From the end 191 To parse from the end, the parser MUST load the last 18 bytes as the 192 following [CDDL] group in array context: [ednote-loading-cddl] 194 tail = ( 195 length: uint, ; Total number of bytes in the package. 196 magic2: h'F0 9F 8C 90 F0 9F 93 A6', ; 🌐📦 in UTF-8. 197 ) 199 If the bytes don't match this group or these two CBOR items don't 200 occupy exactly 18 bytes, parsing MUST fail. 202 Otherwise, continue as if the byte "length" bytes before the end of 203 the string were the beginning of the package, and the parser were a 204 from the beginning (Section 2.2.2) parser. 206 2.2.2. From the beginning 208 If the first 10 bytes of the package are not "85 48 F0 9F 8C 90 F0 9F 209 93 A6" (the CBOR encoding of the 5-item array header and 8-byte 210 bytestring header, followed by 🌐📦 in UTF-8), parsing 211 MUST fail. 213 Parse one CBOR item starting at the 11th byte of the package. If 214 this does not match the CDDL 216 section-offsets = { * tstr => uint }, 218 or it is not a Canonical CBOR item (Section 3.9 of [CBOR]), parsing 219 MUST fail. 221 Let _sections-start_ be the offset of the byte after the "section- 222 offsets" item. For example, if "section-offsets" were 52 bytes long, 223 _sections-start_ would be 63. 225 This specification defines two section names: "indexed-content" and 226 "manifest". 228 If "section-offsets"["indexed-content"] is not present, parsing MUST 229 fail. 231 The parser MUST ignore unknown keys in the "section-offsets" map 232 because new sections may be defined in future specifications. 233 [ednote-critical-sections] 234 Let _index_ be the result of parsing the bytes starting at offset 235 _sections-start_ + "section-offsets"["indexed-content"] using the 236 instructions in Section 2.3. 238 If "section-offsets"["manifest"] is present, let _manifest_ be the 239 result of parsing the bytes starting at offset _sections-start_ + 240 "section-offsets"["manifest"] using the instructions in Section 2.4. 242 The parser MAY return a semantic package consisting of _index_, and, 243 if initialized, _manifest_. 245 To parse each resource described within _index_, the parser MUST 246 follow the instructions in Section 2.5. 248 2.3. Parsing the index 250 The main content of a package is an index of HTTP requests pointing 251 to HTTP responses. These request/response pairs hold the manifests 252 of sub-packages and the resources in the package and all of its sub- 253 packages. Both the requests and responses can appear in any order, 254 usually chosen to optimize loading while the package is streamed. 256 To parse the index, starting at offset _index-start_, the parser MUST 257 do the following: 259 If the byte at _index-start_ is not 0x82 (the [CBOR] header for a 260 2-element array), the parser MUST fail. 262 Load a CBOR item starting at _index-start_ + 1 as the "index" array 263 in the following CDDL: 265 $section-name /= "indexed-content" 266 $section /= index 268 index = [* [resource-key: http-headers, 269 offset: uint, 270 ? length: uint] ] 272 ; http-headers is a byte string in HPACK format (RFC7541). 273 ; The dynamic table begins empty for each instance of 274 ; http-headers. 275 http-headers = bstr 277 If the item doesn't match this CDDL, or it is not a Canonical CBOR 278 item (Section 3.9 of [CBOR]), the parser MUST fail. 280 Let _resources-start_ be the offset immediately after the "index" 281 item. For example, if _index-start_ were 75 and the "index" item 282 were 105 bytes long, _resources-start_ would be 75+1+105=181. (1 for 283 the 0x82 array header.) 285 Decode all of the "resource-key"s using [HPACK], with an initially- 286 empty dynamic table for each one. [ednote-compression] The decoded 287 "resource-key"s are header lists ([HPACK], Section 1.3), ordered 288 lists of name-value pairs. 290 The parser MUST fail if any of the following is true: 292 1. HPACK decoding encountered an error. 294 2. Any "resource-key"'s first three headers are not named ":scheme", 295 ":authority", and ":path", in that order. Note that ":method" is 296 intentionally omitted because only the GET method is meaningful. 298 3. Any of the pseudo-headers' values violates a requirement in 299 Section 8.1.2.3 of [HTTP2]. 301 4. Any "resource-key" has a non-pseudo-header name that includes the 302 ":" character or is not lower-case ascii ([HTTP2], 303 Section 8.1.2). 305 5. Any two decoded "resource-key"s are the same. Note that header 306 lists with the same header fields in a different order are not 307 the same. 309 Increment all "offset"s by _resources-start_. 311 Return the resulting "index", an array of decoded-resource-key, 312 adjusted-offset, and optional-length triples. 314 The optional "length" field in the index entries is redundant with 315 the length prefixes on the "response-headers" and "body" in the 316 content, but it can be used to issue Range requests [RFC7233] for 317 responses that appear late in the content. 319 2.4. Parsing the manifest 321 A package's manifest contains some metadata for the package; hashes, 322 used in Section 2.5, Paragraph 9, for all resources included in that 323 package; and validity information for any sub-packages 324 (Section 2.4.1) the package depends on. The manifest is signed, so 325 that UAs can trust that it comes from its claimed origin. [ednote- 326 manifest-name] 328 To parse a manifest starting at _manifest-start_, a parser MUST do 329 the following: 331 Load one CBOR item starting at _manifest-start_ as a "signed- 332 manifest" from the following CDDL: 334 $section-name /= "manifest" 335 $section /= signed-manifest 337 signed-manifest = { 338 manifest: manifest, 339 certificates: [+ certificate], 340 signatures: [+ signature] 341 } 343 manifest = { 344 metadata: manifest-metadata, 345 resource-hashes: {* hash-algorithm => [hash-value]}, 346 ? subpackages: [* subpackage], 347 } 349 manifest-metadata = { 350 date: time, 351 origin: uri, 352 * tstr => any, 353 } 355 ; From https://www.w3.org/TR/CSP3/#grammardef-hash-algorithm. 356 hash-algorithm /= "sha256" / "sha384" / "sha512" 357 ; Note that a hash value is not base64-encoded, unlike in CSP. 358 hash-value = bstr 360 ; X.509 format; see https://tools.ietf.org/html/rfc5280 361 certificate = bstr 363 signature = { 364 ; This is the index of the certificate within the certificates array to use 365 ; to validate the signature. 366 keyIndex: uint, 367 signature: bstr, 368 } 370 If the item doesn't match the CDDL or it's not a Canonical CBOR item 371 (Section 3.9 of [CBOR]), parsing MUST fail. 373 Parse the elements of "certificates" as X.509 certificates within the 374 [RFC5280] profile. If any certificate fails to parse, parsing MUST 375 fail. 377 Let _message_ be the concatenation of the following byte strings. 378 This matches the [TLS1.3] format to avoid cross-protocol attacks when 379 TLS certificates are used to sign manifests. 381 1. A string that consists of octet 32 (0x20) repeated 64 times. 383 2. A context string: the ASCII encoding of "Web Package Manifest". 385 3. A single 0 byte which serves as a separator. 387 4. The bytes of the "manifest" CBOR item. 389 Let _signing-certificates_ be an empty array. 391 For each element _signature_ of "signatures": 393 1. Let _certificate_ be "certificates"[_signature_["keyIndex"]]. 395 2. The parser MUST define a partial function from public key types 396 to signing algorithms, with the following map as a subset: 398 RSA, 2048 bits: rsa_pss_sha256 as defined in Section 4.2.3 of 399 [TLS1.3] 401 EC, with the secp256r1 curve: ecdsa_secp256r1_sha256 as defined 402 in Section 4.2.3 of [TLS1.3] 404 EC, with the secp384r1 curve: ecdsa_secp384r1_sha384 as defined 405 in Section 4.2.3 of [TLS1.3] 407 Let _signing-alg_ be the result of applying this function to the 408 key type in _certificate_'s Subject Public Key Info. If the 409 function is undefined on this input, the parser MUST continue to 410 the next _signature_. 412 3. Use _signing-alg_ to verify that _signature_["signature"] is 413 _message_'s signature by _certificate_'s public key. If it's 414 not, the parser MUST continue to the next _signature_. 416 4. Append _certificate_ to _signing-certificates_. Note that failed 417 signatures simply cause their certificate to be ignored, so that 418 packagers can give new signature types to parsers that understand 419 them. 421 Let _origin_ be "manifest"["metadata"]["origin"]. 423 Try to find a certificate in _signing-certificates_ that has an 424 identity ([RFC2818], Section 3.1) matching _origin_'s hostname, and 425 that is trusted for serverAuth ([RFC5280], Section 4.2.1.12) using 426 paths built from elements of "certificates" or any other certificates 427 the parser is aware of. If no such certificate is found, and the 428 package is not already trusted as received from _origin_'s hostname, 429 for example because it was received over a TLS connection to that 430 host, then parsing MUST fail. 432 *TODO:* Process the "subpackages" item by fetching those manifests 433 via the index, and checking their signatures and dates/hashes, 434 recursively. 436 The parsed manifest consists of the set of _signing-certificates_ and 437 the "manifest" CBOR item. The items in "manifest"["metadata"] SHOULD 438 be interpreted as described in the [appmanifest] specification. 440 2.4.1. Sub-packages 442 A sub-package is represented by a Section 2.4 file looked up as a 443 Section 2.5 within the "indexed-content" section. The sub-package's 444 resources are not otherwise distinguished from the rest of the 445 resources in the package. Sub-packages can form an arbitrarily-deep 446 tree. 448 There are three possible forms of dependencies on sub-packages, of 449 which we allow two. Because a sub-package's manifest is protected by 450 its own signature, if the main package trusts the sub-package's 451 server, it could avoid specifying a version of the sub-package at 452 all. However, this opens the main package up to downgrade attacks, 453 where the sub-package is replaced by an older, vulnerable version, so 454 we don't allow this option. 456 subpackage = [ 457 resource: resource-key, 458 validation: { 459 ? hash: {+ hash-algorithm => hash-value}, 460 ? notbefore: time, 461 } 462 ] 464 If the main package wants to load either the sub-package it was built 465 with or any upgrade, it can specify the date of the original sub- 466 package: 468 [32("https://example.com/loginsdk.package"), {"notbefore": 1(1486429554)}] 470 Constraining packages with their date makes it possible to link 471 together sub-packages with common dependencies, even if the sub- 472 packages were built at different times. 474 If the main package wants to be certain it's loading the exact 475 version of a sub-package that it was built with, it can constrain 476 sub-package with a hash of its manifest: 478 [32("https://example.com/loginsdk.package"), 479 {"hash": {"sha256": b64'9qg0NGDuhsjeGwrcbaxMKZAvfzAHJ2d8L7NkDzXhgHk='}}] 481 Note that because the sub-package may include sub-sub-packages by 482 date, the top package may need to explicitly list those sub-sub- 483 packages' hashes in order to be completely constrained. 485 2.5. Parsing a resource 487 To parse the resource from a _package_ corresponding to a _header- 488 list_, a parser MUST do the following: 490 Find the (_resource-key_, _offset_, _length_) triple in _package_'s 491 index where _resource-key_ is the same as _header-list_. If no such 492 triple exists, the parser MUST fail. 494 Parse one CBOR item starting at _offset_ as the following CDDL: 496 response = [response-headers: http-headers, body: bstr] 498 If the item doesn't match the CDDL or it's not a Canonical CBOR item 499 (Section 3.9 of [CBOR]), parsing MUST fail. 501 Decode the "response-headers" field using [HPACK], with an initially- 502 empty dynamic table. The decoded "response-headers" is a header list 503 ([HPACK], Section 1.3), an ordered list of name-value pairs. 505 The parser MUST fail if any of the following is true: 507 1. HPACK decoding encountered an error. 509 2. The first header name within "response-headers" is not ":status", 510 or this pseudo-header's value violates a requirement in 511 Section 8.1.2.3 of [HTTP2]. 513 3. Any other header name includes the ":" character or is not lower- 514 case ascii ([HTTP2], Section 8.1.2). 516 4. The _header-list_ contains any header names other than ":scheme", 517 ":authority", ":path", and either "response-headers" has no 518 "vary" header (Section 7.1.4 of [RFC7231]) or these header names 519 aren't listed in it. 521 Let _origin_ be the Web Origin [RFC6454] of _header-list_'s ":scheme" 522 and ":authority" headers. 524 Let _resource-bytes_ be the result of encoding the array of [_header- 525 list_, "response-headers", "body"] as Canonical CBOR in the following 526 CDDL schema: [ednote-figure-in-list] 528 resource-bytes = [ 529 request: [ 530 *(header-name: bstr, header-value: bstr) 531 ], 532 response-headers: [ 533 *(header-name: bstr, header-value: bstr) 534 ], 535 response-body: bstr 536 ] 538 Note that this uses the decoded header fields, not the bytes 539 originally included in the package. 541 The hashed data differs from [SRI], which only hashes the body. 542 Including the headers will usually prevent a package from relying on 543 some of its contents being transferred as normal network responses, 544 unless its author can guarantee the network won't change or reorder 545 the headers. 547 If the _package_ contains a _manifest_: 549 1. *TODO:* Let _origin-manifest_ be the signed manifest for 550 _origin_, found by searching through _manifest_'s subpackages for 551 a matching origin. 553 2. Let _alg_ be one of the "hash-algorithm"s within _origin- 554 manifest_. The parser SHOULD select the most collision-resistant 555 hash algorithm. If the parser also implements [SRI], it SHOULD 556 use the same order as its "getPrioritizedHashFunction()" 557 implementation. 559 3. If the digest of _resource-bytes_ using _alg_ does not appear in 560 the _origin-manifest_'s "resource-hashes"[_alg_] array, the 561 parser MUST fail. 563 Return the (decoded "response-headers", "body") pair. 565 3. Guidelines for package authors 567 Packages SHOULD consist of a single Canonical CBOR item matching the 568 "webpackage" CDDL rule in Section 2.2. 570 Every resource's hash SHOULD appear in every array within "resource- 571 hashes": otherwise the set of valid resources will depend on the 572 parser's choice of preferred hash algorithm. 574 4. Security Considerations 576 Signature validation is difficult. 578 Packages with a valid signature need to be invalidated when either 580 o the private key for any certificate in the signature's validation 581 chain is leaked, or 583 o a vulnerability is discovered in the package's contents. 585 Because packages are intended to be used offline, it's impossible to 586 inject a revocation check into the critical path of using the 587 package, and even in online scenarios, such revocation checks don't 588 actually work [2]. Instead, package consumers must check for a 589 sufficiently recent set of validation files, consisting of OCSP 590 responses [RFC6960] and signed package version constraints, for 591 example within the last 7-30 days. *TODO:* These version constraints 592 aren't designed yet. 594 Relaxing the requirement to consult DNS when determining authority 595 for an origin means that an attacker who possesses a valid 596 certificate no longer needs to be on-path to redirect traffic to 597 them; instead of modifying DNS, they need only convince the user to 598 visit another Web site, in order to serve packages signed as the 599 target. 601 All subpackages that mention a particular origin need to be validated 602 before loading resources from that origin. Otherwise, package A 603 could include package B and an old, vulnerable version of package C 604 that B also depends on. If B's dependency isn't checked before 605 loading resources from C, A could compromise B. 607 5. IANA considerations 608 5.1. Internet Media Type Registration 610 IANA maintains the registry of Internet Media Types [RFC6838] at 611 https://www.iana.org/assignments/media-types. 613 o Type name: application 615 o Subtype name: package+cbor [ednote-mime-naming] 617 o Required parameters: N/A 619 o Optional parameters: N/A 621 o Encoding considerations: binary 623 o Security considerations: See Section 4 of this document. 625 o Interoperability considerations: N/A 627 o Published specification: This document 629 o Applications that use this media type: None yet, but it is 630 expected that web browsers will use this format. 632 o Fragment identifier considerations: N/A 634 o Additional information: 636 * Deprecated alias names for this type: N/A 638 * Magic number(s): 85 48 F0 9F 8C 90 F0 9F 93 A6 640 * File extension(s): .wpk 642 * Macintosh file type code(s): N/A 644 o Person & email address to contact for further information: See the 645 Author's Address section of this specification. 647 o Intended usage: COMMON 649 o Restrictions on usage: N/A 651 o Author: See the Author's Address section of this specification. 653 o Change controller: The IESG iesg@ietf.org [4] 655 o Provisional registration? (standards tree only): Not yet. 657 6. References 659 6.1. Normative References 661 [appmanifest] 662 Caceres, M., Christiansen, K., Lamouri, M., and A. 663 Kostiainen, "Web App Manifest", World Wide Web Consortium 664 WD WD-appmanifest-20170608, June 2017, 665 . 667 [CBOR] Bormann, C. and P. Hoffman, "Concise Binary Object 668 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 669 October 2013, . 671 [CDDL] Birkholz, H., Vigano, C., and C. Bormann, "CBOR data 672 definition language (CDDL): a notational convention to 673 express CBOR data structures", draft-greevenbosch-appsawg- 674 cbor-cddl-10 (work in progress), March 2017. 676 [HPACK] Peon, R. and H. Ruellan, "HPACK: Header Compression for 677 HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, 678 . 680 [HTML] WHATWG, "HTML", n.d., . 683 [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 684 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 685 DOI 10.17487/RFC7540, May 2015, 686 . 688 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 689 Requirement Levels", BCP 14, RFC 2119, 690 DOI 10.17487/RFC2119, March 1997, 691 . 693 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 694 DOI 10.17487/RFC2818, May 2000, 695 . 697 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 698 Housley, R., and W. Polk, "Internet X.509 Public Key 699 Infrastructure Certificate and Certificate Revocation List 700 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 701 . 703 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 704 DOI 10.17487/RFC6454, December 2011, 705 . 707 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 708 Galperin, S., and C. Adams, "X.509 Internet Public Key 709 Infrastructure Online Certificate Status Protocol - OCSP", 710 RFC 6960, DOI 10.17487/RFC6960, June 2013, 711 . 713 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 714 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 715 DOI 10.17487/RFC7231, June 2014, 716 . 718 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 719 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 720 May 2017, . 722 [SRI] Akhawe, D., Braun, F., Marier, F., and J. Weinberger, 723 "Subresource Integrity", World Wide Web Consortium 724 Recommendation REC-SRI-20160623, June 2016, 725 . 727 [TLS1.3] Rescorla, E., "The Transport Layer Security (TLS) Protocol 728 Version 1.3", draft-ietf-tls-tls13-20 (work in progress), 729 April 2017. 731 6.2. Informative References 733 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 734 Specifications and Registration Procedures", BCP 13, 735 RFC 6838, DOI 10.17487/RFC6838, January 2013, 736 . 738 [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 739 "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", 740 RFC 7233, DOI 10.17487/RFC7233, June 2014, 741 . 743 [ServiceWorkers] 744 Russell, A., Song, J., Archibald, J., and M. 745 Kruisselbrink, "Service Workers 1", World Wide Web 746 Consortium WD WD-service-workers-1-20161011, October 2016, 747 . 750 6.3. URIs 752 [1] https://github.com/WICG/webpackage/issues/45 754 [2] https://www.imperialviolet.org/2012/02/05/crlsets.html 756 [4] mailto:iesg@ietf.org 758 Appendix A. Acknowledgements 760 Thanks to Adam Langley and Ryan Sleevi for in-depth feedback about 761 the security impact of this proposal. 763 Editorial Comments 765 [ednote-loading-cddl] jyasskin: CDDL doesn't actually define how to use 766 it as a schema to load CBOR data. 768 [ednote-critical-sections] jyasskin: Do we need to mark critical section 769 names? 771 [ednote-compression] jyasskin: This spec has different security 772 constraints from the ones that drove HPACK, so we 773 may be able to do better with another compression 774 format. 776 [ednote-manifest-name] jyasskin: This section doesn't describe a 777 manifest (https://www.merriam- 778 webster.com/dictionary/manifest#h3), so consider 779 renaming it to something like "authenticity". 781 [ednote-figure-in-list] jyasskin: This step would be inside the 782 manifest-only block, but then the code block is 783 rendered out-of-order. 785 [ednote-mime-naming] jyasskin: I suspect the mime type will need to be a 786 bit longer: application/webpackage+cbor or similar. 788 Author's Address 790 Jeffrey Yasskin 791 Google 793 Email: jyasskin@chromium.org