Reference the IANA registry of hash names

[jb-wisemo]

IANA has a nice public name registry for hash algorithms, but with relatively few entries. Other open standard organizations may have more complete registries.

Rather than needing updates as new algorithms are standardized, the SRI specification should simply reference that IANA (or other) registry, with the proviso that any dash characters in the standardized algorithm name shall be omitted, and any letters converted to lower case. For example "SHA-256" becomes "sha256" consistent with the existing SRI specification text.

[annevk]

I don't think that's a good idea. SRI should only contain algorithms we plan to support.

[mozfreddyb]

I agree with @annevk here. We do not intend to support many more hash algorithms as of now. Whenever we do add more algorithms, we should add them individually depending on implementation progress so that the spec matches the reality.

[awwright]

Can you please explain how an algorithm being listed in the IANA registry implies it must be supported? That's not my understanding of how IANA registries work... as I understand, the registry is to standardize names and values that may grow over time, and doesn't necessarily imply support (otherwise it would have been written into the specification). This makes it appropriate for SRI to reference.

[annevk]

We're not using those names and we have no plans to use those names, so no.

[awwright]

@annevk Yes, I see that you're not using those names. This issue is proposing to use the registry instead. You said

SRI should only contain algorithms we plan to support

Can you please explain this?

[jb-wisemo]

To clarify, the proposal says to mechanically transform the names from the algorithm registry to match what the current SRI spec says for existing algorithms and fit the SRI use of a dash to terminate the algorithm name.

Also, the registry in question exists specifically for WebPKI and thus indicates hashes likely to be implemented in future browsers and browser versions anyway. This is consistent with the WebCrypto spec that says to support whatever is in the running browsers' cryptographic libraries.