idnits 2.17.1 

draft-yasskin-wpack-use-cases-02.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

     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 (13 April 2021) is 1102 days in the past.  Is this
     intentional?


  Checking references for intended status: Informational
  ----------------------------------------------------------------------------

  -- 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 (~~), 1 warning (==), 3 comments (--).

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


2	Network Working Group                                         J. Yasskin
3	Internet-Draft                                                    Google
4	Intended status: Informational                             13 April 2021
5	Expires: 15 October 2021

7	              Use Cases and Requirements for Web Packages
8	                    draft-yasskin-wpack-use-cases-02

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	Discussion Venues

17	   This note is to be removed before publishing as an RFC.

19	   Discussion of this document takes place on the WPACK Working Group
20	   mailing list (wpack@ietf.org), which is archived at
21	   https://mailarchive.ietf.org/arch/browse/wpack/.

23	   Source for this draft and an issue tracker can be found at
24	   https://github.com/WICG/webpackage.

26	Status of This Memo

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

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

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

41	   This Internet-Draft will expire on 15 October 2021.

43	Copyright Notice

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

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

57	Table of Contents

59	   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
60	   2.  Use cases . . . . . . . . . . . . . . . . . . . . . . . . . .   4
61	     2.1.  Essential . . . . . . . . . . . . . . . . . . . . . . . .   4
62	       2.1.1.  Offline installation  . . . . . . . . . . . . . . . .   4
63	       2.1.2.  Offline browsing  . . . . . . . . . . . . . . . . . .   6
64	       2.1.3.  Save and share a web page . . . . . . . . . . . . . .   6
65	       2.1.4.  Privacy-preserving prefetch . . . . . . . . . . . . .   7
66	     2.2.  Nice-to-have  . . . . . . . . . . . . . . . . . . . . . .   7
67	       2.2.1.  Packaged Web Publications . . . . . . . . . . . . . .   8
68	       2.2.2.  Avoiding Censorship . . . . . . . . . . . . . . . . .   9
69	       2.2.3.  Third-party security review . . . . . . . . . . . . .   9
70	       2.2.4.  Building packages from multiple libraries . . . . . .  10
71	       2.2.5.  Cross-CDN Serving . . . . . . . . . . . . . . . . . .  10
72	       2.2.6.  Pre-installed applications  . . . . . . . . . . . . .  11
73	       2.2.7.  Protecting Users from a Compromised Frontend  . . . .  12
74	       2.2.8.  Installation from a self-extracting executable  . . .  13
75	       2.2.9.  Packages in version control . . . . . . . . . . . . .  13
76	       2.2.10. Subresource bundling  . . . . . . . . . . . . . . . .  13
77	       2.2.11. Archival  . . . . . . . . . . . . . . . . . . . . . .  14
78	   3.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .  15
79	     3.1.  Essential . . . . . . . . . . . . . . . . . . . . . . . .  15
80	       3.1.1.  Indexed by URL  . . . . . . . . . . . . . . . . . . .  15
81	       3.1.2.  Request headers . . . . . . . . . . . . . . . . . . .  15
82	       3.1.3.  Response headers  . . . . . . . . . . . . . . . . . .  15
83	       3.1.4.  Signing as an origin  . . . . . . . . . . . . . . . .  15
84	       3.1.5.  Random access . . . . . . . . . . . . . . . . . . . .  16
85	       3.1.6.  Resources from multiple origins in a package  . . . .  16
86	       3.1.7.  Cryptographic agility . . . . . . . . . . . . . . . .  16
87	       3.1.8.  Unsigned content  . . . . . . . . . . . . . . . . . .  16
88	       3.1.9.  Certificate revocation  . . . . . . . . . . . . . . .  16
89	       3.1.10. Downgrade prevention  . . . . . . . . . . . . . . . .  16
90	       3.1.11. Metadata  . . . . . . . . . . . . . . . . . . . . . .  17
91	       3.1.12. Implementations are hard to get wrong . . . . . . . .  17
92	     3.2.  Nice to have  . . . . . . . . . . . . . . . . . . . . . .  17
93	       3.2.1.  Streamed loading  . . . . . . . . . . . . . . . . . .  17
94	       3.2.2.  Signing without origin trust  . . . . . . . . . . . .  17
95	       3.2.3.  Additional signatures . . . . . . . . . . . . . . . .  17
96	       3.2.4.  Binary  . . . . . . . . . . . . . . . . . . . . . . .  18
97	       3.2.5.  Deduplication of diamond dependencies . . . . . . . .  18
98	       3.2.6.  Old crypto can be removed . . . . . . . . . . . . . .  18
99	       3.2.7.  Compress transfers  . . . . . . . . . . . . . . . . .  18
100	       3.2.8.  Compress stored packages  . . . . . . . . . . . . . .  18
101	       3.2.9.  Subsetting and reordering . . . . . . . . . . . . . .  18
102	       3.2.10. Packaged validity information . . . . . . . . . . . .  18
103	       3.2.11. Signing uses existing TLS certificates  . . . . . . .  18
104	       3.2.12. External dependencies . . . . . . . . . . . . . . . .  19
105	       3.2.13. Trailing length . . . . . . . . . . . . . . . . . . .  19
106	       3.2.14. Time-shifting execution . . . . . . . . . . . . . . .  19
107	       3.2.15. Service Worker integration  . . . . . . . . . . . . .  19
108	   4.  Non-goals . . . . . . . . . . . . . . . . . . . . . . . . . .  19
109	     4.1.  Store confidential data . . . . . . . . . . . . . . . . .  19
110	     4.2.  Generate packages on the fly  . . . . . . . . . . . . . .  20
111	     4.3.  Non-origin identity . . . . . . . . . . . . . . . . . . .  20
112	     4.4.  DRM . . . . . . . . . . . . . . . . . . . . . . . . . . .  20
113	     4.5.  Ergonomic replacement for HTTP/2 PUSH . . . . . . . . . .  20
114	   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  21
115	   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
116	   7.  Informative References  . . . . . . . . . . . . . . . . . . .  21
117	   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  23
118	   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  23

