Concrete format for signed responses

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