If you include content produced by a third party (e.g. JQuery) off a CDN, right now you can use the hash-based SRI mechanism to make sure that only the exact file you specified can be included, otherwise the CDN could suddenly send any compromised code. The file can't be changed, because otherwise the hash wouldn't match.

With a signature, you could specify "include cdn.com/jquery-X if signed by the JQuery project", so JQuery could publish security updates and those could be rolled out to the CDNs and included in all pages automatically, without the siteowners having to make changes (if the security fix doesn't break compatibility).

For your own content, you'd mostly gain the convenience of not having to update the hashes on all the pages including the resource.

This is more convenient but less secure than a straight-up hash. If an attacker compromises the JQuery signing key, they could still serve malicious files. With a hash, the authenticity is ONLY dependant on the TLS connection to the main website, e.g. github.

TL;DR:

* hash: need to compromise the main website, that supplies (and authenticates) the hash

* signature by CDN: attacker can either compromise the main website OR <del>the third party CDN</del> <ins>author/signer of the third-party resource</ins>

(edit: correction as pointed out by response)

It would still help against compromise of the CDN, but not against compromise of the original source.

Of course it's a trade off. For stuff like Google Fonts, the Facebook like button etc I'd expect that hashes won't become common, because the effort of publishing changed hashes and embedding them into sites is to big.

Yes, it's nominally less secure but I trust the authors of major scripts (ex. the Facebook like button) to be able to keep their keys secure. If losing private keys is a major security concern, then TLS is also useless.

It's not "nominal"; losing private keys is a major security concern. No, "TLS is useless" does not follow from that - we have things like forward secrecy which are security models specifically designed to give some protection in the case of private key compromise.

(edit: e.g. see https://en.greatfire.org/blog/2015/sep/popular-chinese-ios-a... just out today)

Especially in the case of a library developer, they hold the keys to many websites, so there is extra incentive for an attacker to break that rather than "some random guy's website". The more third-party signers you trust, the more holes you (and your users) have.

Furthermore, you are forcing your users (who actually run this code) to place their trust in these parties too, which is not a great thing (transitive trust) to force upon someone. (This is not the case for e.g. depending on system libraries explicitly installed by the user.)