120	1.  Introduction

122	   People would like to use content offline and in other situations
123	   where there isn't a direct connection to the server where the content
124	   originates.  However, it's difficult to distribute and verify the
125	   authenticity of applications and content without a connection to the
126	   network.  The W3C has addressed running applications offline with
127	   Service Workers ([ServiceWorkers]), but not the problem of
128	   distribution.

130	   Previous attempts at packaging web resources (e.g.  Resource Packages
131	   (https://www.mnot.net/blog/2010/02/18/resource_packages) and the W3C
132	   TAG's packaging proposal (https://w3ctag.github.io/packaging-on-the-
133	   web/)) were motivated by speeding up the download of resources from a
134	   single server, which is probably better achieved through other
135	   mechanisms like HTTP/2 PUSH, possibly augmented with a simple
136	   manifest of URLs a page plans to use
137	   (https://lists.w3.org/Archives/Public/public-web-
138	   perf/2015Jan/0038.html).  This attempt is instead motivated by
139	   avoiding a connection to the origin server at all.  It may still be
140	   useful for the earlier use cases, so they're still listed, but
141	   they're not primary.

143	2.  Use cases

145	   These use cases are in rough descending priority order.  If use cases
146	   have conflicting requirements, the design should enable more
147	   important use cases.

149	2.1.  Essential

151	2.1.1.  Offline installation

