子资源完整性的草案规范很简单：

本文档指定了这样一个验证方案，扩展了两个 HTML 元素，其完整性属性包含作者期望加载的资源表示的加密散列。

这样的解决方案是一个非常静态的解决方案。如果可靠的提供商想要更改他们的 JavaScript，他们必须更新完整性哈希并将其分发给所有可能的用户。本质上，该地址处的对象最好永远不要改变。如果你更新你的资源，你应该给它一个新地址和它的新哈希。（这让我想到了IPFS，但我离题了。）在（几乎）最坏的情况下，聪明但无知的 Web 开发人员将在任何给定时刻从托管的任何文档动态生成散列。

不过，我对这种方法持怀疑态度——我可以向您发送一份使用我的私钥签名的文档，而您拥有我的公钥，就可以信任该文档的谱系，就像您相信我的公钥是我的一样。有没有办法在不破坏安全性的情况下利用非对称密钥签名为 Web 开发人员提供更好的体验？

假设，如果（而不是 SRI）以下行为被嵌入到 Web 用户代理中，安全影响会是什么：

主 Web 服务器响应将包括映射到其子资源的公钥列表。预计这些资源将是签署的文件。如果不是，或者如果签名与预期的密钥不匹配，用户代理将采取类似于 SRI 草案规范建议的保护措施。

最终，我试图了解在这种情况下提供每个文档的静态哈希如何比密钥签名更好。