Provenance vs. content

[mozfreddyb]

I know the spec text already touches on this, but we would like to provide an additional piece of concern.

Hashed content provides a direct connection between the author of the HTML and the expected resource. Regardless of the author and the serving infrastructure.

Provenance only provides a connection to an opaque holder of a private key.
While key is intended as a countersignature from the author of the resource, it might as well be held by the CDN itself.

In essence, the provenance guarantee is completely opaque to the user, the website and the browser.

[mikewest]

I certainly agree that hashes and keys have different properties, but I'm not sure I understand the implications of your claims here. Do you have a suggestion for changes to the document's text that could help clarify?

To your specific claims:

While key is intended as a countersignature from the author of the resource, it might as well be held by the CDN itself.

In the model proposed here, the document's author makes a decision about the keys they choose to trust with the ability to execute code on their page. By doing so, they're able to instruct the browser to enforce the integrity of their supply chain, ensuring that key possession is a necessary condition for code execution. You're certainly correct that the key may be held by anyone, and it's reasonable for developers to therefore make careful decisions about the keys they choose to trust. Is that something we should make clearer in the spec?

In essence, the provenance guarantee is completely opaque to the user, the website and the browser.

I don't understand this claim. First, any integrity claim (hashes, signatures, divine intervention, etc) is opaque to the user as I don't think any user agent provides a user-facing signal around integrity checks (nor does that seem initially valuable). Second, the guarantee isn't opaque; it requires key possession when minting the response. The value of that assertion might vary depending on the qualities of the private key (is it held offline or in an HSM as part of your build process? is is published publicly on your website's homepage?), but that's precisely the decision that the website author makes when choosing a (set of) key(s) to trust.

[mozfreddyb]

Right, I think this boils down to how informed the decision is:
When someone decides to include a third-party script with SRI, right now, they essentially pin a resource to its content. Something the author can audit once and the browser will always verify.
But when choosing a public key, the decision is to trust in those that share their public key - regardless of how the private key is held.

[mikewest]

I'd frame it as a distinction between verifying the integrity of a specific resource on the one hand, and verifying the integrity of a developer's chosen supply chain on the other. I certainly agree that those integrity checks have different properties, and developers would reasonably choose one or the other depending on their needs.