SRI: One resource, many representations.

[mikewest]

Given the prevalence of content negotiation schemes like https://www.igvita.com/2013/05/01/deploying-webp-via-accept-content-negotiation/, I worry a bit about the current MIME type syntax for integrity metadata. The previous syntax allowed each integrity metadata tuple to contain a distinct MIME type, which would, for instance, allow a server to return a WebP image rather than a PNG one for performance reasons if the UA supported it.

The current scheme has a single type, which applies to every algorithm/digest pair.

This might or might not be a reasonable limitation, but I'd like to see it explicitly considered, as I don't think I've seen any discussion of this impact.

/cc @igrigorik @yoavweiss @metromoxie @fmarier @mozfreddyb @devd

[annevk]

We did: https://lists.w3.org/Archives/Public/public-webappsec/2015Jan/0288.html At the time I concluded it could always be added later, is that not true anymore?

[mikewest]

I missed that thread, sorry. Thanks for dredging it up for me.

So the thought would be that type:XXX's position determines which items it applies to?

[yoavweiss]

It's fairly possible I'm missing something, but wouldn't the problem with conneg and SRI be that the hashes of the different representations would be different? Do we permit multiple hashes that some may not match the returned content? (I guess I could just go read the SRI processing model...)

[mikewest]

Maybe I should read the processing model. When I originally wrote the thing, I think this was in my head as something to support, but I haven't checked up on things to see where we've evolved. :)

As I noted, if you actively decide this isn't worth supporting, or is actively bad to support, great! Just note that explicitly in the spec somewhere.

[annevk]

@mikewest yes. @yoavweiss you can already have multiple hashes due to different hashing algorithms.

[yoavweiss]

@annevk - from does resource match metadataList it seems like only the strongest hash is picked and validated against (so there can only be one ). I believe that if there are multiple "strongest" hashes, the first or last one (based on the UA specific priority function) will get picked.

[annevk]

Right and if we ever wanted to support content negotiation you'd first filter on type and then on "strongest".

[joelweinberger]

I just wrote up that pull request to add a note about content negotiation.

[igrigorik]

Wait, is there a reason why we're restricting this discussion to content-type negotiation? "One resource, many representations" is a much broader concept. For example, the server may return different representations of the same resource based on any number of advertised request headers... e.g. CH.

To make this concrete, say I have an HTML resource which will vary based on advertised DPR, RW, and possibly MD request headers, how do I use SRI (or not?) for this asset?

[devd]

exactly. I think we should just change the algorithm to keep a list of hashes (still insisting on strongest hash function).

[joelweinberger]

To clarify, @devd, you're suggesting we keep a list of hashes, but only keep around the strongest hash algorithm? That is, if we have:
weakhash;deadbeef, stronghash;beefdead
weakhash;feebdaed, stronghash;daedfeeb

We'd keep around both lists, but only
stronghash;beefdead
stronghash;daedfeeb

That would sound reasonable to me, although it is technically independent of whether we should have separate option-expessions for each (but hey, why not if we're at that point?).

[devd]

yup, and I think the change is simple enough that we can even push it into v1. wdyt?

[fmarier]

Implementation-wise, it's not a huge change, but it's not a trivial one either. Considering the fact that v1 only has support for styles and scripts, are we going to run into problems if there is only a single valid hash value? If not, I'd suggest ensuring forward-compatibility in v1 and moving "list of hashes" to v2.

Regarding the way that we currently specify content-type via a single option. Should we revert back to tying the content-type to each hash value (e.g. sha256-deadbeef-text/css)? It sounds like that's what @mikewest is suggesting.