- From: Jeffrey Yasskin <jyasskin@google.com>
- Date: Tue, 05 Dec 2017 21:19:43 +0000
- To: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CANh-dXkgss_Mt0F4hv5fBcrHUJ6=BO7o5u2OCWzxJom=xAiJ0w@mail.gmail.com>
Hi all, I've published https://tools.ietf.org/id/draft-yasskin-http-origin-signed-responses-01.html to follow up on https://lists.w3.org/Archives/Public/ietf-http-wg/2017JulSep/0385.html with a concrete proposal for the Signature header. I made several choices in this design where another tradeoff would be totally plausible. Let me know where you'd prefer something different. Some interesting aspects of this update: * The signature covers the URL, so it's really a signed "exchange" rather than just a signed response. * To simplify the Signed-Headers header, it's not possible to customize which parts of the request are included in the signature. Exactly the method and effective request URI are included. * The signing key can either be a certificate's key or a raw ed25519 public key. The first supports origin-trusted certificates and other complex forms of trust, while the second supports https://github.com/mikewest/signature-based-sri and other ways a public key might be trusted out-of-band. Attentive folks will notice that this means signed exchanges are no longer necessarily *origin*-signed. * Certificate chains are fetched and cached from a URL rather than bundled into the Signature header. Normal use is likely to Push the chain for a group of signed exchanges. * There's a way to update the signatures for a response without re-fetching the whole response. I'll be updating https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html as you point out things I should change. Thanks, Jeffrey
Received on Tuesday, 5 December 2017 21:20:21 UTC