This document specifies such a validation scheme, extending two HTML elements with an integrity attribute that contains a cryptographic hash of the representation of the resource the author expects to load.
I'm skeptical of this approach, though – I can send you a document signed with my private key and you, having my public key, can trust the pedigree of that document as much as you trust my public key to be mine. Is there no way to leverage asymmetric key signing to provide a better experience for web developers without undermining security?
Hypothetically, what would be the security impact if (instead of SRI) the following behavior were baked into web user agents:
A primary web server response would include a list of public keys mapped to its subresources. Those resources would be expected to be signed documents. If not, or if the signature doesn't match the expected key, the user agent would take protective measures similar to what the SRI draft spec proposes.
Ultimately I'm trying to understand how providing static hashes of each document is better than key signing in this case.