idnits 2.17.1 

draft-yasskin-webpackage-use-cases-01.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 (March 05, 2018) is 2244 days in the past.  Is this
     intentional?


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  == Outdated reference: A later version (-12) exists of
     draft-cavage-http-signatures-09

  == Outdated reference: A later version (-05) exists of
     draft-ietf-httpbis-cache-digest-03

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

  -- 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 (~~), 4 warnings (==), 28 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                            March 05, 2018
5	Expires: September 6, 2018

7	              Use Cases and Requirements for Web Packages
8	                 draft-yasskin-webpackage-use-cases-01

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 September 6, 2018.

41	Copyright Notice

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

117	1.  Introduction

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

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

136	2.  Use cases

138	   These use cases are in rough descending priority order.  If use cases
139	   have conflicting requirements, the design should enable more
140	   important use cases.

142	2.1.  Essential

144	2.1.1.  Offline installation

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

152	   There are roughly two ways to accomplish this:

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

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

164	   Associated requirements for just the Service Worker:

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

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

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

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

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

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

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

188	   Additional associated requirements for packaged resources:

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

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

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

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

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

206	2.1.1.1.  Online use

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

211	2.1.1.2.  Fully offline use

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

218	   Associated requirements beyond Offline installation:

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

224	2.1.2.  Offline browsing

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

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

236	   Associated requirements beyond Offline installation:

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

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

244	2.1.3.  Save and share a web page

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

255	   Associated requirements:

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

259	   o  Resources from multiple origins in a package: General web pages
260	      include resources from multiple origins.

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

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

267	2.2.  Nice-to-have

269	2.2.1.  Packaged Web Publications

271	   The W3C's Publishing Working Group [9], merged from the International
272	   Digital Publishing Forum (IDPF) and in charge of EPUB maintenance,
273	   wants to be able to create publications on the web and then let them
274	   be copied to different servers or to other users via arbitrary
275	   protocols.  See their Packaged Web Publications use cases [10] for
276	   more details.

278	   Associated requirements:

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

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

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

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

295	   Other requirements are similar to those from Offline installation:

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

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

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

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

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

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

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

320	2.2.2.  Avoiding Censorship

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

328	   Today it's straightforward to retrieve blocked content from a third
329	   party, but there's no guarantee that the third-party has sent the
330	   user an accurate representation of the content: the user has to trust
331	   the third party.

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

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

342	   Associated requirements:

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

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

351	2.2.3.  Third-party security review

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

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

365	   Associated requirements:

367	   o  Additional signatures

369	2.2.4.  Building packages from multiple libraries

371	   Large programs are built from smaller components.  In the case of the
372	   web, components can be included either as Javascript files or as
373	   "<iframe>"d subresources.  In the first case, the packager could copy
374	   the JS files to their own origin; but in the second, it may be
375	   important for the "<iframe>"d resources to be able to make same-
376	   origin [11] requests back to their own origin, for example to
377	   implement federated sign-in.

379	   Associated requirements:

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

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

389	2.2.4.1.  Shared libraries

391	   In ecosystems like Electron [12] and Node [13], many packages may
392	   share some common dependencies.  The cost of downloading each package
393	   can be greatly reduced if the package can merely point at other
394	   dependencies to download instead of including them all inline.

396	   Associated requirements:

398	   o  External dependencies

400	2.2.5.  Privacy-preserving prefetch

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

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

418	   Two search engines have built systems to do this with today's
419	   technology: Google's AMP [14] and Baidu's MIP [15] formats and caches
420	   allow them to prefetch search results while preserving privacy, at
421	   the cost of showing the wrong URLs for the results once the user has
422	   clicked.  A good solution to this problem would show the right URLs
423	   but still avoid a request to the publishing origin until after the
424	   user clicks.

426	   Associated requirements:

428	   o  Signing as an origin: To prove the content came from the original
429	      origin.

431	   o  Streamed loading: If the user clicks before the target page is
432	      fully transferred, the browser should be able to start loading
433	      early parts before the source site finishes sending the whole
434	      page.

436	   o  Compress transfers

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

