idnits 2.17.1 draft-yasskin-webpackage-use-cases-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 30, 2017) is 2403 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '3' on line 726 -- Looks like a reference, but probably isn't: '4' on line 729 -- Looks like a reference, but probably isn't: '5' on line 731 -- Looks like a reference, but probably isn't: '6' on line 733 -- Looks like a reference, but probably isn't: '7' on line 735 -- Looks like a reference, but probably isn't: '8' on line 737 -- Looks like a reference, but probably isn't: '9' on line 739 -- Looks like a reference, but probably isn't: '10' on line 741 -- Looks like a reference, but probably isn't: '11' on line 743 -- Looks like a reference, but probably isn't: '12' on line 745 -- Looks like a reference, but probably isn't: '13' on line 747 -- Looks like a reference, but probably isn't: '14' on line 750 -- Looks like a reference, but probably isn't: '15' on line 753 -- Looks like a reference, but probably isn't: '16' on line 756 -- Looks like a reference, but probably isn't: '17' on line 758 -- Looks like a reference, but probably isn't: '18' on line 761 -- Looks like a reference, but probably isn't: '19' on line 633 -- Looks like a reference, but probably isn't: '20' on line 638 -- Looks like a reference, but probably isn't: '1' on line 722 -- Looks like a reference, but probably isn't: '2' on line 724 == Outdated reference: A later version (-12) exists of draft-cavage-http-signatures-07 -- Obsolete informational reference (is this intentional?): RFC 6962 (Obsoleted by RFC 9162) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 23 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: Informational August 30, 2017 5 Expires: March 3, 2018 7 Use Cases and Requirements for Web Packages 8 draft-yasskin-webpackage-use-cases-00 10 Abstract 12 This document lists use cases for signing and/or bundling collections 13 of web pages, and extracts a set of requirements from them. 15 Note to Readers 17 Discussion of this draft takes place on the ART area mailing list 18 (art@ietf.org), which is archived at 19 https://mailarchive.ietf.org/arch/search/?email_list=art. 21 The source code and issues list for this draft can be found in 22 https://github.com/WICG/webpackage. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 3, 2018. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Essential . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1.1. Offline installation . . . . . . . . . . . . . . . . 3 62 2.1.2. Offline browsing . . . . . . . . . . . . . . . . . . 5 63 2.1.3. Save and share a web page . . . . . . . . . . . . . . 5 64 2.2. Nice-to-have . . . . . . . . . . . . . . . . . . . . . . 6 65 2.2.1. Packaged Web Publications . . . . . . . . . . . . . . 6 66 2.2.2. Third-party security review . . . . . . . . . . . . . 7 67 2.2.3. Building packages from multiple libraries . . . . . . 7 68 2.2.4. CDNs . . . . . . . . . . . . . . . . . . . . . . . . 8 69 2.2.5. Installation from a self-extracting executable . . . 8 70 2.2.6. Ergonomic replacement for HTTP/2 PUSH . . . . . . . . 9 71 2.2.7. Packages in version control . . . . . . . . . . . . . 9 72 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 9 73 3.1. Essential . . . . . . . . . . . . . . . . . . . . . . . . 10 74 3.1.1. Indexed by URL . . . . . . . . . . . . . . . . . . . 10 75 3.1.2. Request headers . . . . . . . . . . . . . . . . . . . 10 76 3.1.3. Response headers . . . . . . . . . . . . . . . . . . 10 77 3.1.4. Signing as an origin . . . . . . . . . . . . . . . . 10 78 3.1.5. Random access . . . . . . . . . . . . . . . . . . . . 11 79 3.1.6. Resources from multiple origins in a package . . . . 11 80 3.1.7. Cryptographic agility . . . . . . . . . . . . . . . . 11 81 3.1.8. Unsigned content . . . . . . . . . . . . . . . . . . 11 82 3.1.9. Certificate revocation . . . . . . . . . . . . . . . 11 83 3.1.10. Downgrade prevention . . . . . . . . . . . . . . . . 11 84 3.1.11. Metadata . . . . . . . . . . . . . . . . . . . . . . 11 85 3.1.12. Implementations are hard to get wrong . . . . . . . . 12 86 3.2. Nice to have . . . . . . . . . . . . . . . . . . . . . . 12 87 3.2.1. Streamed loading . . . . . . . . . . . . . . . . . . 12 88 3.2.2. Cross-signatures . . . . . . . . . . . . . . . . . . 12 89 3.2.3. Binary . . . . . . . . . . . . . . . . . . . . . . . 12 90 3.2.4. Deduplication of diamond dependencies . . . . . . . . 12 91 3.2.5. Old crypto can be removed . . . . . . . . . . . . . . 12 92 3.2.6. Compress transfers . . . . . . . . . . . . . . . . . 13 93 3.2.7. Compress stored packages . . . . . . . . . . . . . . 13 94 3.2.8. Subsetting and reordering . . . . . . . . . . . . . . 13 95 3.2.9. Packaged validity information . . . . . . . . . . . . 13 96 3.2.10. Signing uses existing TLS certificates . . . . . . . 13 97 3.2.11. External dependencies . . . . . . . . . . . . . . . . 13 98 3.2.12. Trailing length . . . . . . . . . . . . . . . . . . . 13 99 4. Non-goals . . . . . . . . . . . . . . . . . . . . . . . . . . 13 100 4.1. Store confidential data . . . . . . . . . . . . . . . . . 14 101 4.2. Generate packages on the fly . . . . . . . . . . . . . . 14 102 4.3. Non-origin identity . . . . . . . . . . . . . . . . . . . 14 103 4.4. DRM . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 104 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 105 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 106 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 107 7.1. Informative References . . . . . . . . . . . . . . . . . 15 108 7.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 16 109 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17 110 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 112 1. Introduction 114 People would like to use content offline and in other situations 115 where there isn't a direct connection to the server where the content 116 originates. However, it's difficult to distribute and verify the 117 authenticity of applications and content without a connection to the 118 network. The W3C has addressed running applications offline with 119 Service Workers ([ServiceWorkers]), but not the problem of 120 distribution. 122 Previous attempts at packaging web resources (e.g. Resource Packages 123 [3] and the W3C TAG's packaging proposal [4]) were motivated by 124 speeding up the download of resources from a single server, which is 125 probably better achieved through other mechanisms like HTTP/2 PUSH, 126 possibly augmented with a simple manifest of URLs a page plans to use 127 [5]. This attempt is instead motivated by avoiding a connection to 128 the origin server at all. It may still be useful for the earlier use 129 cases, so they're still listed, but they're not primary. 131 2. Use cases 133 These use cases are in rough descending priority order. If use cases 134 have conflicting requirements, the design should enable more 135 important use cases. 137 2.1. Essential 139 2.1.1. Offline installation 141 Alex can download a file containing a website (a PWA [6]) including a 142 Service Worker from origin "O", and transmit it to their peer Bailey, 143 and then Bailey can install the Service Worker with a proof that it 144 came from "O". This saves Bailey the bandwidth costs of transferring 145 the website. 147 Associated requirements: 149 o Indexed by URL: Resources on the web are addressed by URL. 151 o Request headers: If Bailey's running a different browser from Alex 152 or has a different language configured, the "accept*" headers are 153 important for selecting which resource to use at each URL. 155 o Response headers: The meaning of a resource is heavily influenced 156 by its HTTP response headers. 158 o Signing as an origin: To prove that the file came from "O". 160 o Signing uses existing TLS certificates: So "O" doesn't have to 161 spend lots of money buying a specialized certificate. 163 o Resources from multiple origins in a package: So the site can be 164 built from multiple components (Section 2.2.3). 166 o Cryptographic agility: Today's algorithms will eventually be 167 obsolete and will need to be replaced. 169 o Certificate revocation: "O"'s certificate might be compromised or 170 mis-issued, and the attacker shouldn't then get an infinite 171 ability to mint packages. 173 o Downgrade prevention: "O"'s site might have an XSS vulnerability, 174 and attackers with an old signed package shouldn't be able to take 175 advantage of the XSS forever. 177 o Metadata: The browser needs to know which resource within a 178 package file to treat as its Service Worker and/or initial HTML 179 page. 181 2.1.1.1. Online use 183 Bailey may have an internet connection through which they can, in 184 real time, fetch updates to the package they received from Alex. 186 2.1.1.2. Fully offline use 188 Or Bailey may not have any internet connection a significant fraction 189 of the time, either because they have no internet at all, because 190 they turn off internet except when intentionally downloading content, 191 or because they use up their plan partway through each month. 193 Associated requirements beyond Offline installation: 195 o Packaged validity information: Even without a direct internet 196 connection, Bailey should be able to check that their package is 197 still valid. 199 2.1.2. Offline browsing 201 Alex can download a file containing a large website (e.g. Wikipedia) 202 from its origin, save it to transferrable storage (e.g. an SD card), 203 and hand it to their peer Bailey. Then Bailey can browse the website 204 with a proof that it came from "O". Bailey may not have the storage 205 space to copy the website before browsing it. 207 Associated requirements beyond Offline installation: 209 o Random access: To avoid needing a long linear scan before using 210 the content. 212 o Compress stored packages: So that more content can fit on the same 213 storage device. 215 2.1.3. Save and share a web page 217 Casey is viewing a web page and wants to save it either for offline 218 use or to show it to their friend Dakota. Since Casey isn't the web 219 page's author, they don't have the private key needed to sign the 220 page. Browsers currently allow their users to save pages, but each 221 browser uses a different format (MHTML, Web Archive, or files in a 222 directory), so Dakota and Casey would need to be using the same 223 browser. Casey could also take a screenshot, at the cost of losing 224 links and accessibility. 226 Associated requirements: 228 o Unsigned content: A client can't sign content as another origin. 230 o Resources from multiple origins in a package: General web pages 231 include resources from multiple origins. 233 o Indexed by URL: Resources on the web are addressed by URL. 235 o Response headers: The meaning of a resource is heavily influenced 236 by its HTTP response headers. 238 2.2. Nice-to-have 240 2.2.1. Packaged Web Publications 242 The W3C's Publishing Working Group [7], merged from the International 243 Digital Publishing Forum (IDPF) and in charge of EPUB maintenance, 244 wants to be able to create publications on the web and then let them 245 be copied to different servers or to other users via arbitrary 246 protocols. See their Packaged Web Publications use cases [8] for 247 more details. 249 Associated requirements: 251 o Indexed by URL: Resources on the web are addressed by URL. 253 o Signing as an origin: So that readers can be sure their copy is 254 authentic and so that copying the package preserves the URLs of 255 the content inside it. 257 o Downgrade prevention: An early version of a publication might 258 contain incorrect content, and a publisher should be able to 259 update that without worrying that an attacker can still show the 260 old content to users. 262 o Metadata: A publication can have copyright and licensing concerns; 263 a title, author, and cover image; an ISBN or DOI name; etc.; which 264 should be included when that publication is packaged. 266 Other requirements are similar to those from Offline installation: 268 o Random access: To avoid needing a long linear scan before using 269 the content. 271 o Compress stored packages: So that more content can fit on the same 272 storage device. 274 o Request headers: If different users' browsers have different 275 capabilities or preferences, the "accept*" headers are important 276 for selecting which resource to use at each URL. 278 o Response headers: The meaning of a resource is heavily influenced 279 by its HTTP response headers. 281 o Signing uses existing TLS certificates: So a publisher doesn't 282 have to spend lots of money buying a specialized certificate. 284 o Cryptographic agility: Today's algorithms will eventually be 285 obsolete and will need to be replaced. 287 o Certificate revocation: The publisher's certificate might be 288 compromised or mis-issued, and an attacker shouldn't then get an 289 infinite ability to mint packages. 291 2.2.2. Third-party security review 293 Some users may want to grant certain permissions only to applications 294 that have been reviewed for security by a trusted third party. These 295 third parties could provide guarantees similar to those provided by 296 the iOS, Android, or ChromeOS app stores, which might allow browsers 297 to offer more powerful capabilities than have been deemed safe for 298 unaudited websites. 300 Binary transparency for websites is similar: like with Certificate 301 Transparency [RFC6962], the transparency logs would sign the content 302 of the package to provide assurance that experts had a chance to 303 audit the exact package a client received. 305 Associated requirements: 307 o Cross-signatures 309 2.2.3. Building packages from multiple libraries 311 Large programs are built from smaller components. In the case of the 312 web, components can be included either as Javascript files or as 313 "