Re: SRI and signatures

Hi

I like both approaches. If the other approach has more traction, I think
that's fine. I do worry about signing headers though: in addition to the
issues with CDN etc per your email, I also think it is different from how
SRIv1 which only signs body. Is there a chance that the origin-signed HTTP
responses could make signing headers optional (or do they do this already)?

Are origin-signed HTTP responses implemented in any UA? That might be the
easiest way to check if they work for/hinder any use cases.

cheers
Dev


On 12 December 2017 at 08:44, Daniel Vogelheim <vogelheim@chromium.org>
wrote:

> Hi Dev, all,
>
> Thanks for looking into this!
>
> The IETF's HTTP group is currently looking at a related proposal in the
> context of web packaging, which has a good bit of overlap with the SRI
> proposal discussed here: Origin-signed HTTP Responses
> <https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html> specifies
> a (similar but different) way for HTTP responses to contain a digital
> signature. This could either be based on a TLS certificate - which is the
> main thrust of that proposal - but could also be an ed25519 key (unrelated
> to the TLS certificate hierarchy), as it is in SRI explainer posted here.
>
> We'd prefer to avoid multiple incompatible signature schemes for HTTP
> resources, and so we're looking into whether we can base our SRI ideas off
> of this other work instead. Generally, that proposal should be quite
> compatible with our ideas: Both make it a duty of the resource to supply
> its integrity information in a new header. In their case, they then
> serialize the exchange; in ours, we would require the integrity info either
> from an integrity=.. attribute, or via a content security policy.
>
> From what I'm seeing, there are two main structural differences between
> the signature-based-SRI explainer and the Origin-signed responses:
>
> - Origin-signed responses support multiple signature schemes. They support
> ed25519 keys (so you can use ephemeral keys with whatever key rotation
> scheme you see fit), but they also want to be able to tie their signatures
> to a specific origin via the existing TLS public key infrastructure.
> - They also sign some of the headers. This makes a lot of sense in their
> context (providing equivalence to a TLS connection in an offline package),
> but I worry this would make live hard for SRI for CDNs or other complex
> deployments, since then you need to guarantee that your CDN preserves
> (certain) headers.
>
> I'm particularly interested in any feedback whether adopting this new
> scheme would improve/hinder any specific use cases and if so, whether this
> suggests any changes. Any comments?
>
>
> Daniel
>