443	2.2.6.  Cross-CDN Serving

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

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

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

462	   Associated requirements:

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

468	   o  Signing as an origin: To prove the content came from the original
469	      origin.

471	   o  Compress transfers

473	2.2.7.  Installation from a self-extracting executable

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

481	   Associated requirements:

483	   o  Trailing length

485	2.2.8.  Packages in version control

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

492	   Associated requirements:

494	   o  Binary

496	2.2.9.  Subresource bundling

498	   Text based subresources often benefit from improved compression
499	   ratios when bundled together.

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

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

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

512	   3.  Loss of module semantics - ES6 modules must be delivered as
513	       independent resources.  Therefore, current bundling methods,
514	       which deliver them with other resources under a common URL,
515	       require transpilation to ES5 and result in loss of ES6 module
516	       semantics.

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

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

528	   Associated requirements:

530	   o  Indexed by URL

532	   o  Streamed loading: To solve downside 1.

534	   o  Compress transfers: To keep the upside.

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

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

541	2.2.10.  Archival

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

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

557	   Associated requirements:

559	   o  Indexed by URL

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

563	   o  Unsigned content: To deal with expired signatures.

565	   o  Time-shifting execution

567	3.  Requirements

569	3.1.  Essential

571	3.1.1.  Indexed by URL

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

576	3.1.2.  Request headers

578	   Resource keys should include request headers like "accept" and
579	   "accept-language", which allows content-negotiated resources to be
580	   represented.

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

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

590	3.1.3.  Response headers

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

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

599	3.1.4.  Signing as an origin

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

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

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

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

618	   In any cryptographic system, the specification is responsible to make
619	   correct implementations easier to deploy than incorrect
620	   implementations (Section 3.1.12).

622	3.1.5.  Random access

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

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

630	3.1.6.  Resources from multiple origins in a package

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

635	3.1.7.  Cryptographic agility

637	   Obsolete cryptographic algorithms can be replaced.

639	   Planning to upgrade the cryptography also means we should include
640	   some way to know when it's safe to remove old cryptography
641	   (Section 3.2.5).

643	3.1.8.  Unsigned content

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

648	3.1.9.  Certificate revocation

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

653	3.1.10.  Downgrade prevention

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

658	3.1.11.  Metadata

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

664	3.1.12.  Implementations are hard to get wrong

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

670	   o  Explicitly specifying a cryptographic algorithm identifier in
671	      [RFC7515] made it easy for implementations to trust that
672	      algorithm, which caused vulnerabilities [17].

674	   o  [ZIP]'s duplicate specification of filenames makes it easy for
675	      implementations to check the signature of one copy but use the
676	      other [18].

678	   o  Following Langley's Law [19] when possible makes it hard to deploy
679	      incorrect implementations.

681	3.2.  Nice to have

683	3.2.1.  Streamed loading

685	   The browser can load a package as it downloads.

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

689	3.2.2.  Additional signatures

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

693	3.2.3.  Binary

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

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

700	3.2.4.  Deduplication of diamond dependencies

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

706	3.2.5.  Old crypto can be removed

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

711	3.2.6.  Compress transfers

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

717	3.2.7.  Compress stored packages

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

721	3.2.8.  Subsetting and reordering

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

726	3.2.9.  Packaged validity information

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

731	3.2.10.  Signing uses existing TLS certificates

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

737	3.2.11.  External dependencies

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

743	3.2.12.  Trailing length

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

748	   This conflicts with [MHTML].

750	3.2.13.  Time-shifting execution

752	   In some unsigned packages, Javascript time-telling functions should
753	   return the timestamp of the package, rather than the true current
754	   time.

756	   We should explore if this has security implications.

758	4.  Non-goals

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

764	4.1.  Store confidential data

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

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

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

780	4.2.  Generate packages on the fly

782	   See discussion at WICG/webpackage#6 [21].

784	4.3.  Non-origin identity

786	   A package can be primarily identified as coming from something other
787	   than a Web Origin [22].

789	4.4.  DRM

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

795	4.5.  Ergonomic replacement for HTTP/2 PUSH

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

