Who Is Strongest?

[otherdaniel]

Subresource Integrity specifies to get the strongest metadata from the set of supplied SRI constraints, but unfortunately forgot to mention what strongest means in this context. This would be reasonably intuitive for 3 hash functions from the same family (shaXXX-*), but would already break down for hash functions from a different family, or for something entirely different, like a digital signature scheme.

For practical purposes, it's likely best to define strongest as loosely being newest, since that would allow a deployment scenario where you can add try out the latest scheme by adding it to the main resource, without having to worry about which clients support it.

[otherdaniel]

Alternatively, one could give up the notion of "strongest" in favour of the order (or another explicit criteria), to let the page author express their intent.

[devd]

hmm .. is this a bug in SRI or in the signatures + SRI part?

If you are only talking about hashes and strongest, SRIv1 IIRC intentionally doesn't go into who is strongest. The idea is that the browser can and should pick. Relative strengths of hash functions change over time as attacks are found and new hash functions discovered. The UA should pick (or the web app author can use only the ones they want).

Or is there something specific about the Signatures bit you are asking about? Its not clear (to me) in the current writeup if a server can respond with multiple signatures (See #8 ). Assuming multiple signatures are allowed, then I think we can still leave it to the UA to use the strongest signature it can find or fail (or do something else)

[mikewest]

Closing this in favor of https://github.com/w3c/webappsec-subresource-integrity/pull/126, as it's more about SRI than signatures specifically.