idnits 2.17.1 

draft-yasskin-webpackage-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 :
  ----------------------------------------------------------------------------

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


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

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

  -- The document date (October 30, 2019) is 1637 days in the past.  Is this
     intentional?


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

  -- Looks like a reference, but probably isn't: '1' on line 1035

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

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

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

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

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

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

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

  -- Looks like a reference, but probably isn't: '9' on line 1053

  -- Looks like a reference, but probably isn't: '10' on line 1055

  -- Looks like a reference, but probably isn't: '11' on line 1057

  -- Looks like a reference, but probably isn't: '12' on line 1059

  -- Looks like a reference, but probably isn't: '13' on line 1061

  -- Looks like a reference, but probably isn't: '14' on line 1063

  -- Looks like a reference, but probably isn't: '15' on line 1065

  -- Looks like a reference, but probably isn't: '16' on line 1067

  -- Looks like a reference, but probably isn't: '17' on line 1069

  -- Looks like a reference, but probably isn't: '18' on line 1072

  -- Looks like a reference, but probably isn't: '19' on line 1074

  -- Looks like a reference, but probably isn't: '20' on line 1077

  -- Looks like a reference, but probably isn't: '21' on line 1080

  -- Looks like a reference, but probably isn't: '22' on line 1083

  -- Looks like a reference, but probably isn't: '23' on line 1085

  -- Looks like a reference, but probably isn't: '24' on line 1088

  -- Looks like a reference, but probably isn't: '25' on line 1091

  -- Looks like a reference, but probably isn't: '26' on line 1093

  -- Looks like a reference, but probably isn't: '27' on line 1095

  == Outdated reference: A later version (-06) exists of
     draft-ietf-httpbis-http2-secondary-certs-04

  -- 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: 1 error (**), 0 flaws (~~), 2 warnings (==), 30 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                          October 30, 2019
5	Expires: May 2, 2020

7	              Use Cases and Requirements for Web Packages
8	                 draft-yasskin-webpackage-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	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 [1].

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

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 https://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 May 2, 2020.

41	Copyright Notice

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

121	1.  Introduction

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

