Those sources can then be other less-secure protocols, even those unanticipated by the referrer, because the client got the necessary verifier via the secure-path.
Browsers definitely don't cache across origins by this though.
If they did, would it be possible to create a malicious JavaScript file with the same MD5 as jQuery?
You definitely wouldn't use MD5, as experts have been recommending against its use for content-security since about 1996.[2] (A practical full chosen-preimage attack hasn't yet been developed, but still, you'd design for security for the next few decades, which would mean a SHA256 or better.) The choice of a good hash would mean no one could practically create an alternate file with the same hash.
Any file can be modified to result in a hash collision with a specific MD5. This makes is unsuitable for its stated purpose as a cryptographic hash.
The solution would be to use a newer and stronger hash like Keccak.
A solution similar to what you are thinking of is already used by Bittorrent's Distributed Hash Table to identify files.
https://en.wikipedia.org/wiki/MD5#Preimage_vulnerability
MD5 should absolutely not be used for this content-identification purpose or any other new code... and wise designers haven't been using it for 10+ years. I'm just mentioning this to be precise about the current state of its proven weaknesses.
The security folks I talk to are... nervous... about this use of subresource integrity, however.
1. Integrity
You want to make sure the data you're getting is from the source you expect, and that it hasn't been compromised. HTTPS does this with PKI by enabling you to verify the destination host is really who they say they are (Certificates) and to only trade data with them. Anybody who doesn't pass the signed-certificate-verifying test, doesn't get to give us data.
2. Secrecy
We don't want anyone else knowing what our data is because it may contain sensitive information. Once we verify the identity of the sender, each session is independently encrypted to prevent later decoding.
So what would we need to cache our content and retain its integrity and secrecy? The simplest thing would be encrypted blobs of data signed by our destination host's certificate. A proxy could keep data for a set amount of time, perhaps each piece of data encapsulated in a different session. All our client would need to do was connect once and initiate a session, and the server could deliver a copy of the encrypted/signed payload to the proxy.
With some magic flags in the new protocol our client could be instructed that the server allows the client to make a 'proxy request' to the destination for content. This request could be made in such a way that it allows a proxy to intercept this request from the client (which could be plaintext actually), get the encrypted chunk from the destination (which could also be done plaintext), and the proxy could deliver the chunk to the client, similar to what it does now with HTTP. Since the chunk was signed and encrypted by the destination, the proxy can't do anything but deliver the exact copy the destination gave it. Our client receives the data it wants from the proxy and verifies it's from the destination, unpacks it and loads it.
1. Client requests content from server (HTTPS)
2. Server replies back that server allows proxy requests (HTTPS)
3. Client sends request again with proxy-request flags and arbitrary content identifier & session identifier (HTTP)
4. Proxy receives request, gets content from server (HTTP)
5. Proxy replies to client delivering content from server (HTTP)
6. Client verifies content was signed by server
If you are going to use HTTPS, you need to use it for all content on that domain. Otherwise if you load for example a large javascript file over HTTP, the attacker can just poison that file and control your whole page.
Even if you loaded an image from the same domain, your credentials would sent sent as a cookie in plain text.
You could use a separate domain for content as explained here: http://stackoverflow.com/a/5160657/804713