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.

Ok, I'm traveling on April 17, so let's shoot for May 1 then.

> #235 (comment): 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 header field" isn't exactly right, but I haven't been able to think of a better one: suggestions are welcome.

Cool. We listed those because they do affect state that a browser keeps about the origin. But I'm happy to see them allowed. Presumably then a signed exchange could set Public-Key-Pins or Strict-Transport-Security for the origin should the client later visit directly (within the header expiration, of course).

> #235 (comment): Formatting my HTTP/1.1 wrong there is just a bug. I don't have automated tests for my RFC draft.

> #235 (comment):

> 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 without a connection to the TLS server.

Understood that they have to work when completely offline, and if the recipient of the exchange is offline and has never interacted with the signing origin, then of course they have to rely solely on the content of the exchange. In my head I'm looking for ways to correlate signed exchanges with the origin when the client has previous interactions, since the exchange is using a different certificate than the origin's tls cert. A same CA restriction is probably not worth the trouble (and likely to cause CA lock-in/transition problems anyway).

> 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?

A statement isn't necessarily necessary. Since it's a new use of a certificate I was just checking. I do wonder if there's value in having a different CAA record for exchange signing certificates, so a domain could opt-out, for example, or use a different CA.

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

Cool. So a previously discovered (and not expired) HPKP header should be used to validate the key used in a signed exchange? (for clients respecting HPKP)

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

>#235 (comment): 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.

> #235 (comment): Note that online revocation checks don't work in either the offline or privacy-preserving prefetch 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 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.

Ok, I'll take another look at that.

-- 
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-379541038