[SRI] Inconsistent Integrity Metadata Conventions

[lgarron]

I tried testing SRI in Chrome by following the Integrity Metadata section. It appears to match RFC6920, but I had to make the following changes to get it to work:

• Change sha-256 to sha256
• Remove the first two replacements from sed in the example command (i.e. use the base 64 output from OpenSSL with the = signs removed and no other changes).

It might just be something we need to fix in Chrome, but Joel encouraged me file an issue to make sure that all the specs and implementations match at some point.

[devd]

I believe this goes back to the confusion between whether we want to use the CSP syntax or the ni:// IETF syntax. (http://tools.ietf.org/html/rfc6920)

In an ideal world, the CSP spec would have used the dash and everything would be nice. Right now, there is no clean solution. I am leaning towards using the CSP syntax (without the dash).

[briansmith]

Are you referring to the CSP hash-source syntax? If so, it is not too late to change it to make it have the dash. Browsers can also support the old dash-less syntax for compatibility in the short term (ideally, with a warning emitted).

Note, however, that http://tools.ietf.org/html/draft-ietf-websec-key-pinning-21 has the same dashless sha256 issue, and that can't be changed as easily. However, I think at least all the webappsec/HTML5 specs should be consistent with each other in this respect, for learnability's sake.

[devd]

yeah and the implementation is consistent right now. The question is: what should that consistent format be? dash or no dash? no dash means that existing CSP hash-source implementations don't need to be modified. dash means that we are consistent with the IETF "naming things with hashes" spec too.

[lgarron]

If we're planning to use the RFC6920 syntax (ni://) for SRI, matching it exactly sounds like the only sane solution from a developer's perspective (whom we should prefer over implementers).

Even if CSP remains different, at least it doesn't use ni://, so there is less potential for confusion/surprise.

[devd]

One of the things @metromoxie, @briansmith and I talked about is potentially using hash-source as a way to say "load this file with SRI hash as given" (and solve the CSP/XSS issue talked about on the thread multiple times). For that use case, there is some value to having the same syntax.

[mikewest]

FWIW, I plan to support both "sha-256" and "sha256" in Blink for both CSP and SRI: https://codereview.chromium.org/798043002/

Postel's law, etc.

[fmarier]

We support both in gecko as well and lowercase them too.

[devd]

awesome! that's really the best solution ;)

what should we say in the spec?

[mozfreddyb]

We discussed this in https://github.com/w3c/webappsec/pull/125 already. Let's keep it in one place, please.