Re: [w3ctag/design-reviews] Signed Exchanges (#235)

I'm available in general at 8am PDT, but I'll be on vacation on April 24th. April 17 or May 1 should work. BlinkOn is April 18-19 in case you want to get in specifically before or after that.

https://github.com/w3ctag/design-reviews/issues/235#issuecomment-379423243: Public-Key-Pins, Strict-Transport-Security, and Expect-CT don't look like they can be used for replay attacks (downgrade for DoS, maybe, but that's different from the reason we block cookies), so I think I was right to skip them, although it's definitely possible that I missed other headers that I should have included. The summary of "stateful request header field" isn't exactly right, but I haven't been able to think of a better one: suggestions are welcome.

https://github.com/w3ctag/design-reviews/issues/235#issuecomment-379424440: Formatting my HTTP/1.1 wrong there is just a bug. I don't have automated tests for my RFC draft.

https://github.com/w3ctag/design-reviews/issues/235#issuecomment-379424835: 

1. I don't see a way to enforce that the exchange-signing certificate is issued by the same CA as the origin's TLS certificate(s). These things are [meant to be used offline](https://tools.ietf.org/html/draft-yasskin-webpackage-use-cases-01#section-2.1.1) without a connection to the TLS server.

2. I intend CAs to follow the same procedures when issuing an exchange-signing certificate as they follow when issuing a TLS certificate, including CAA. Where would you expect to find a statement to that effect?

3. Yes, previously discovered information about an origin should affect which certificates are accepted for signed exchanges.

4. Yes, static key pins should restrict exchange-signing certificates.

https://github.com/w3ctag/design-reviews/issues/235#issuecomment-379424926: I'm working on the bit of the explainer that describes the SW and HTTP cache integration. Expect this by Friday. The rough sketch is that prefetch should only go through the physical URL's SW, but a navigation has an effective redirect to the logical URL, at which point that load goes through the logical URL's SW, with probably an extra attribute on the event notifying it that the content has been pre-populated.

https://github.com/w3ctag/design-reviews/issues/235#issuecomment-379425103: Note that online revocation checks don't work in either the [offline](https://tools.ietf.org/html/draft-yasskin-webpackage-use-cases-01#section-2.1.1) or [privacy-preserving prefetch](https://tools.ietf.org/html/draft-yasskin-webpackage-use-cases-01#section-2.2.5) use cases. We're handling certificate revocation using stapled OCSP responses and content revocation using the maximum signature lifetime (7 days, the same as OCSP, for now). If you want to revoke a particular exchange without revoking other exchanges signed by the same certificate, update its [`validityUrl`](file:///Users/jyasskin/src/webpackage/draft-yasskin-http-origin-signed-responses.html#rfc.section.3.6) to remove the signature and stop posting new signatures there. Clients willing to take a round-trip will notice the missing signature at the `validityUrl`, but offline clients will have to wait for whatever expiration you picked for the signature.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/235#issuecomment-379461756