search

w3c / vc-di-ecdsa

Data Integrity specification for ECDSA using NIST-compliant curves
https://w3c.github.io/vc-di-ecdsa/
Other
9 stars 9 forks source link

Add which cryptographic hash function to use for RDF-CANON. #36

Closed msporny closed 10 months ago

msporny commented 10 months ago

This PR attempts to address issue #32 by explicitly stating which hash function should be passed to RDF-CANON and stating that verification methods should be fetched and cached early in the process.

Preview | Diff

msporny commented 10 months ago

Remove second paragraph on RDFC parameters. The hash used in RDFC is separate from the hashing used for signatures.

While SHA2-256 has been demonstrated to be adequate for the foreseeable future, there are individuals that continue to believe that 384 bits of security is necessary, and if so, that those parameters should apply all the way down to the canonicalization algorithm. That is why this PR is being raised -- to address concerns that 384 bits of security can be used everywhere that cryptographic hashing is performed, even down into RDFC-1.0.

Wind4Greg commented 10 months ago

Do we have to remove P-384 support then? The RDFC spec only has SHA-256 defined. Also the library that RDFC library that I use only supports SHA-256 so I wouldn't be able to generate the P-384 test vectors until that library was updated. I looked at the RDF spec but it really didn't say why a secure hash was being used or why SHA-256 (128 bits of security).

msporny commented 10 months ago

Do we have to remove P-384 support then?

No, I expect removing P-384 support will lead to objections.

The RDFC spec only has SHA-256 defined. Also the library that RDFC library that I use only supports SHA-256 so I wouldn't be able to generate the P-384 test vectors until that library was updated.

We'll have to make sure the library you are using supports P-384 as an option to use when the c14n algorithm is running.

I looked at the RDF spec but it really didn't say why a secure hash was being used or why SHA-256

The hashing algorithm is used when hashing the paths and doing comparisons, and it's extremely unlikely that there would be a collision there using SHA-256... that said, people will argue that we're not matching the cryptographic hash function strength across the board, and that's the purpose of this PR -- to avoid having to have that debate (even though SHA-2 256 is perfectly fine to use on the path calculations, with SHA-384 on the canonicalized quads).

All this to say, we need to support P-384 and SHA-2 384 all the way down into RDFC-1.0.

msporny commented 10 months ago

Normative, multiple reviews, changes requested and made, no objections, merging.