From e49f193256c12dada01714a82a4b9a888e8f2d54 Mon Sep 17 00:00:00 2001 From: Jeffrey Yasskin Date: Wed, 11 Apr 2018 13:33:36 -0700 Subject: [PATCH] Fix more comments from Kinuko. --- explainer.md | 38 ++++++++++++++++++++++++++------------ 1 file changed, 26 insertions(+), 12 deletions(-) diff --git a/explainer.md b/explainer.md index 08ab5fc63..62f424560 100644 --- a/explainer.md +++ b/explainer.md @@ -20,11 +20,12 @@ TAG's Web Packaging Draft](https://w3ctag.github.io/packaging-on-the-web/)~~. - [Privacy-preserving prefetch](#privacy-preserving-prefetch) - [Packaged Web Publications](#packaged-web-publications) - [Third-party security review](#third-party-security-review) -- [Loading sketch](#loading-sketch) +- [Signed Exchange Loading Sketch](#signed-exchange-loading-sketch) - [Fetch the physical URL](#fetch-the-physical-url) - [Fetch the certificate chain](#fetch-the-certificate-chain) - [Signature verification](#signature-verification) - [Prefetching stops here](#prefetching-stops-here) + - [No nested signed exchanges](#no-nested-signed-exchanges) - [Caching the signed response](#caching-the-signed-response) - [Navigations and subresources redirect](#navigations-and-subresources-redirect) - [Matching prefetches with subresources](#matching-prefetches-with-subresources) @@ -124,7 +125,7 @@ logical URLs of their contained exchanges. We'll need to specify how browsers load both signed exchanges and bundles of exchanges. -For now, this explainer has [a sketch of how loading will work](#loading-sketch). +For now, this explainer has [a sketch of how loading will work](#signed-exchange-loading-sketch). ## Use cases @@ -243,7 +244,7 @@ third-party then signs either the exchanges in a package or the package as a whole using a certificate whose metadata reflects whichever property was reviewed for. -## Loading sketch +## Signed Exchange Loading Sketch When an **embedder** prefetches or embeds an enveloped signed exchange, or a client navigates from the embedder to an enveloped signed exchange, the @@ -319,6 +320,13 @@ cache entry that would be visible to the logical URL's server. Prefetches can and should process any `Link: <>; rel=preload` headers they find, as prefetches. If those point at signed exchanges, this process repeats. +### No nested signed exchanges + +To limit the complexity of the implementation, we're currently planning to +disallow signed exchanges that contain either signed exchanges or redirects. +This may change if use cases come up or if the implementation turns out to be +simpler than expected. + ### Caching the signed response If the signed exchange was requested as a navigation or subresource (i.e. *not* @@ -330,22 +338,27 @@ This *doesn't* happen if: request headers the client would use for a normal request in the same context. This prevents a malicious intermediate from sticking the wrong content-negotiated resource in the HTTP cache. -* There's a response in the HTTP (or preload?) cache with a newer Date header +* There's a response in the HTTP (or any?) cache with a newer Date header than the signed exchange's response. This prevents some downgrade attacks. In either of these cases, the client just skips to the redirect in the next step. -If we're still here, the signed exchange is put into the [preload -cache](https://github.com/whatwg/fetch/issues/590) and, if the response headers -allow it (and review of this explainer indicates it's a good idea), the [HTTP -cache](https://tools.ietf.org/html/rfc7234). +If we're still here, the signed exchange is put into a "use-once" cache similar +to the [preload cache](https://github.com/whatwg/fetch/issues/590) and, if the +response headers allow it (and review of this explainer indicates it's a good +idea), the [HTTP cache](https://tools.ietf.org/html/rfc7234). If we put the signed exchange in the HTTP cache, its freshness has to be bounded by the shorter of the normal HTTP cache lifetime or the signature's expiration. +This is more strict than the bound on cache freshness when it crosses a +certificate or OCSP response expiration in order to partially mitigate +[downgrade +attacks](https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#seccons-downgrades). For *later* loads of the logical URL (in particular, not the load that's -happening through the signed exchange, since it's fulfilled using the preload -cache), a stale entry can be revalidated in the following ways: +happening through the signed exchange, since it's fulfilled using the +above-mentioned "use-once" cache), a stale entry can be revalidated in the +following ways: * If the `Signature` is expired but the HTTP caching information is fresh, the client can fetch the `validityUrl `to update just the signature. It *must not* @@ -370,8 +383,9 @@ chose to return a signed exchange, so we currently think it doesn't need a second chance. If the request goes through a Service Worker (and caching wasn't skipped above), -the `FetchEvent` needs to include some notification that there's a response -available in the preload cache. We currently think the +the Service Worker will probably want the `FetchEvent` to include some +notification that there's a response available without a network request. It may +be reasonable to ship without this, but we currently think the [`preloadResponse`](https://w3c.github.io/ServiceWorker/#fetch-event-preloadresponse) field in `FetchEvent` may be enough, although this doesn't provide a place to tell the Service Worker about any differences between the signed exchange's