Proposal: Signatures in SRI.

TL;DR: I'd appreciate feedback on a proposal for a small, signature-based
extension to SRI and CSP
<https://github.com/w3c/webappsec-subresource-integrity/blob/master/signature-based-restrictions-explainer.markdown>
.

In talking to some folks internally at Google, we've found some use cases
for SRI in combination with CSP for some applications that the security
team is particularly interested in locking down. Prototypes of this
combined mechanism work the way they expect, but turning those prototypes
into production will be quite difficult, given the dependencies on shared
code written by several distinct teams and some additional requirements for
out-of-band delivery that aren't directly relevant to this proposal.

Signatures seem like they would provide some of the same benefits, with
real deployment advantages. It seems like these advantages might be
applicable to other folks' projects as well, so I've written up a small
explainer at
https://github.com/w3c/webappsec-subresource-integrity/blob/master/signature-based-restrictions-explainer.markdown
in the hopes of gauging interest. I'd appreciate y'all taking a look.

We've talked about extending SRI with signatures a few times over the
years, and a few folks have put together different proposals for doing so
(the thread at https://github.com/w3c/webappsec/issues/449 contains a few
examples). Mine is a fairly narrow approach in comparison with some other
suggestions, which I hope is a feature. :)

In broad strokes, I'd suggest the following:

1.  We add support for Ed25519 in `integrity` attributes and CSP source
expressions (e.g. `<script src="whatever.js" integrity='ed25519-[public
key]'>`).

2.  We add support for a server-side mechanism of delivering an Ed25519
signature along with a resource (e.g. a new `Signature:
ed25519-[signature]` header).

3.  We use the signature in the integrity attribute to verify the signature
in the header after receiving the resource (much as we do for hashes today).

WDYT?

-mike