digestAlgorithm should be sha512

[blearyalarm]

According t rfc8419 section 2.3, the digest must be SHA512.

[dlongley]

The cryptosuite defined by the spec in this repository is unrelated to CMS (Cryptographic Message Syntax).

[blearyalarm]

Can you please explain how to understand this?

The Ed25519 2018 signature suite MUST be used in conjunction with the signing and verification algorithms in the Linked Data Signatures [LD-SIGNATURES] specification. The suite consists of the following algorithms:

Parameter	Value	Specification
canonicalizationAlgorithm	https://w3id.org/security#URDNA2015	[RDF-DATASET-NORMALIZATION]
digestAlgorithm	http://w3id.org/digests#sha256	[RFC6234]
signatureAlgorithm	http://w3id.org/security#ed25519	[ED25519]

My understanding is: First, use the canonicalization algorithm to normalize the message body. Then use the digest algorithm to digest the message. Then sign the digested message with ed25519 primary key.

If it is not related, how to understand this table? Sorry, I'm new to this.

[dlongley]

@blearyalarm,

Sorry, I'm new to this.

No worries! Also, it's important to note that this spec is an input into the yet to be launched new W3C Verifiable Credentials Working Group and that group will be revising and improving it -- or potentially combining it with other similar specs.

My understanding is: First, use the canonicalization algorithm to normalize the message body. Then use the digest algorithm to digest the message. Then sign the digested message with ed25519 primary key.

That's almost right. This spec layers on top of the Data Integrity spec, previously known as the Linked Data Signatures spec. Following a link to the LD signatures spec (now renamed), the Create Verify Hash section details what needs to be done to produce the bytes that are digitally signed and / or verified. The short version is:

1. Remove any existing proof property from the document that is to be signed. (This is to allow independently generated proofs to be attached to the same document).
2. Canonize the resulting document using the canonicalization algorithm.
3. Create another document that holds all of the proof options (all proof meta data such as created date, verification method identifier, so on) and canonize it (using the canonicalization algorithm).
4. Hash the canonized proof options document using the hash algorithm (SHA-256) producing a 32 byte digest.
5. Hash the canonized resulting document using the hash algorithm (SHA-256) and append the resulting 32 byte digest to the digest from the previous step, producing a 64 byte value to be signed.
6. Sign the 64 byte value using the signature algorithm (PureEdDSA) using the ed25519 private key.

Therefore, the hashing algorithm is used to hash the canonized proof options and the canonized document. The proof options are signed along with the document so that every input value is covered by the signature -- so there are effectively two parts of the "message" that are combined together prior signing. The parts are each hashed before concatenating them to ensure that they are encapsulated, i.e., that they do not mix in unexpected ways (if part of the proof options could somehow be confused with part of the document being signed).

The resulting 64 bytes forms the actual "message" that is to be given to the signing primitive. In the case of this signature suite, that message is not additionally hashed at all, rather, the PureEdDSA algorithm is used (which involves no pre-hashing of the "message").

Finally, the RFC you mentioned (RFC 8419) has to do with an entirely different and unrelated format for data: CMS (Cryptographic Message Syntax). That spec requires SHA-512 to be used on an eContent value which is defined over in RFC 5652. This involves taking data expressed using ASN.1 and DER and hashing it.

The cryptosuite defined here is for signing JSON-LD / RDF / Linked Data, not CMS / ASN.1 / DER formatted data, so it has a different approach for creating the message that is to be passed to the signing primitive -- and happens to use a different hashing algorithm.

Additionally, all of the above is different from whatever hashing algorithms happen to be used internally by Ed25519. So, there are many layers here.

[blearyalarm]

Thanks a lot. Now I understand.

[peacekeeper]

I remember this also confused me once. The way I think about it now is: First SHA256 during RDF canonicalization and hashing, and then SHA512 internally during Ed25519 signing.

@blearyalarm do you want to close the issue, or do you still have more questions/thoughts about this?

[blearyalarm]

Thanks, close now.