Sending expected headers & allowing public keys integrity

[homakov]

Here are two features I believe could be super useful.

1. If the integrity attribute is set, let's send it in the request header

<script integrity_no="sha256-sha" crossorigins=="anonymous" src="https://APP/sdk.js"></script>

Will add a header Integrity: sha256-sha. This way the APP server knows what version of SDK should be served and can route the request to specific file version. Now we must change the URL along to sdk-1.3.5.js every time new version is out. I don't think leaking expected integrity presents any security risk.

2. Allowing public keys (1 or more) to be used in integrity attribute e.g. integrity=ec25519-PUB & ec25519-PUB2 and the response must include Integrity-Signatures header with both of them (private keys could be stored on separate laptops of two developers making it harder to take over critical stuff like addthis.js (cough).

Actually, I'd love to see something general like setting public keys in the app/manifest.json and requiring signatures per every resource load, that would basically solve the web app trust problem, but SRI is a good start.

What are your thoughts? @mikewest @devd @fmarier @metromoxie

[annevk]

1 is a duplicate of #47.

[mozfreddyb]

And 2 is w3c/webappsec#449
Thank you for your comments, Egor. Closing this in favor of the original threads.

[annevk]

@mozfreddyb you should probably move that second thread here. I was sure I read about it before, but couldn't find it in this repository.