131	   Previous attempts at packaging web resources (e.g.  Resource Packages
132	   [3] and the W3C TAG's packaging proposal [4]) were motivated by
133	   speeding up the download of resources from a single server, which is
134	   probably better achieved through other mechanisms like HTTP/2 PUSH,
135	   possibly augmented with a simple manifest of URLs a page plans to use
136	   [5].  This attempt is instead motivated by avoiding a connection to
137	   the origin server at all.  It may still be useful for the earlier use
138	   cases, so they're still listed, but they're not primary.

140	2.  Use cases

142	   These use cases are in rough descending priority order.  If use cases
143	   have conflicting requirements, the design should enable more
144	   important use cases.

146	2.1.  Essential

148	2.1.1.  Offline installation

150	   Alex can download a file containing a website (a PWA [6]) including a
151	   Service Worker from origin "O", and transmit it to their peer Bailey,
152	   and then Bailey can install the Service Worker with a proof that it
153	   came from "O".  This saves Bailey the bandwidth costs of transferring
154	   the website.

156	   There are roughly two ways to accomplish this:

158	   1.  Package just the Service Worker Javascript and any other
159	       Javascript that it importScripts() [7], with their URLs and
160	       enough metadata to synthesize a
161	       navigator.serviceWorker.register(scriptURL, options) call [8],
162	       along with an uninterpreted but signature-checked blob of data
163	       that the Service Worker can interpret to fill in its caches.

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

168	   Associated requirements for just the Service Worker:

170	   o  Indexed by URL: The "register()" and "importScripts()" calls have
171	      semantics that depend on the URL.

173	   o  Signing as an origin: To prove that the file came from "O".

175	   o  Signing uses existing TLS certificates: So "O" doesn't have to
176	      spend lots of money buying a specialized certificate.

178	   o  Cryptographic agility: Today's algorithms will eventually be
179	      obsolete and will need to be replaced.

181	   o  Certificate revocation: "O"'s certificate might be compromised or
182	      mis-issued, and the attacker shouldn't then get an infinite
183	      ability to mint packages.

185	   o  Downgrade prevention: "O"'s site might have an XSS vulnerability,
186	      and attackers with an old signed package shouldn't be able to take
187	      advantage of the XSS forever.

189	   o  Metadata: Just enough to generate the "register()" call, which is
190	      less than a full W3C Application Manifest.

192	   Additional associated requirements for packaged resources:

194	   o  Indexed by URL: Resources on the web are addressed by URL.

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

200	   o  Response headers: The meaning of a resource is heavily influenced
201	      by its HTTP response headers.

203	   o  Resources from multiple origins in a package: So the site can be
204	      built from multiple components (Section 2.2.4).

206	   o  Metadata: The browser needs to know which resource within a
207	      package file to treat as its Service Worker and/or initial HTML
208	      page.

210	2.1.1.1.  Online use

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

215	2.1.1.2.  Fully offline use

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

222	   Associated requirements beyond Offline installation:

224	   o  Packaged validity information: Even without a direct internet
225	      connection, Bailey should be able to check that their package is
226	      still valid.

228	2.1.2.  Offline browsing

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

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

240	   Associated requirements beyond Offline installation:

242	   o  Random access: To avoid needing a long linear scan before using
243	      the content.

245	   o  Compress stored packages: So that more content can fit on the same
246	      storage device.

248	2.1.3.  Save and share a web page

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

259	   Associated requirements:

261	   o  Unsigned content: A client can't sign content as another origin.

263	   o  Resources from multiple origins in a package: General web pages
264	      include resources from multiple origins.

266	   o  Indexed by URL: Resources on the web are addressed by URL.

268	   o  Response headers: The meaning of a resource is heavily influenced
269	      by its HTTP response headers.

271	2.1.4.  Privacy-preserving prefetch

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

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

289	   Two search engines have built systems to do this with today's
290	   technology: Google's AMP [9] and Baidu's MIP [10] formats and caches
291	   allow them to prefetch search results while preserving privacy, at
292	   the cost of showing the wrong URLs for the results once the user has
293	   clicked.  A good solution to this problem would show the right URLs
294	   but still avoid a request to the publishing origin until after the
295	   user clicks.

297	   Associated requirements:

299	   o  Signing as an origin: To prove the content came from the original
300	      origin.

302	   o  Streamed loading: If the user clicks before the target page is
303	      fully transferred, the browser should be able to start loading
304	      early parts before the source site finishes sending the whole
305	      page.

307	   o  Compress transfers

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

314	2.2.  Nice-to-have

316	2.2.1.  Packaged Web Publications

318	   The W3C's Publishing Working Group [11], merged from the
319	   International Digital Publishing Forum (IDPF) and in charge of EPUB
320	   maintenance, wants to be able to create publications on the web and
321	   then let them be copied to different servers or to other users via
322	   arbitrary protocols.  See their Packaged Web Publications use cases
323	   [12] for more details.

325	   Associated requirements:

327	   o  Indexed by URL: Resources on the web are addressed by URL.

329	   o  Signing as an origin: So that readers can be sure their copy is
330	      authentic and so that copying the package preserves the URLs of
331	      the content inside it.

333	   o  Downgrade prevention: An early version of a publication might
334	      contain incorrect content, and a publisher should be able to
335	      update that without worrying that an attacker can still show the
336	      old content to users.

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

342	   Other requirements are similar to those from Offline installation:

344	   o  Random access: To avoid needing a long linear scan before using
345	      the content.

347	   o  Compress stored packages: So that more content can fit on the same
348	      storage device.

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

354	   o  Response headers: The meaning of a resource is heavily influenced
355	      by its HTTP response headers.

357	   o  Signing uses existing TLS certificates: So a publisher doesn't
358	      have to spend lots of money buying a specialized certificate.

360	   o  Cryptographic agility: Today's algorithms will eventually be
361	      obsolete and will need to be replaced.

363	   o  Certificate revocation: The publisher's certificate might be
364	      compromised or mis-issued, and an attacker shouldn't then get an
365	      infinite ability to mint packages.

367	2.2.2.  Avoiding Censorship

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

375	   Today it's straightforward to retrieve blocked content from a third
376	   party, but there's no guarantee that the third-party has sent the
377	   user an accurate representation of the content: the user has to trust
378	   the third party.

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

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

389	   Associated requirements:

391	   o  Indexed by URL: So the user can see that they're getting the
392	      content they expected.

394	   o  Signing as an origin: So that readers can be sure their copy is
395	      authentic and so that copying the package preserves the URLs of
396	      the content inside it.

398	2.2.3.  Third-party security review

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

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

412	   Associated requirements:

414	   o  Additional signatures

416	2.2.4.  Building packages from multiple libraries

418	   Large programs are built from smaller components.  In the case of the
419	   web, components can be included either as Javascript files or as
420	   "<iframe>"d subresources.  In the first case, the packager could copy
421	   the JS files to their own origin; but in the second, it may be
422	   important for the "<iframe>"d resources to be able to make same-
423	   origin [13] requests back to their own origin, for example to
424	   implement federated sign-in.

426	   Associated requirements:

428	   o  Resources from multiple origins in a package: Each component may
429	      come from its own origin.

431	   o  Deduplication of diamond dependencies: If we have dependencies
432	      A->B->D and A->C->D, it's important that a request for a D
433	      resource resolves to a single resource that both B and C can
434	      handle.

436	2.2.4.1.  Shared libraries

438	   In ecosystems like Electron [14] and Node [15], many packages may
439	   share some common dependencies.  The cost of downloading each package
440	   can be greatly reduced if the package can merely point at other
441	   dependencies to download instead of including them all inline.

443	   Associated requirements:

445	   o  External dependencies

447	2.2.5.  Cross-CDN Serving

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

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

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

466	   Associated requirements:

468	   o  Streamed loading: To get optimal performance, the browser should
469	      be able to start loading early parts of a resource before the
470	      distributor finishes sending the whole resource.

472	   o  Signing as an origin: To prove the content came from the original
473	      origin.

475	   o  Compress transfers

477	2.2.6.  Pre-installed applications

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

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

493	   If multiple browsers supported an unsigned web package format, with
494	   an option to trust it as if it were signed if it's in a particular
495	   section of the filesystem that's as protected as the browser's
496	   executable, and if registering a Service Worker from a page inside a
497	   package passed the full package contents to the Service Worker's
498	   "install" event, the device manufacturer could provide web packages
499	   for each pre-installed application that would work in the user's
500	   chosen browser.

502	   Associated requirements:

504	   o  Service Worker integration: To pass the package into the "install"
505	      event and from there get its contents into a "Cache".

507	2.2.7.  Protecting Users from a Compromised Frontend

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

522	   Not all application developers should choose to require signed
523	   updates, since doing so adds the risk of losing the signing key, but
524	   having this option gives security-sensitive applications like
525	   Dashlane [16] an incentive to build native apps instead of web apps.

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

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

537	   Note that HPKP has been turned off in Chromium [17] because it was
538	   difficult to use and made it too easy to "brick" a website.  To
539	   reduce the chance of bricking the website, this key pinning design
540	   could require an active Service Worker before enforcing the pins.  It
541	   could also avoid the need for users to take manual action to recover
542	   from a lost signing key by allowing a new key to be used if it's seen
543	   consistently for a site-chosen amount of time, instead of waiting for
544	   the whole pin to expire.  However, these mitigations don't guarantee
545	   that browsers would find the tradeoffs more acceptable than they did
546	   for HPKP.

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

553	   Associated requirements:

555	   o  Signing without origin trust: To let a backend system vouch for
556	      the content.  This would likely be augmented with origin trust by
557	      receiving the signed content over TLS.

559	   o  Streamed loading: To get optimal performance, the browser should
560	      be able to start loading early parts of a resource before the
561	      server finishes sending the whole resource.

563	2.2.8.  Installation from a self-extracting executable

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

571	   Associated requirements:

573	   o  Trailing length

575	2.2.9.  Packages in version control

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

582	   Associated requirements:

584	   o  Binary

586	2.2.10.  Subresource bundling

588	   Text based subresources often benefit from improved compression
589	   ratios when bundled together.

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

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

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

602	   3.  Loss of module semantics - ES6 modules must be delivered as
603	       independent resources.  Therefore, current bundling methods,
604	       which deliver them with other resources under a common URL,
605	       require transpilation to ES5 and result in loss of ES6 module
606	       semantics.

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

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

618	   Associated requirements:

620	   o  Indexed by URL
621	   o  Streamed loading: To solve downside 1.

623	   o  Compress transfers: To keep the upside.

625	   o  Response headers: At least the Content-Type is needed to load JS
626	      and CSS.

628	   o  Unsigned content: Signing same-origin content wastes space.

630	2.2.11.  Archival

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

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

646	   Associated requirements:

648	   o  Indexed by URL

650	   o  Response headers: To accurately record the server's response.

652	   o  Unsigned content: To deal with expired signatures.

654	   o  Time-shifting execution

656	3.  Requirements

658	3.1.  Essential

660	3.1.1.  Indexed by URL

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

665	3.1.2.  Request headers

667	   Resource keys should include request headers like "accept" and
668	   "accept-language", which allows content-negotiated resources to be
669	   represented.

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

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

679	3.1.3.  Response headers

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

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

688	3.1.4.  Signing as an origin

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

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

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

703	   In any cryptographic system, the specification is responsible to make
704	   correct implementations easier to deploy than incorrect
705	   implementations (Section 3.1.12).

707	3.1.5.  Random access

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

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

715	3.1.6.  Resources from multiple origins in a package

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

720	3.1.7.  Cryptographic agility

722	   Obsolete cryptographic algorithms can be replaced.

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

728	3.1.8.  Unsigned content

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

733	3.1.9.  Certificate revocation

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

738	3.1.10.  Downgrade prevention

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

743	3.1.11.  Metadata

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

749	3.1.12.  Implementations are hard to get wrong

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

755	   o  Explicitly specifying a cryptographic algorithm identifier in
756	      [RFC7515] made it easy for implementations to trust that
757	      algorithm, which caused vulnerabilities [19].

759	   o  [ZIP]'s duplicate specification of filenames makes it easy for
760	      implementations to check the signature of one copy but use the
761	      other [20].

763	   o  Following Langley's Law [21] when possible makes it hard to deploy
764	      incorrect implementations.

766	3.2.  Nice to have

768	3.2.1.  Streamed loading

770	   The browser can load a package as it downloads.

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

774	3.2.2.  Signing without origin trust

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

781	3.2.3.  Additional signatures

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

785	3.2.4.  Binary

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

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

792	3.2.5.  Deduplication of diamond dependencies

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

798	3.2.6.  Old crypto can be removed

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

803	3.2.7.  Compress transfers

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

809	3.2.8.  Compress stored packages

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

813	3.2.9.  Subsetting and reordering

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

818	3.2.10.  Packaged validity information

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

823	3.2.11.  Signing uses existing TLS certificates

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

829	3.2.12.  External dependencies

831	   Sub-packages can be "external" to the main package, meaning the
832	   browser will need to either fetch them separately or already have
833	   them.  (#35, App Installer Story [22])

835	3.2.13.  Trailing length

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

840	   This conflicts with [MHTML].

842	3.2.14.  Time-shifting execution

844	   In some unsigned packages, Javascript time-telling functions should
845	   return the timestamp of the package, rather than the true current
846	   time.

848	   We should explore if this has security implications.

850	3.2.15.  Service Worker integration

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

857	4.  Non-goals

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

863	4.1.  Store confidential data

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

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

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

879	4.2.  Generate packages on the fly

881	   See discussion at WICG/webpackage#6 [23].

883	4.3.  Non-origin identity

885	   A package can be primarily identified as coming from something other
886	   than a Web Origin [24].

888	4.4.  DRM

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

894	4.5.  Ergonomic replacement for HTTP/2 PUSH

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

901	   Trying to bundle resources in order to speed up page loads has a long
902	   history, including Resource Packages [25] from 2010 and the W3C TAG's
903	   packaging proposal [26] from 2015.

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

909	   o  [I-D.vkrasnov-h2-compression-dictionaries] should allow individual
910	      small resources to be compressed as well as they would be in a
911	      bundle.

913	   o  [I-D.ietf-httpbis-cache-digest] tells the server which resources
914	      it doesn't need to PUSH.

916	   Associated requirements:

918	   o  Streamed loading: If the whole package has to be downloaded before
919	      the browser can load a piece, this will definitely be slower than
920	      PUSH.

922	   o  Compress transfers: Keep up with
923	      [I-D.vkrasnov-h2-compression-dictionaries].

925	   o  Indexed by URL: Resources on the web are addressed by URL.

927	   o  Request headers: PUSH_PROMISE [27] ([RFC7540], section 6.6)
928	      includes request headers.

930	   o  Response headers: PUSHed resources include their response headers.

932	5.  Security Considerations

934	   The security considerations will depend on the solution designed to
935	   satisfy the above requirements.  See
936	   [I-D.yasskin-dispatch-web-packaging] for one possible set of security
937	   considerations.

939	6.  IANA Considerations

941	   This document has no actions for IANA.

943	7.  References

945	7.1.  Informative References

947	   [I-D.burke-content-signature]
948	              Burke, B., "HTTP Header for digital signatures", draft-
949	              burke-content-signature-00 (work in progress), March 2011.

951	   [I-D.cavage-http-signatures]
952	              Cavage, M. and M. Sporny, "Signing HTTP Messages", draft-
953	              cavage-http-signatures-12 (work in progress), October
954	              2019.

956	   [I-D.ietf-httpbis-cache-digest]
957	              Oku, K. and Y. Weiss, "Cache Digests for HTTP/2", draft-
958	              ietf-httpbis-cache-digest-05 (work in progress), July
959	              2018.

961	   [I-D.ietf-httpbis-http2-secondary-certs]
962	              Bishop, M., Sullivan, N., and M. Thomson, "Secondary
963	              Certificate Authentication in HTTP/2", draft-ietf-httpbis-
964	              http2-secondary-certs-04 (work in progress), April 2019.

966	   [I-D.thomson-http-content-signature]
967	              Thomson, M., "Content-Signature Header Field for HTTP",
968	              draft-thomson-http-content-signature-00 (work in
969	              progress), July 2015.

971	   [I-D.vkrasnov-h2-compression-dictionaries]
972	              Krasnov, V. and Y. Weiss, "Compression Dictionaries for
973	              HTTP/2", draft-vkrasnov-h2-compression-dictionaries-03
974	              (work in progress), March 2018.

976	   [I-D.yasskin-dispatch-web-packaging]
977	              Yasskin, J., "Web Packaging", draft-yasskin-dispatch-web-
978	              packaging-00 (work in progress), June 2017.

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

984	   [JAR]      "JAR File Specification", 2014,
985	              <https://docs.oracle.com/javase/7/docs/technotes/guides/
986	              jar/jar.html>.

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

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

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

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

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

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

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

1019	   [ServiceWorkers]
1020	              "Service Workers Nightly", W3C ED, n.d.,
1021	              <https://w3c.github.io/ServiceWorker/>.

1023	   [W3C.WD-appmanifest-20170828]
1024	              Caceres, M., Christiansen, K., Lamouri, M., Kostiainen,
1025	              A., and R. Dolin, "Web App Manifest", World Wide Web
1026	              Consortium WD WD-appmanifest-20170828, August 2017,
1027	              <https://www.w3.org/TR/2017/WD-appmanifest-20170828>.

1029	   [ZIP]      "APPNOTE.TXT - .ZIP File Format Specification", October
1030	              2014, <https://pkware.cachefly.net/webdocs/casestudies/
1031	              APPNOTE.TXT>.

1033	7.2.  URIs

1035	   [1] https://mailarchive.ietf.org/arch/search/?email_list=art

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

1039	   [3] https://www.mnot.net/blog/2010/02/18/resource_packages

1041	   [4] https://w3ctag.github.io/packaging-on-the-web/

1043	   [5] https://lists.w3.org/Archives/Public/public-web-
1044	       perf/2015Jan/0038.html

1046	   [6] https://developers.google.com/web/progressive-web-apps/checklist

1048	   [7] https://w3c.github.io/ServiceWorker/#importscripts

1050	   [8] https://w3c.github.io/ServiceWorker/#navigator-service-worker-
1051	       register

1053	   [9] https://www.ampproject.org/

1055	   [10] https://www.mipengine.org/

1057	   [11] https://www.w3.org/publishing/groups/publ-wg/

1059	   [12] https://www.w3.org/TR/pwp-ucr/#pwp

1061	   [13] https://html.spec.whatwg.org/multipage/origin.html#same-origin

1063	   [14] https://electron.atom.io/

1065	   [15] https://nodejs.org/en/

1067	   [16] https://app.dashlane.com/

1069	   [17] https://groups.google.com/a/chromium.org/d/topic/blink-
1070	        dev/he9tr7p3rZ8/discussion

1072	   [18] https://twitter.com/anjacks0n/status/950861384266416134

1074	   [19] https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-
1075	        standard-that-everyone-should-avoid

1077	   [20] https://nakedsecurity.sophos.com/2013/07/10/anatomy-of-a-
1078	        security-hole-googles-android-master-key-debacle-explained/

1080	   [21] https://blog.gerv.net/2016/09/introducing-deliberate-protocol-
1081	        errors-langleys-law/

1083	   [22] https://github.com/WICG/webpackage/issues/35

1085	   [23] https://github.com/WICG/webpackage/
1086	        issues/6#issuecomment-275746125

1088	   [24] https://html.spec.whatwg.org/multipage/browsers.html#concept-
1089	        origin

1091	   [25] https://www.mnot.net/blog/2010/02/18/resource_packages

1093	   [26] https://w3ctag.github.io/packaging-on-the-web/

1095	   [27] http://httpwg.org/specs/rfc7540.html#PUSH_PROMISE

1097	Appendix A.  Acknowledgements

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

1102	Author's Address

1104	   Jeffrey Yasskin
1105	   Google

1107	   Email: jyasskin@chromium.org