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