Make the possibility of changing the hash function a SHOULD?
iherman opened this issue · comments
We know that RDFC has been criticized on the ground of using SHA-256. Whether this is justified or not, it is not for me to say; I am not an expert on hash functions. The fact remains that it is a point of "vulnerability".
Our current answer is in the (terminology section)[https://www.w3.org/TR/rdf-canon/#dfn-hash-algorithm]:
The default hash algorithm used by RDFC-1.0, namely, SHA-256 [FIPS-180-4].
Implementations can be written to parameterize the hash algorithm without any other changes. Using a different hash algorithm will generally result in different output than using the default.
In the specification itself, it only says:
By default, RDFC-1.0 uses the SHA-256 hash algorithm [FIPS-180-4].
My feeling is that these statements are weak in view of the context. In my view, we should say somewhere in the spec (probably in §4.1) that
- Implementation SHOULD be written in a way that the hash algorithm can be parametrized
- If such a parametrization is built in the implementation, at the minimum SHA-384 MUST be provided as an alternative.
(And we can say something about future versions, which may mandate other alternatives.)
Actually, I would not be shocked to see SHOULD be a MUST.
Note that, at this stage, this is an editorial change only, that does not jeopardize the fate of the spec: we have two tests which check the usage of SHA-384, and we already have three implementations that pass these tests. I.e., we are ready to go to REC even with MUST.
This was resolved in the meeting on 2023-09-11 https://www.w3.org/2023/09/11-rch-minutes.html#r01