153	   Alex can download a file containing a website (a PWA
154	   (https://developers.google.com/web/progressive-web-apps/checklist))
155	   including a Service Worker from origin "O", and transmit it to their
156	   peer Bailey, and then Bailey can install the Service Worker with a
157	   proof that it came from "O".  This saves Bailey the bandwidth costs
158	   of transferring the website.

160	   There are roughly two ways to accomplish this:

162	   1.  Package just the Service Worker Javascript and any other
163	       Javascript that it importScripts() (https://w3c.github.io/
164	       ServiceWorker/#importscripts), with their URLs and enough
165	       metadata to synthesize a
166	       navigator.serviceWorker.register(scriptURL, options) call
167	       (https://w3c.github.io/ServiceWorker/#navigator-service-worker-
168	       register), along with an uninterpreted but signature-checked blob
169	       of data that the Service Worker can interpret to fill in its
170	       caches.

172	   2.  Package the resources so that the Service Worker can fetch() them
173	       to populate its cache.

175	   Associated requirements for just the Service Worker:

177	   *  Indexed by URL: The "register()" and "importScripts()" calls have
178	      semantics that depend on the URL.

180	   *  Signing as an origin: To prove that the file came from "O".

182	   *  Signing uses existing TLS certificates: So "O" doesn't have to
183	      spend lots of money buying a specialized certificate.

185	   *  Cryptographic agility: Today's algorithms will eventually be
186	      obsolete and will need to be replaced.

188	   *  Certificate revocation: "O"'s certificate might be compromised or
189	      mis-issued, and the attacker shouldn't then get an infinite
190	      ability to mint packages.

192	   *  Downgrade prevention: "O"'s site might have an XSS vulnerability,
193	      and attackers with an old signed package shouldn't be able to take
194	      advantage of the XSS forever.

196	   *  Metadata: Just enough to generate the "register()" call, which is
197	      less than a full W3C Application Manifest.

199	   Additional associated requirements for packaged resources:

201	   *  Indexed by URL: Resources on the web are addressed by URL.

203	   *  Request headers: If Bailey's running a different browser from Alex
204	      or has a different language configured, the "accept*" headers are
205	      important for selecting which resource to use at each URL.

207	   *  Response headers: The meaning of a resource is heavily influenced
208	      by its HTTP response headers.

210	   *  Resources from multiple origins in a package: So the site can be
211	      built from multiple components (Section 2.2.4).

213	   *  Metadata: The browser needs to know which resource within a
214	      package file to treat as its Service Worker and/or initial HTML
215	      page.

217	2.1.1.1.  Online use

219	   Bailey may have an internet connection through which they can, in
220	   real time, fetch updates to the package they received from Alex.

222	2.1.1.2.  Fully offline use

224	   Or Bailey may not have any internet connection a significant fraction
225	   of the time, either because they have no internet at all, because
226	   they turn off internet except when intentionally downloading content,
227	   or because they use up their plan partway through each month.

229	   Associated requirements beyond Offline installation:

231	   *  Packaged validity information: Even without a direct internet
232	      connection, Bailey should be able to check that their package is
233	      still valid.

235	2.1.2.  Offline browsing

237	   Alex can download a file containing a large website (e.g.  Wikipedia)
238	   from its origin, save it to transferrable storage (e.g. an SD card),
239	   and hand it to their peer Bailey.  Then Bailey can browse the website
240	   with a proof that it came from "O".  Bailey may not have the storage
241	   space to copy the website before browsing it.

243	   This use case is harder for publishers to support if we specialize
244	   Section 2.1.1 for Service Workers since it requires the publisher to
245	   adopt Service Workers before they can sign their site.

247	   Associated requirements beyond Offline installation:

249	   *  Random access: To avoid needing a long linear scan before using
250	      the content.

252	   *  Compress stored packages: So that more content can fit on the same
253	      storage device.

255	2.1.3.  Save and share a web page

257	   Casey is viewing a web page and wants to save it either for offline
258	   use or to show it to their friend Dakota.  Since Casey isn't the web
259	   page's publisher, they don't have the private key needed to sign the
260	   page.  Browsers currently allow their users to save pages, but each
261	   browser uses a different format (MHTML, Web Archive, or files in a
262	   directory), so Dakota and Casey would need to be using the same
263	   browser.  Casey could also take a screenshot, at the cost of losing
264	   links and accessibility.

266	   Associated requirements:

268	   *  Unsigned content: A client can't sign content as another origin.

270	   *  Resources from multiple origins in a package: General web pages
271	      include resources from multiple origins.

273	   *  Indexed by URL: Resources on the web are addressed by URL.

275	   *  Response headers: The meaning of a resource is heavily influenced
276	      by its HTTP response headers.

278	2.1.4.  Privacy-preserving prefetch

280	   Lots of websites link to other websites.  Many of these source sites
281	   would like the targets of these links to load quickly.  The source
282	   could use "<link rel="prefetch">" to prefetch the target of a link,
283	   but if the user doesn't actually click that link, that leaks the fact
284	   that the user saw a page that linked to the target.  This can be true
285	   even if the prefetch is made without browser credentials because of
286	   mechanisms like TLS session IDs.

288	   Because clients have limited data budgets to prefetch link targets,
289	   this use case is probably limited to sites that can accurately
290	   predict which link their users are most likely to click.  For
291	   example, search engines can predict that their users will click one
292	   of the first couple results, and news aggreggation sites like Reddit
293	   or Slashdot can hope that users will read the article if they've
294	   navigated to its discussion.

296	   Two search engines have built systems to do this with today's
297	   technology: Google's AMP (https://www.ampproject.org/) and Baidu's
298	   MIP (https://www.mipengine.org/) formats and caches allow them to
299	   prefetch search results while preserving privacy, at the cost of
300	   showing the wrong URLs for the results once the user has clicked.  A
301	   good solution to this problem would show the right URLs but still
302	   avoid a request to the publishing origin until after the user clicks.

304	   Associated requirements:

306	   *  Signing as an origin: To prove the content came from the original
307	      origin.

309	   *  Streamed loading: If the user clicks before the target page is
310	      fully transferred, the browser should be able to start loading
311	      early parts before the source site finishes sending the whole
312	      page.

314	   *  Compress transfers

316	   *  Subsetting and reordering: If a prefetched page includes
317	      subresources, its publisher might want to provide and sign both
318	      WebP and PNG versions of an image, but the source site should be
319	      able to transfer only best one for each client.

321	2.2.  Nice-to-have
322	2.2.1.  Packaged Web Publications

324	   The W3C's Publishing Working Group
325	   (https://www.w3.org/publishing/groups/publ-wg/), merged from the
326	   International Digital Publishing Forum (IDPF) and in charge of EPUB
327	   maintenance, wants to be able to create publications on the web and
328	   then let them be copied to different servers or to other users via
329	   arbitrary protocols.  See their Packaged Web Publications use cases
330	   (https://www.w3.org/TR/pwp-ucr/#pwp) for more details.

332	   Associated requirements:

334	   *  Indexed by URL: Resources on the web are addressed by URL.

336	   *  Signing as an origin: So that readers can be sure their copy is
337	      authentic and so that copying the package preserves the URLs of
338	      the content inside it.

340	   *  Downgrade prevention: An early version of a publication might
341	      contain incorrect content, and a publisher should be able to
342	      update that without worrying that an attacker can still show the
343	      old content to users.

345	   *  Metadata: A publication can have copyright and licensing concerns;
346	      a title, author, and cover image; an ISBN or DOI name; etc.; which
347	      should be included when that publication is packaged.

349	   Other requirements are similar to those from Offline installation:

351	   *  Random access: To avoid needing a long linear scan before using
352	      the content.

354	   *  Compress stored packages: So that more content can fit on the same
355	      storage device.

357	   *  Request headers: If different users' browsers have different
358	      capabilities or preferences, the "accept*" headers are important
359	      for selecting which resource to use at each URL.

361	   *  Response headers: The meaning of a resource is heavily influenced
362	      by its HTTP response headers.

364	   *  Signing uses existing TLS certificates: So a publisher doesn't
365	      have to spend lots of money buying a specialized certificate.

367	   *  Cryptographic agility: Today's algorithms will eventually be
368	      obsolete and will need to be replaced.

370	   *  Certificate revocation: The publisher's certificate might be
371	      compromised or mis-issued, and an attacker shouldn't then get an
372	      infinite ability to mint packages.

374	2.2.2.  Avoiding Censorship

376	   Some users want to retrieve resources that their governments or
377	   network providers don't want them to see.  Right now, it's
378	   straightforward for someone in a privileged network position to block
379	   access to particular hosts, but TLS makes it difficult to block
380	   access to particular resources on those hosts.

382	   Today it's straightforward to retrieve blocked content from a third
383	   party, but there's no guarantee that the third-party has sent the
384	   user an accurate representation of the content: the user has to trust
385	   the third party.

387	   With signed web packages, the user can re-gain assurance that the
388	   content is authentic, while still bypassing the censorship.  Packages
389	   don't do anything to help discover this content.

391	   Systems that make censorship more difficult can also make legitimate
392	   content filtering more difficult.  Because the client that processes
393	   a web package always knows the true URL, this forces content
394	   filtering to happen on the client instead of on the network.

396	   Associated requirements:

398	   *  Indexed by URL: So the user can see that they're getting the
399	      content they expected.

401	   *  Signing as an origin: So that readers can be sure their copy is
402	      authentic and so that copying the package preserves the URLs of
403	      the content inside it.

405	2.2.3.  Third-party security review

407	   Some users may want to grant certain permissions only to applications
408	   that have been reviewed for security by a trusted third party.  These
409	   third parties could provide guarantees similar to those provided by
410	   the iOS, Android, or Chrome OS app stores, which might allow browsers
411	   to offer more powerful capabilities than have been deemed safe for
412	   unaudited websites.

414	   Binary transparency for websites is similar: like with Certificate
415	   Transparency [RFC6962], the transparency logs would sign the content
416	   of the package to provide assurance that experts had a chance to
417	   audit the exact package a client received.

419	   Associated requirements:

421	   *  Additional signatures

423	2.2.4.  Building packages from multiple libraries

425	   Large programs are built from smaller components.  In the case of the
426	   web, components can be included either as Javascript files or as
427	   "<iframe>"d subresources.  In the first case, the packager could copy
428	   the JS files to their own origin; but in the second, it may be
429	   important for the "<iframe>"d resources to be able to make same-
430	   origin (https://html.spec.whatwg.org/multipage/origin.html#same-
431	   origin) requests back to their own origin, for example to implement
432	   federated sign-in.

434	   Associated requirements:

436	   *  Resources from multiple origins in a package: Each component may
437	      come from its own origin.

439	   *  Deduplication of diamond dependencies: If we have dependencies
440	      A->B->D and A->C->D, it's important that a request for a D
441	      resource resolves to a single resource that both B and C can
442	      handle.

444	2.2.4.1.  Shared libraries

446	   In ecosystems like Electron (https://electron.atom.io/) and Node
447	   (https://nodejs.org/en/), many packages may share some common
448	   dependencies.  The cost of downloading each package can be greatly
449	   reduced if the package can merely point at other dependencies to
450	   download instead of including them all inline.

452	   Associated requirements:

454	   *  External dependencies

456	2.2.5.  Cross-CDN Serving

458	   When a web page has subresources from a different origin, retrieval
459	   of those subresources can be optimized if they're transferred over
460	   the same connection as the main resource.  If both origins are
461	   distributed by the same CDN, in-progress mechanisms like
462	   [I-D.ietf-httpbis-http2-secondary-certs] allow the server to use a
463	   single connection to send both resources, but if the resource and
464	   subresource don't share a CDN or don't use a CDN at all, existing
465	   mechanisms don't help.

467	   If the subresource is signed by its publisher, the main resource's
468	   server can forward it to the client.

470	   There are some yet-to-be-solved privacy problems if the client and
471	   server want to avoid transferring subresources that are already in
472	   the client's cache: naively telling the server that a resource is
473	   already present is a privacy leak.

475	   Associated requirements:

477	   *  Streamed loading: To get optimal performance, the browser should
478	      be able to start loading early parts of a resource before the
479	      distributor finishes sending the whole resource.

481	   *  Signing as an origin: To prove the content came from the original
482	      origin.

484	   *  Compress transfers

486	2.2.6.  Pre-installed applications

488	   Device manufacturers would like to ship their devices with some web
489	   applications pre-installed and usable even if the application is
490	   first used without an internet connection.  Thereafter, the
491	   application should use the normal Service Worker update mechanism to
492	   stay up to date.

494	   One way to accomplish this would be to pre-create a browser profile
495	   in the device's default browser and navigate it to each of the pre-
496	   installed apps before recording the device image.  However, this
497	   means end-users miss the browser's initial setup flow and possibly
498	   that any "unique" cookies the sites set are now shared across
499	   everyone who bought the device.  It also doesn't help users who
500	   change their default browser.

502	   If multiple browsers supported an unsigned web package format, with
503	   an option to trust it as if it were signed if it's in a particular
504	   section of the filesystem that's as protected as the browser's
505	   executable, and if registering a Service Worker from a page inside a
506	   package passed the full package contents to the Service Worker's
507	   "install" event, the device manufacturer could provide web packages
508	   for each pre-installed application that would work in the user's
509	   chosen browser.

511	   Associated requirements:

513	   *  Service Worker integration: To pass the package into the "install"
514	      event and from there get its contents into a "Cache".

516	2.2.7.  Protecting Users from a Compromised Frontend

518	   If an attacker gains control over a frontend server, any user who
519	   visits that server while they have control can have their web app
520	   upgraded to a hostile version.  On the other hand, native
521	   applications either control their own update process or delegate it
522	   to an app store, which allows them to protect users by requiring that
523	   updates are signed by a trusted key.  This protection isn't perfect
524	   ---it's a Trust-On-First-Use mechanism that doesn't protect users who
525	   first install the application while the attacker controls the server
526	   they get it from, and attackers can bypass it by compromising the
527	   app's build system---but since both of those risks also apply to web
528	   apps, it does make the attack surface for native applications smaller
529	   than for web apps.

531	   Not all application developers should choose to require signed
532	   updates, since doing so adds the risk of losing the signing key, but
533	   having this option gives security-sensitive applications like
534	   Dashlane (https://app.dashlane.com/) an incentive to build native
535	   apps instead of web apps.

537	   It has been difficult to add a signature requirement for web app
538	   upgrades because we haven't had a way to sign web resources.  Web
539	   Packaging is expected to provide that, so we'll be able to consider
540	   the best way to do it.

542	   Both HTTP Strict Transport Security (HSTS, [RFC6797]) and HTTP Public
543	   Key Pinning (HPKP, [RFC7469]) have established ways to pin assertions
544	   about a site's security for a bounded time after a visit.  We could
545	   do the same with a web app's signing key.

547	   Note that HPKP has been turned off in Chromium
548	   (https://groups.google.com/a/chromium.org/d/topic/blink-
549	   dev/he9tr7p3rZ8/discussion) because it was difficult to use and made
550	   it too easy to "brick" a website.  To reduce the chance of bricking
551	   the website, this key pinning design could require an active Service
552	   Worker before enforcing the pins.  It could also avoid the need for
553	   users to take manual action to recover from a lost signing key by
554	   allowing a new key to be used if it's seen consistently for a site-
555	   chosen amount of time, instead of waiting for the whole pin to
556	   expire.  However, these mitigations don't guarantee that browsers
557	   would find the tradeoffs more acceptable than they did for HPKP.

559	   One can think of a CDN as a potentially-compromised frontend and use
560	   this mechanism to limit the damage it can cause.  However, this
561	   doesn't make it safe to use a wholly-untrustworthy CDN because of the
562	   risk to first-time users.

564	   Associated requirements:

566	   *  Signing without origin trust: To let a backend system vouch for
567	      the content.  This would likely be augmented with origin trust by
568	      receiving the signed content over TLS.

570	   *  Streamed loading: To get optimal performance, the browser should
571	      be able to start loading early parts of a resource before the
572	      server finishes sending the whole resource.

574	2.2.8.  Installation from a self-extracting executable

576	   The Node and Electron communities would like to install packages
577	   using self-extracting executables.  The traditional way to design a
578	   self-extracting executable is to concatenate the package to the end
579	   of the executable, have the executable look for a length at its own
580	   end, and seek backwards from there for the start of the package.

582	   Associated requirements:

584	   *  Trailing length

586	2.2.9.  Packages in version control

588	   Once packages are generated, they should be stored in version
589	   control.  Many popular VC systems auto-detect text files in order to
590	   "fix" their line endings.  If the first bytes of a package look like
591	   text, while later bytes store binary data, VC may break the package.

593	   Associated requirements:

595	   *  Binary

597	2.2.10.  Subresource bundling

599	   Text based subresources often benefit from improved compression
600	   ratios when bundled together.

602	   At the same time, the current practice of JS and CSS bundling, by
603	   compiling everything into a single JS file, also has negative side-
604	   effects:

606	   1.  Dependent execution - in order to start executing _any_ of the
607	       bundled resources, it is required to download, parse and execute
608	       _all_ of them.

610	   2.  Loss of caching granularity - Modification of _any_ of the
611	       resources results in caching invalidation of _all_ of them.

613	   3.  Loss of module semantics - ES6 modules must be delivered as
614	       independent resources.  Therefore, current bundling methods,
615	       which deliver them with other resources under a common URL,
616	       require transpilation to ES5 and result in loss of ES6 module
617	       semantics.

619	   An on-the-fly readable packaging format, that will enable resources
620	   to maintain their own URLs while being physically delivered with
621	   other resources, can resolve the above downsides while keeping the
622	   upsides of improved compression ratios.

624	   To improve cache granularity, the client needs to tell the server
625	   which versions of which resources are already cached, which it could
626	   do with a Service Worker or perhaps with
627	   [I-D.ietf-httpbis-cache-digest].

629	   Associated requirements:

631	   *  Indexed by URL

633	   *  Streamed loading: To solve downside 1.

635	   *  Compress transfers: To keep the upside.

637	   *  Response headers: At least the Content-Type is needed to load JS
638	      and CSS.

640	   *  Unsigned content: Signing same-origin content wastes space.

642	2.2.11.  Archival

644	   Existing formats like WARC ([ISO28500]) do a good job of accurately
645	   representing the state of a web server at a particular time, but a
646	   browser can't currently use them to give a person the experience of
647	   that website at the time it was archived.  It's not obvious to the
648	   author of this draft that a new packaging format is likely to improve
649	   on WARC, compared to, for example, implementing support for WARC in
650	   browsers, but folks who know about archiving seem interested, e.g.:
651	   https://twitter.com/anjacks0n/status/950861384266416134
652	   (https://twitter.com/anjacks0n/status/950861384266416134).

654	   Because of the time scales involved in archival, any signatures from
655	   the original host would likely not be trusted anymore by the time the
656	   archive is viewed, so implementations would need to sandbox the
657	   content instead of running it on the original origin.

659	   Associated requirements:

661	   *  Indexed by URL

663	   *  Response headers: To accurately record the server's response.

665	   *  Unsigned content: To deal with expired signatures.

667	   *  Time-shifting execution

669	3.  Requirements

671	3.1.  Essential

673	3.1.1.  Indexed by URL

675	   Resources should be keyed by URLs, matching how browsers look
676	   resources up over HTTP.

678	3.1.2.  Request headers

680	   Resource keys should include request headers like "accept" and
681	   "accept-language", which allows content-negotiated resources to be
682	   represented.

684	   This would require an extension to [MHTML], which uses the "content-
685	   location" response header to encode the requested URL, but has no way
686	   to encode other request headers.  MHTML also has no instructions for
687	   handling multiple resources with the same "content-location".

689	   This also requires an extension to [ZIP]: we'd need to encode the
690	   request headers into ZIP's filename fields.

692	3.1.3.  Response headers

694	   Resources should include their HTTP response headers, like "content-
695	   type", "content-encoding", "expires", "content-security-policy", etc.

697	   This requires an extension to [ZIP]: we'd need something like [JAR]'s
698	   "META-INF" directory to hold extra metadata beyond the resource's
699	   body.

701	3.1.4.  Signing as an origin

703	   Resources within a package are provably from an entity with the
704	   ability to serve HTTPS requests for those resources' origin
705	   [RFC6454].

707	   Note that previous attempts to sign HTTP messages
708	   ([I-D.thomson-http-content-signature], [I-D.burke-content-signature],
709	   and [I-D.cavage-http-signatures]) omit a description of how a client
710	   should use a signature to prove that a resource comes from a
711	   particular origin, and they're probably not usable for that purpose.

713	   This would require an extension to the [ZIP] format, similar to
714	   [JAR]'s signatures.

716	   In any cryptographic system, the specification is responsible to make
717	   correct implementations easier to deploy than incorrect
718	   implementations (Section 3.1.12).

720	3.1.5.  Random access

722	   When a package is stored on disk, the browser can access arbitrary
723	   resources without a linear scan.

725	   [MHTML] would need to be extended with an index of the byte offsets
726	   of each contained resource.

728	3.1.6.  Resources from multiple origins in a package

730	   A package from origin "A" can contain resources from origin "B"
731	   authenticated at the same level as those from "A".

733	3.1.7.  Cryptographic agility

735	   Obsolete cryptographic algorithms can be replaced.

737	   Planning to upgrade the cryptography also means we should include
738	   some way to know when it's safe to remove old cryptography
739	   (Section 3.2.6).

741	3.1.8.  Unsigned content

743	   Alex can create their own package without a CA-signed certificate,
744	   and Bailey can view the content of the package.

746	3.1.9.  Certificate revocation

748	   When a package is signed by a revoked certificate, online browsers
749	   can detect this reasonably quickly.

751	3.1.10.  Downgrade prevention

753	   Attackers can't cause a browser to trust an older, vulnerable version
754	   of a package after the browser has seen a newer version.

756	3.1.11.  Metadata

758	   Metadata like that found in the W3C's Application Manifest
759	   [W3C.WD-appmanifest-20170828] can help a client know how to load and
760	   display a package.

762	3.1.12.  Implementations are hard to get wrong

764	   The design should incorporate aspects that tend to cause incorrect
765	   implementations to get noticed quickly, and avoid aspects that are
766	   easy to implement incorrectly.  For example:

768	   *  Explicitly specifying a cryptographic algorithm identifier in
769	      [RFC7515] made it easy for implementations to trust that
770	      algorithm, which caused vulnerabilities
771	      (https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-
772	      standard-that-everyone-should-avoid).

774	   *  [ZIP]'s duplicate specification of filenames makes it easy for
775	      implementations to check the signature of one copy but use the
776	      other (https://nakedsecurity.sophos.com/2013/07/10/anatomy-of-a-
777	      security-hole-googles-android-master-key-debacle-explained/).

779	   *  Following Langley's Law (https://blog.gerv.net/2016/09/
780	      introducing-deliberate-protocol-errors-langleys-law/) when
781	      possible makes it hard to deploy incorrect implementations.

783	3.2.  Nice to have

785	3.2.1.  Streamed loading

787	   The browser can load a package as it downloads.

789	   This conflicts with ZIP, since ZIP's index is at the end.

791	3.2.2.  Signing without origin trust

793	   It's possible to sign a resource with a key that has some effect on
794	   trust other than asserting that the origin's owner vouches for it.
795	   These keys could be expressed as raw public keys or as certificates
796	   with other key usages.

798	3.2.3.  Additional signatures

800	   Third-parties can vouch for packages by signing them.

802	3.2.4.  Binary

804	   The format is identified as binary by tools that might try to "fix"
805	   line endings.

807	   This conflicts with using an [MHTML]-based format.

809	3.2.5.  Deduplication of diamond dependencies

811	   Nested packages that have multiple dependency routes to the same sub-
812	   package, can be transmitted and stored with only one copy of that
813	   sub-package.

815	3.2.6.  Old crypto can be removed

817	   The ecosystem can identify when an obsolete cryptographic algorithm
818	   is no longer needed and can be removed.

820	3.2.7.  Compress transfers

822	   Transferring a package over the network takes as few bytes as
823	   possible.  This is an easier problem than Compress stored packages
824	   since it doesn't have to preserve Random access.

826	3.2.8.  Compress stored packages

828	   Storing a package on disk takes as few bytes as possible.

830	3.2.9.  Subsetting and reordering

832	   Resources can be removed from and reordered within a package, without
833	   breaking signatures (Section 3.1.4).

835	3.2.10.  Packaged validity information

837	   Certificate revocation and Downgrade prevention information can
838	   itself be packaged or included in other packages.

840	3.2.11.  Signing uses existing TLS certificates

842	   A "normal" TLS certificate can be used for signing packages.
843	   Avoiding extra requirements like "code signing" certificates makes
844	   packaging more accessible to all sites.

846	3.2.12.  External dependencies

848	   Sub-packages can be "external" to the main package, meaning the
849	   browser will need to either fetch them separately or already have
850	   them. (#35, App Installer Story (https://github.com/WICG/webpackage/
851	   issues/35))

853	3.2.13.  Trailing length

855	   The package's length in bytes appears a fixed offset from the end of
856	   the package.

858	   This conflicts with [MHTML].

860	3.2.14.  Time-shifting execution

862	   In some unsigned packages, Javascript time-telling functions should
863	   return the timestamp of the package, rather than the true current
864	   time.

866	   We should explore if this has security implications.

868	3.2.15.  Service Worker integration

870	   When a web page inside a package registers a Service Worker, that
871	   Service Worker's "install" event should receive a reference to the
872	   full package, with a way to copy the package's contents into a
873	   "Cache" object.  ([ServiceWorkers])

875	4.  Non-goals

877	   Some features often come along with packaging and signing, and it's
878	   important to explicitly note that they don't appear in the list of
879	   Requirements.

881	4.1.  Store confidential data

883	   Packages are designed to hold public information and to be shared to
884	   people with whom the original publisher never has an interactive
885	   connection.  In that situation, there's no way to keep the contents
886	   confidential: even if they were encrypted, to make the data public,
887	   anyone would have to be able to get the decryption key.

889	   It's possible to maintain something similar to confidentiality for
890	   non-public packaged data, but doing so complicates the format design
891	   and can give users a false sense of security.

893	   We believe we'll cause fewer privacy breaches if we omit any
894	   mechanism for encrypting data, than if we include something and try
895	   to teach people when it's unsafe to use.

897	4.2.  Generate packages on the fly

899	   See discussion at WICG/webpackage#6
900	   (https://github.com/WICG/webpackage/issues/6#issuecomment-275746125).

902	4.3.  Non-origin identity

904	   A package can be primarily identified as coming from something other
905	   than a Web Origin (https://html.spec.whatwg.org/multipage/
906	   browsers.html#concept-origin).

908	4.4.  DRM

910	   Special support for blocking access to downloaded content based on
911	   licensing.  Note that DRM systems can be shipped inside the package
912	   even if the packaging format doesn't specifically support them.

914	4.5.  Ergonomic replacement for HTTP/2 PUSH

916	   HTTP/2 PUSH ([RFC7540], section 8.2) is hard for developers to
917	   configure, and an explicit package format might be easier.  However,
918	   experts in this area believe we should focus on improving PUSH
919	   directly instead of routing around it with a bundling format.

921	   Trying to bundle resources in order to speed up page loads has a long
922	   history, including Resource Packages
923	   (https://www.mnot.net/blog/2010/02/18/resource_packages) from 2010
924	   and the W3C TAG's packaging proposal (https://w3ctag.github.io/
925	   packaging-on-the-web/) from 2015.

927	   However, the HTTPWG is doing a lot of work to let servers optimize
928	   the PUSHed data, and packaging would either have to re-do that or
929	   accept lower performance.  For example:

931	   *  [I-D.vkrasnov-h2-compression-dictionaries] should allow individual
932	      small resources to be compressed as well as they would be in a
933	      bundle.

935	   *  [I-D.ietf-httpbis-cache-digest] tells the server which resources
936	      it doesn't need to PUSH.

938	   Associated requirements:

940	   *  Streamed loading: If the whole package has to be downloaded before
941	      the browser can load a piece, this will definitely be slower than
942	      PUSH.

944	   *  Compress transfers: Keep up with
945	      [I-D.vkrasnov-h2-compression-dictionaries].

947	   *  Indexed by URL: Resources on the web are addressed by URL.

949	   *  Request headers: PUSH_PROMISE (http://httpwg.org/specs/
950	      rfc7540.html#PUSH_PROMISE) ([RFC7540], section 6.6) includes
951	      request headers.

953	   *  Response headers: PUSHed resources include their response headers.

955	5.  Security Considerations

957	   The security considerations will depend on the solution designed to
958	   satisfy the above requirements.  See
959	   [I-D.yasskin-dispatch-web-packaging] for one possible set of security
960	   considerations.

962	6.  IANA Considerations

964	   This document has no actions for IANA.

966	7.  Informative References

968	   [I-D.burke-content-signature]
969	              Burke, B., "HTTP Header for digital signatures", Work in
970	              Progress, Internet-Draft, draft-burke-content-signature-
971	              00, 7 March 2011, <https://tools.ietf.org/html/draft-
972	              burke-content-signature-00>.

974	   [I-D.cavage-http-signatures]
975	              Cavage, M. and M. Sporny, "Signing HTTP Messages", Work in
976	              Progress, Internet-Draft, draft-cavage-http-signatures-12,
977	              21 October 2019, <https://tools.ietf.org/html/draft-
978	              cavage-http-signatures-12>.

980	   [I-D.ietf-httpbis-cache-digest]
981	              Oku, K. and Y. Weiss, "Cache Digests for HTTP/2", Work in
982	              Progress, Internet-Draft, draft-ietf-httpbis-cache-digest-
983	              05, 2 July 2018, <https://tools.ietf.org/html/draft-ietf-
984	              httpbis-cache-digest-05>.

986	   [I-D.ietf-httpbis-http2-secondary-certs]
987	              Bishop, M., Sullivan, N., and M. Thomson, "Secondary
988	              Certificate Authentication in HTTP/2", Work in Progress,
989	              Internet-Draft, draft-ietf-httpbis-http2-secondary-certs-
990	              06, 14 May 2020, <https://tools.ietf.org/html/draft-ietf-
991	              httpbis-http2-secondary-certs-06>.

993	   [I-D.thomson-http-content-signature]
994	              Thomson, M., "Content-Signature Header Field for HTTP",
995	              Work in Progress, Internet-Draft, draft-thomson-http-
996	              content-signature-00, 2 July 2015,
997	              <https://tools.ietf.org/html/draft-thomson-http-content-
998	              signature-00>.

1000	   [I-D.vkrasnov-h2-compression-dictionaries]
1001	              Krasnov, V. and Y. Weiss, "Compression Dictionaries for
1002	              HTTP/2", Work in Progress, Internet-Draft, draft-vkrasnov-
1003	              h2-compression-dictionaries-03, 5 March 2018,
1004	              <https://tools.ietf.org/html/draft-vkrasnov-h2-
1005	              compression-dictionaries-03>.

1007	   [I-D.yasskin-dispatch-web-packaging]
1008	              Yasskin, J., "Web Packaging", Work in Progress, Internet-
1009	              Draft, draft-yasskin-dispatch-web-packaging-00, 30 June
1010	              2017, <https://tools.ietf.org/html/draft-yasskin-dispatch-
1011	              web-packaging-00>.

1013	   [ISO28500] "WARC file format", ISO 28500:2017, 2017,
1014	              <https://www.iso.org/standard/68004.html>.

1016	   [JAR]      "JAR File Specification", 2014,
1017	              <https://docs.oracle.com/javase/7/docs/technotes/guides/
1018	              jar/jar.html>.

1020	   [MHTML]    Palme, J., Hopmann, A., and N. Shelness, "MIME
1021	              Encapsulation of Aggregate Documents, such as HTML
1022	              (MHTML)", RFC 2557, DOI 10.17487/RFC2557, March 1999,
1023	              <https://www.rfc-editor.org/rfc/rfc2557>.

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

1029	   [RFC6797]  Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
1030	              Transport Security (HSTS)", RFC 6797,
1031	              DOI 10.17487/RFC6797, November 2012,
1032	              <https://www.rfc-editor.org/rfc/rfc6797>.

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

1038	   [RFC7469]  Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
1039	              Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
1040	              2015, <https://www.rfc-editor.org/rfc/rfc7469>.

1042	   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
1043	              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
1044	              2015, <https://www.rfc-editor.org/rfc/rfc7515>.

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

1051	   [ServiceWorkers]
1052	              "Service Workers Nightly", W3C ED,
1053	              <https://w3c.github.io/ServiceWorker/>.

1055	   [W3C.WD-appmanifest-20170828]
1056	              Caceres, M., Christiansen, K., Lamouri, M., Kostiainen,
1057	              A., and R. Dolin, "Web App Manifest", World Wide Web
1058	              Consortium WD WD-appmanifest-20170828, 28 August 2017,
1059	              <https://www.w3.org/TR/2017/WD-appmanifest-20170828>.

1061	   [ZIP]      "APPNOTE.TXT - .ZIP File Format Specification", 1 October
1062	              2014, <https://pkware.cachefly.net/webdocs/casestudies/
1063	              APPNOTE.TXT>.

1065	Appendix A.  Acknowledgements

1067	   Thanks to Yoav Weiss for the Subresource bundling use case and
1068	   discussions about content distributors.

1070	Author's Address

1072	   Jeffrey Yasskin
1073	   Google

1075	   Email: jyasskin@chromium.org