Description
I would like to ask to extent the possibilities of SRI, by adding some form of signature-checking.
This would most probably be a 'version 2.0' request ;).
Why?
Currently webdevelopers (of the websites including a script) are only possible to add a SRI if they exactly know what the integrity-hash is of a script. For instance:
<script src="https://example.com/example-framework.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
crossorigin="anonymous"></script>
This is great, if you trust only the developer (of the included script) for a specific version of a script. Though, in practice, sometimes you actually want to trust the developer a bit more, allowing him to change the script a bit, without you wanting to update for every single version. But you might still not trust the CDN hosting it.
Adding the ability to not only add a HASH, but also adding some form of fingerprinting could help.
For instance:
<script src="https://example.com/example-framework.js"
integrity="fingerprint-pgp-43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8"
crossorigin="anonymous"></script>
On the hosting side this would obviously also need a change: the file needs to be signed.
This might be done for instance in a header:
Integrity-fingerprint:pgp-43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8
Integrity-fingerprint-signature:oqexampleVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC
This way the webdeveloper (of the websites including a script) knows for sure that the javascript itself has the integrity as specified, while the javascript-developer can do an update to the script without needing to wait for every webdeveloper to start using the update.
Advantages
Versioning becomes more easy. Also Tag Managers (like Google Tag Manager) might finally be able to use SRI.
Security-level Change (and the disadvantage)
For the matter of trusting the CDN there is no change, a CDN operator (or attacker that takes of the CDN or is MiTM) still can't create a SRI that is valid when manipulating the script.
But this is less secure than the actual SRI-integrity hash, obviously. You explicitly trust the developer of the script in this case. So should only be used in the scenario's where you actually trust that developer.
However, if you run a large website, being able to enforce SRI, while having one or two scripts that lean on fingerprinting instead of hashing, might proof a better security model than not being able to enforce at all.
Content-Security-Policy: require-sri-for script style