802	   Trying to bundle resources in order to speed up page loads has a long
803	   history, including Resource Packages [23] from 2010 and the W3C TAG's
804	   packaging proposal [24] from 2015.

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

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

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

817	   Associated requirements:

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

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

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

828	   o  Request headers: PUSH_PROMISE [25] ([RFC7540], section 6.6)
829	      includes request headers.

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

833	5.  Security Considerations

835	   The security considerations will depend on the solution designed to
836	   satisfy the above requirements.  See
837	   [I-D.yasskin-dispatch-web-packaging] for one possible set of security
838	   considerations.

840	6.  IANA Considerations

842	   This document has no actions for IANA.

844	7.  References

846	7.1.  Informative References

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

852	   [I-D.cavage-http-signatures]
853	              Cavage, M. and M. Sporny, "Signing HTTP Messages", draft-
854	              cavage-http-signatures-09 (work in progress), November
855	              2017.

857	   [I-D.ietf-httpbis-cache-digest]
858	              Oku, K. and M. Nottingham, "Cache Digests for HTTP/2",
859	              draft-ietf-httpbis-cache-digest-03 (work in progress),
860	              February 2018.

862	   [I-D.ietf-httpbis-http2-secondary-certs]
863	              Bishop, M., Sullivan, N., and M. Thomson, "Secondary
864	              Certificate Authentication in HTTP/2", draft-ietf-httpbis-
865	              http2-secondary-certs-00 (work in progress), December
866	              2017.

868	   [I-D.thomson-http-content-signature]
869	              Thomson, M., "Content-Signature Header Field for HTTP",
870	              draft-thomson-http-content-signature-00 (work in
871	              progress), July 2015.

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

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

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

886	   [JAR]      "JAR File Specification", 2014,
887	              <https://docs.oracle.com/javase/7/docs/technotes/guides/
888	              jar/jar.html>.

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

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

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

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

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

912	   [ServiceWorkers]
913	              Russell, A., Song, J., Archibald, J., and M.
914	              Kruisselbrink, "Service Workers 1", World Wide Web
915	              Consortium WD WD-service-workers-1-20161011, October 2016,
916	              <https://www.w3.org/TR/2016/
917	              WD-service-workers-1-20161011>.

919	   [W3C.WD-appmanifest-20170828]
920	              Caceres, M., Christiansen, K., Lamouri, M., Kostiainen,
921	              A., and R. Dolin, "Web App Manifest", World Wide Web
922	              Consortium WD WD-appmanifest-20170828, August 2017,
923	              <https://www.w3.org/TR/2017/WD-appmanifest-20170828>.

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

929	7.2.  URIs

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

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

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

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

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

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

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

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

949	   [9] https://www.w3.org/publishing/groups/publ-wg/

951	   [10] https://www.w3.org/TR/pwp-ucr/#pwp

953	   [11] https://html.spec.whatwg.org/multipage/origin.html#same-origin

955	   [12] https://electron.atom.io/

957	   [13] https://nodejs.org/en/

959	   [14] https://www.ampproject.org/

961	   [15] https://www.mipengine.org/

963	   [16] https://twitter.com/anjacks0n/status/950861384266416134

965	   [17] https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-
966	        standard-that-everyone-should-avoid

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

971	   [19] https://blog.gerv.net/2016/09/introducing-deliberate-protocol-
972	        errors-langleys-law/

974	   [20] https://github.com/WICG/webpackage/issues/35

976	   [21] https://github.com/WICG/webpackage/
977	        issues/6#issuecomment-275746125

979	   [22] https://html.spec.whatwg.org/multipage/browsers.html#concept-
980	        origin

982	   [23] https://www.mnot.net/blog/2010/02/18/resource_packages

984	   [24] https://w3ctag.github.io/packaging-on-the-web/

986	   [25] http://httpwg.org/specs/rfc7540.html#PUSH_PROMISE

988	Appendix A.  Acknowledgements

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

993	Author's Address

995	   Jeffrey Yasskin
996	   Google

998	   Email: jyasskin@chromium.org