Making the RCH hash function reference more explicit #70
Conversation
iherman
requested review from
msporny,
martyr280,
Wind4Greg and
seabass-labrax
as code owners
index.html
Outdated
| SHA-2 with 256 bits of output is utilized. For P-384 keys, SHA-2 with 384-bits | ||
| of output is utilized. | ||
| When the RDF Dataset Canonicalization Algorithm (RDFC-1.0) [[RDF-CANON]] is used with ECDSA | ||
| algorithms, the cryptographic hashing function used by RDFC-1.0 MUST depend on the size of |
There was a problem hiding this comment.
This first MUST seems a bit awkward now that the following sentences have the more clarifying and more obviously testable MUSTs in them. Can we do this?:
| algorithms, the cryptographic hashing function used by RDFC-1.0 MUST depend on the size of | |
| algorithms, the cryptographic hashing function used by RDFC-1.0 depends on the size of |
Approving either way.
There was a problem hiding this comment.
It does read a bit better now, but I still think the first MUST is unnecessary because it isn't specific -- it's the following two sentences that make the specific asks of implementations. I'd still change it from "MUST depend" to just "depends".
There was a problem hiding this comment.
I have no idea what happened, but it seems as @TallTed's change proposals, that I thought I accepted, did not make it into the branch (I may have pushed the "resolve" button too quickly.) I re-did his editings manually.
To avoid misunderstandings, this is the text now:
When the RDF Dataset Canonicalization Algorithm (RDFC-1.0) [[RDF-CANON]] is used
with ECDSA algorithms, the cryptographic hashing function used by RDFC-1.0 MUST
be chosen based on the size of the associated public key. For P-256 keys, the
default hashing function, SHA-2 with 256 bits of output, MUST be used. For P-384
keys, SHA-2 with 384-bits of output MUST be used, specified via the RDFC-1.0
implementation-specific parameter.
In this text I believe all MUST-s are justified. @dlongley, can you look at it again?
(Sorry for my clumsiness...)
There was a problem hiding this comment.
No worries! I left a suggestion and an explanation for it. I approve either way, but I think my suggestion improves things from a testability perspective.
Co-authored-by: Dave Longley <dlongley@digitalbazaar.com>
|
Editorial, multiple reviews, changes requested and made, no objections, merging. |
This PR proposes the changes described in #69.
Preview | Diff