VC cryptographic suites recommendation

[rghiorghisor]

• [x] I have read the CLA Document and I hereby sign the CLA.

---

Are there any cryptographic suites recommendations? And if not should there be?

Both VC issuers and VC verifies need to be able to implement the crypto algorithms correctly, and making recommendations might help. In order to clarify this, I've added more details below about cryptographic suites and a pending implementation question regarding alternatives, that is "How/What canonicalization algorithm to be used?"

W3C Verifiable Credentials and proofs

The W3C Verifiable Credentials specification does not concern itself with details about the implementation of proofs but makes references to the specifications that do so:

• Data Integrity [https://w3c-ccg.github.io/data-integrity-spec/]
• Linked Data Cryptographic Suites Registries [https://w3c-ccg.github.io/ld-cryptosuite-registry/]
• Verifiable Credentials Extension Registry [https://w3c-ccg.github.io/vc-extension-registry/]

What are Cryptographic Suites?

According to the above 3. "Cryptographic Suites" section of Verifiable Credential Data Integrity 1.0, a cryptographic suite is the entity that specifies how proofs can be created and verified by implementers, and knowing the suite's name must be enough for developers to initiate the creation or verification process.

In the 1.1 "How it works" section of the same specification, the following workflows are depicted for proof creation and validation respectively

Therefor, besides many more, a cryptographic suites's specification needs to answer at least the following questions:

1. How is the proof (signature) represented in a W3C Verifiable Credential?
2. How is the verification material represented and how it can be retrieved?
3. What are the algorithms used for Transformation, Hashing, and Proof Verification?

Alternatives

A cryptographic suite specifies 3 algorithms. If the Hashing (digest algorithm) and Proof Verification (signature algorithm) are standard, the Transformation (JSON/JSON-LD canonicalization algorithm) is somewhat on shaky ground.

Example

Let's compare these two:

• EdDSA Cryptosuite v2020 https://www.w3.org/community/reports/credentials/CG-FINAL-di-eddsa-2020-20220724
• JCS Ed25519 Signature 2020 https://identity.foundation/JcsEd25519Signature2020/

The question on which one to use stems from the transformation algorithm they use and how will this be received by W3C Verifiable Credentials verifiers.

From their specifications, the following algorithms must be used:

EdDSA Cryptosuite v2020			JCS Ed25519 Signature 2020
canonicalization Algorithm	https://w3id.org/security#URDNA2015	RDF-DATASET-NORMALIZATION	canonicalization Algorithm	JSON Canonicalization Scheme (JCS)	JCS
digest Algorithm	SHA-256	RFC6234	digest Algorithm	SHA-256	RFC6234
signature Algorithm	Edwards-Curve Digital Signature Algorithm (EdDSA)	RFC8032	signature Algorithm	Ed25519	RFC8032

As it can be seen above, the only difference is the canonicalization algorithm, i.e the algorithm that handles the normalization of the JSON document to look the same for all involved entities (signer and verifier). A small analysis of both of them:

• URDNA2015 (or RDFC-1.0) is an algorithm that is based on RDF Datasets and implies: transforming the JSON to a RDF Dataset as per specification and applying the canonicalization algoritm per RDF Dataset Canonicalization specification;
  • Advantages:
  • The algorithm is considered preferred for JSON-LD formats, as it is possible for JSON-LD to have different forms but represent the same data;
  • W3C Verifiable Credentials are JSON-LD documents, thus this algorithm follows proper standards;
  • Disadvantages:
  • The JSON-LD to RDF Dataset and RDF Dataset canonicalization processes are complex algorithms to implement that will take a significant amount of time to implement, in addition to the domain knowledge required;
  • There are very few implementation APIs that can make life easier for developers and their usage is not verified;
• JSON Canonicalization Scheme is a simple algorithm, that deals only with JSON formats as is based on transforming the JSON document using simple ordering operations;
  • Advantages: Simple algorithm that has support in many languages: JSON Canonicalization Scheme (JCS). Even if support is not available for a language, implementing it is not difficult;
  • Disadvantages:
  • No support for JSON-LD. Per JCS Ed25519 Signature 2020 specification: "This suite is not compatible with JSON-LD.";
  • Specifications are very vague with regard to what the input for the canonicalization algorithm must be, the alternatives being the JSON document for the JSON-LD extended document.

Please also note, that the challenges that come with choosing the cryptographic suite concern both VC issuers, but also any verifier that needs to validate VCs, thus adoption must also be considered.

The 5.10 "Canonicalization Method Security" section of Verifiable Credential Data Integrity 1.0 is vague about the choice:

If an application only uses JSON and does not depend on any form of RDF semantics, then using a cryptography suite that uses JSON Canonicalization Scheme [RFC8785] is an attractive approach.

If an application uses JSON-LD and needs to secure the semantics of the document, then using a cryptography suite that uses RDF Dataset Canonicalization [RDF-CANON] is an attractive approach.

Conclusion & Questions

The following questions need answering:

1. Does CAWG have any recommendations with regard to the cryptographic suites for W3C Verifiable Credentials?
2. Does CAWG have any recommendations with regard to the JSON canonicalization algorithm to use?
3. Would the above analysed ed25519-cryptosuite-2020 implementations be suitable for recommendations?
4. Does manifest verification and plugins have any preference or restrictions with implementing/adopting the above mentioned algorithms?

Additional notes

• Changing cryptographic suites should not be an issue as long the verifiers support those cryptographic suites;
• Bonus: If JSON Canonicalization Scheme (JCS) is used, should it be applied on VC as a JSON or on the JSON-LD expanded form? As stated, we found the standards to be vague about this and a clear and definitive answer was not found.

[Francisc]

Hi, @OR13. Would you be able to advise here, please?

[OR13]

I don't recommend using any form of data integrity proofs.

I recommend ES256 mandatory, EdDSAEd25519 optional, for JWT, SD-JWT, and COSE.

[rghiorghisor]

Thank you for the input @OR13! What would be the concerns in using embedded proofs? Me, myself I don't have a bias towards or against any of embedded or enveloping proofs. The embedded ones seem a little bit more natural, but that's neither here or there.

[puhley]

The C2PA specification denotes which cryptographic primitives are allowed at their level. There is the question whether CAWG needs to be a superset/subset/equivalent to their requirements to simplify things for implementors. https://c2pa.org/specifications/specifications/2.0/specs/C2PA_Specification.html#_cryptography. At this time, the C2PA list is a superset of this list. However, it should be noted that the C2PA specification states, "Ed25519 instance only. No other EdDSA instances are allowed." Therefore, there could potentially be a divergence in the future.