W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2017

Re: SRI and signatures

From: Daniel Vogelheim <vogelheim@chromium.org>
Date: Tue, 12 Dec 2017 17:44:10 +0100
Message-ID: <CALG6KPPprmoXVz1QyGP9yxUmYS5NdXO6Rz4i4gh8Zj6WJazoMw@mail.gmail.com>
To: public-webappsec@w3.org
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
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?

Received on Tuesday, 12 December 2017 16:57:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:55:02 UTC