This specification describes several Data Integrity Cryptosuites for use when generating a digital signature using Post-Quantum digital signature algorithms.

This specification is experimental, do not use it in any production setting.

Introduction

This specification defines several cryptographic suites for the purposes of creating and verifying proofs for Post-Quantum signatures, in conformance with the Data Integrity [[VC-DATA-INTEGRITY]] specification.

This specification uses either the RDF Dataset Canonicalization Algorithm [[RDF-CANON]] or the JSON Canonicalization Scheme [[RFC8785]] to transform the input document into its canonical form. It uses a hash based on SHA-2 [[RFC6234]] and appropriate to the security category as the message digest, and supports a number of different Post-Quantum signature algorithms with varying properties such as public key size, signature size, and computational and implementational complexity.

Terminology

Terminology used throughout this document is defined in the Terminology section of the [[[VC-DATA-INTEGRITY]]] specification.

A conforming proof is any concrete expression of the data model that complies with the normative statements in this specification. Specifically, all relevant normative statements in Sections [[[#data-model]]] and [[[#Algorithms]]] of this document MUST be enforced.

A conforming processor is any algorithm realized as software and/or hardware that generates or consumes a [=conforming proof=]. Conforming processors MUST produce errors when non-conforming documents are consumed.

This document contains examples of JSON and JSON-LD data. Some of these examples are invalid JSON, as they include features such as inline comments (`//`) explaining certain portions and ellipses (`...`) indicating the omission of information that is irrelevant to the example. Such parts need to be removed if implementers want to treat the examples as valid JSON or JSON-LD.

Data Model

The following sections outline the data model that is used by this specification to express verification methods, such as cryptographic public keys, and data integrity proofs, such as digital signatures.

Verification Methods

These verification methods are used to verify Data Integrity Proofs [[VC-DATA-INTEGRITY]] produced using the cryptographic key material for the various algorithms and parameter sets supported by this specification. The encoding formats for these key types are provided in this section. Lossless cryptographic key transformation processes that result in equivalent cryptographic key material MAY be used during the processing of digital signatures.

Multikey

The Multikey format, defined in [[[CID]]], is used to express public keys for the cryptographic suites defined in this specification.

The `publicKeyMultibase` property represents a Multibase-encoded Multikey expression of a public key.

Public Key Summary, all sizes in bytes.
Signature Name Varint Code Multi-Byte Prefix Raw Public Key Size
ML-DSA-44 0x1210 0x9024 1312
SLH-DSA-SHA2-128s 0x1220 0xa024 32
FALCON-512* 0x122c 0xac24 897
SQIsign-I* 0x122e 0xae24 65

The Multikey encoding of a public key for a signature supported by this specification MUST start with the corresponding multi-byte prefix for the signature named in [[[#MultiKeyTable]]] followed by the raw public key bytes. This multi-byte prefix is the varint expression of the varint code given in the previous table. The resulting value will have a byte length given by the raw public key size in the table plus the length of the multi-byte prefix. This value MUST then be encoded using the base-64-url alphabet, according to the Multibase section of [[[CID]]] and then prepended with the base-64-url Multibase header (`u`).

Examples of all the `publicKeyMultibase` encodings defined in this specification can be found in appendix [[[#TestVectors]]].

Note*: The codes given in [[[#MultiKeyTable]]] for FALCON-512 and SQIsign-I are preliminary and not currently registered with multicodecs. When these signature schemes are formalized by NIST or other SDOs these values should be updated/registered.

Proof Representations

This section details the proof representation formats that are defined by this specification.

DataIntegrityProof

A proof contains the attributes specified in the Proofs section of [[VC-DATA-INTEGRITY]] with the following restrictions.

The `type` property of the proof MUST be `DataIntegrityProof`.

The `cryptosuite` property of the proof MUST be one of the following values from [[[#CryptosuiteTable]]].

Cryptosuites.
Name Signature Algorithm Signature Length
`mldsa44-rdfc-2024` ML-DSA-44 2420
`mldsa44-jcs-2024` ML-DSA-44 2420
`slhdsa128-rdfc-2024` SLH-DSA-SHA2-128s 7856
`slhdsa128-jcs-2024` SLH-DSA-SHA2-128s 7856
`falcon512-rdfc-2024` FALCON-512 666
`falcon512-jcs-2024` FALCON-512 666
`sqisign1-rdfc-2024` SQIsign-I 148
`sqisign1-jcs-2024` SQIsign-I 148

The value of the `proofValue` property of the proof MUST be a signature produced by the signature algorithm corresponding to the `cryptosuite` given in [[[#CryptosuiteTable]]]. This signature is produced according to using the algorithms specified in section [[[#Algorithms]]], then encoded using the base-64-url-nopad header and alphabet as described in the Multibase section of [[VC-DATA-INTEGRITY]].

Examples of the `proofValue` for all the cryptosuites defined in this specification can be found in appendix [[[#TestVectors]]].

Algorithms

The following sections describe multiple Data Integrity cryptographic suites that utilize quantum safe signature algorithms at different claimed security categories. For a given claimed security category, an appropriate hash function MUST be use in the [[[#HashingAlg]]].

From [[[NIST-SP-800-57-Part-1R6]]], Section 4.6.1.4 on the "Security Strengths of Hash Functions, XOFs, and Their Applications," the following hash function are chosen for use with digital signatures in [[[#HashSigTable]]].

Hashes for Signatures.
Security Strength Hash Function
Category 1 or 2 SHA-256
Category 3 or 4 SHA-384
Category 5 SHA-512

This specification supports cryptosuites based on both the Universal RDF Dataset Canonicalization Algorithm [[RDF-CANON]], `rdfc` and JSON Canonicalization Scheme [[RFC8785]], `jcs`. When the RDF Dataset Canonicalization Algorithm [[RDF-CANON]] is used with the [[[#ProofConfigurationAlg]]] and [[[#TransformationAlg]]] algorithms the cryptographic hashing function that is passed to the algorithm MUST be from [[[#HashSigTable]]] appropriate for the claimed security of the signature scheme.

Implementations SHOULD fetch and cache verification method information as early as possible when adding or verifying proofs. Parameters passed to functions in this section use information from the verification method — such as the public key size — to determine function parameters — such as the cryptographic hashing algorithm.

When the RDF Dataset Canonicalization Algorithm [[RDF-CANON]] is used, implementations of that algorithm will detect dataset poisoning by default, and abort processing upon detection.

Common Algorithms

Hashing

The following algorithm specifies how to cryptographically hash a transformed data document and proof configuration into cryptographic hash data that is ready to be provided as input to the algorithms for proof serialization and proof verification of each of the respective cryptosuites.

The required inputs to this algorithm are a transformed data document (|transformedDocument|), canonical proof configuration (|canonicalProofConfig|), and hash name (|hashName|). A single hash data value represented as a series of bytes is produced as output.

  1. If |hashName| is `SHA-256`, let |transformedDocumentHash| be the result of applying the SHA-256 (SHA-2 with 256-bit output) cryptographic hashing algorithm [[RFC6234]] to the respective |transformedDocument|. Respective |transformedDocumentHash| will be exactly 32 bytes in size.
  2. If |hashName| is `SHA-384`, let |transformedDocumentHash| be the result of applying the SHA-384 (SHA-2 with 384-bit output) cryptographic hashing algorithm [[RFC6234]] to the respective |transformedDocument|. Respective |transformedDocumentHash| will be exactly 48 bytes in size.
  3. If |hashName| is `SHA-512`, let |transformedDocumentHash| be the result of applying the SHA-512 (SHA-2 with 512-bit output) cryptographic hashing algorithm [[RFC6234]] to the respective |transformedDocument|. Respective |transformedDocumentHash| will be exactly 64 bytes in size.
  4. If |hashName| is `SHA-256`, let |proofConfigHash| be the result of applying the SHA-256 (SHA-2 with 256-bit output) cryptographic hashing algorithm [[RFC6234]] to the |canonicalProofConfig|. Respective |proofConfigHash| will be exactly 32 bytes in size.
  5. If |hashName| is `SHA-384`, let |proofConfigHash| be the result of applying the SHA-384 (SHA-2 with 384-bit output) cryptographic hashing algorithm [[RFC6234]] to the |canonicalProofConfig|. Respective |proofConfigHash| will be exactly 48 bytes in size.
  6. If |hashName| is `SHA-512`, let |proofConfigHash| be the result of applying the SHA-512 (SHA-2 with 512-bit output) cryptographic hashing algorithm [[RFC6234]] to the |canonicalProofConfig|. Respective |proofConfigHash| will be exactly 64 bytes in size.
  7. Let |hashData| be the result of joining |proofConfigHash| (the first hash) with |transformedDocumentHash| (the second hash).
  8. Return |hashData| as the hash data.

Proof Configuration

The following algorithm specifies how to generate a proof configuration from a set of proof options that is used as input to the proof hashing algorithm.

The required inputs to this algorithm are proof options (|options|), a cryptosuite identifier (|cryptosuite|), the canonicalization scheme (|canonScheme|) and hash name (|hashName|). The proof options MUST contain a type identifier for the cryptographic suite (|type|) and MUST contain the cryptosuite identifier (|cryptosuite|). A proof configuration object is produced as output.

  1. Let |proofConfig| be a clone of the |options| object.
  2. If |proofConfig|.|type| is not set to `DataIntegrityProof`, |proofConfig|.|cryptosuite| is not set to the cryptosuite, or both, an `INVALID_PROOF_CONFIGURATION` error MUST be raised.
  3. If |proofConfig|.|created| is set to a value that is not a valid [[XMLSCHEMA11-2]] datetime, an `INVALID_PROOF_DATETIME` error MUST be raised.
  4. Set |proofConfig|.|@context| to |unsecuredDocument|.|@context|.
  5. If |canonScheme| is `rdfc`, let |canonicalProofConfig| be the result of applying the Universal RDF Dataset Canonicalization Algorithm [[RDF-CANON]] to the |proofConfig|, with hashing parameter set to |hashName|.
  6. If |canonScheme| is `jcs`, let |canonicalProofConfig| be the result of applying the JSON Canonicalization Scheme [[RFC8785]] to the |proofConfig|.
  7. Return |canonicalProofConfig|.

Transformation

The following algorithm specifies how to transform an unsecured input document into a transformed document that is ready to be provided as input to the hashing algorithm in Section [[[#HashingAlg]]].

Required inputs to this algorithm are an unsecured data document (|unsecuredDocument|), transformation options (|options|), a cryptosuite identifier (|cryptosuite|), the canonicalization scheme (|canonScheme|) and hash name (|hashName|). The transformation options MUST contain a type identifier for the cryptographic suite (|type|) and a cryptosuite identifier (|cryptosuite|). A transformed data document is produced as output. Whenever this algorithm encodes strings, it MUST use UTF-8 encoding.

  1. If |options|.|type| is not set to the string `DataIntegrityProof`, |options|.|cryptosuite| is not set to the cryptosuite value, or both, then a `PROOF_TRANSFORMATION_ERROR` MUST be raised.
  2. If |canonScheme| is `rdfc`, let |canonicalDocument| be the result of applying the Universal RDF Dataset Canonicalization Algorithm [[RDF-CANON]] to the |unsecuredDocument| with hashing parameter set to |hashName|.
  3. If |canonScheme| is `jcs`, let |canonicalDocument| be the result of applying the JSON Canonicalization Scheme [[RFC8785]] to the |unsecuredDocument|.
  4. Set |output| to the value of |canonicalDocument|.
  5. Return |canonicalDocument| as the transformed data document.

Proof Serialization

The following algorithm specifies how to serialize a digital signature from a set of cryptographic hash data. This algorithm is designed to be used in conjunction with the algorithms defined in Section 4: Algorithms of the Data Integrity specification [[VC-DATA-INTEGRITY]]. Required inputs are cryptographic hash data (|hashData|), proof options (|options|), and a signature function (|sigFunc|). The proof options MUST contain a type identifier for the cryptographic suite (|type|) and MAY contain a cryptosuite identifier (|cryptosuite|). A single digital proof value represented as series of bytes is produced as output.

  1. Let |privateKeyBytes| be the result of retrieving the private key bytes (or a signing interface enabling the use of the private key bytes) associated with the verification method identified by the |options|.|verificationMethod| value.
  2. Let |proofBytes| be the result of applying the |sigFunc|, with |hashData| as the data to be signed using the private key specified by |privateKeyBytes|. |proofBytes| will have a length as indicated by the cryptosuite.
  3. Return |proofBytes| as the digital proof.

Proof Verification

The following algorithm specifies how to verify a digital signature from a set of cryptographic hash data. This algorithm is designed to be used in conjunction with the algorithms defined in Section 4: Algorithms of the Data Integrity [[VC-DATA-INTEGRITY]] specification. Required inputs are cryptographic hash data (|hashData|), a digital signature (|proofBytes|), proof options (|options|), and a verification function (|verifyFunc|). A verification result represented as a boolean value is produced as output.

  1. Let |publicKeyBytes| be the result of retrieving the public key bytes associated with the |options|.|verificationMethod| value as described in Section 4: Retrieve Verification Method of the Data Integrity specification [[VC-DATA-INTEGRITY]].
  2. Let |verificationResult| be the result of applying the |verifyFunc|, using the public key specified by |publicKeyBytes|, with |hashData| as the data to be verified against the |proofBytes|.
  3. Return |verificationResult| as the verification result.

Instantiate Cryptosuite

This algorithm is used to configure a cryptographic suite to be used by the Add Proof and Verify Proof functions in [[[VC-DATA-INTEGRITY]]]. The algorithm takes an options object ([=map=] |options|) as input and returns a [=data integrity cryptographic suite instance|cryptosuite instance=] ([=struct=] |cryptosuite|).

  1. Initialize |cryptosuite| to an empty [=struct=].
  2. If |options|.|type| does not equal `DataIntegrityProof`, return |cryptosuite|.
  3. If |options|.|cryptosuite| is `mldsa44-rdfc-2024` or `mldsa44-jcs-2024` then:
    1. Set |cryptosuite|.|createProof| to the algorithm in Section [[[#create-proof-ml-dsa]]].
    2. Set |cryptosuite|.|verifyProof| to the algorithm in Section [[[#verify-proof-ml-dsa]]].
  4. If |options|.|cryptosuite| is `slhdsa128-rdfc-2024` or `slhdsa128-jcs-2024` then:
    1. Set |cryptosuite|.|createProof| to the algorithm in Section [[[#create-proof-slh-dsa]]].
    2. Set |cryptosuite|.|verifyProof| to the algorithm in Section [[[#verify-proof-slh-dsa]]].
  5. If |options|.|cryptosuite| is `falcon512-rdfc-2024` or `falcon512-jcs-2024` then:
    1. Set |cryptosuite|.|createProof| to the algorithm in Section [[[#create-proof-falcon]]].
    2. Set |cryptosuite|.|verifyProof| to the algorithm in Section [[[#verify-proof-falcon]]].
  6. If |options|.|cryptosuite| is `sqisign1-rdfc-2024` or `sqisign1-jcs-2024` then:
    1. Set |cryptosuite|.|createProof| to the algorithm in Section [[[#create-proof-sqisign]]].
    2. Set |cryptosuite|.|verifyProof| to the algorithm in Section [[[#verify-proof-sqisign]]].
  7. Return |cryptosuite|.

ML-DSA Cryptosuites

The Module-Lattice-Based Digital Signature Standard defined in [[[FIPS-204]]] [[FIPS-204]] defines parameter sets for three different claimed security strengths. The claimed security strengths, private key, public key, and signature sizes are summarized in [[[#MLSummaryTable]]].

ML-DSA Signatures Summary, all sizes in bytes.
Name Security Private Key Public Key Signature
ML-DSA-44 Category 2 2560 1312 2420
ML-DSA-65 Category 3 4032 1952 3309
ML-DSA-87 Category 5 4896 2592 4627

Supporting both the Universal RDF Dataset Canonicalization Algorithm [[RDF-CANON]], "`rdfc`", the JSON Canonicalization Scheme [[RFC8785]], "`jcs`", and a maximum security category of 2, leads to the family of ML-DSA cryptosuites given in [[[#MLSuitesTable]]].

Supported ML-DSA Cryptosuites.
Name Canonalization Signature/Verification Hash
`mldsa44-rdfc-2024` RDFC ML-DSA-44 SHA-256
`mldsa44-jcs-2024` JCS ML-DSA-44 SHA-256

Create Proof (ML-DSA)

The following algorithm specifies how to create a [=data integrity proof=] given an unsecured data document and an ML-DSA cryptosuite chosen from [[[#MLSuitesTable]]]. The choice of cryptosuite sets the values of |canonScheme|, |hashName|, |sigFunc|, and |verifyFunc| per [[[#MLSuitesTable]]], which are used in the algorithm below. Additional required inputs are an unsecured data document ([=map=] |unsecuredDocument|), and a set of proof options ([=map=] |options|). A [=data integrity proof=] ([=map=]), or an error, is produced as output.

  1. Let |proof| be a clone of the proof options, |options|.
  2. Let |proofConfig| be the result of running the algorithm in Section [[[#ProofConfigurationAlg]]] with |options|, the |cypherSuiteName|, |canonScheme|, and |hashName| passed as parameters.
  3. Let |transformedData| be the result of running the algorithm in Section [[[#TransformationAlg]]] with |unsecuredDocument|, |options|, the |cypherSuiteName|, |canonScheme|, and |hashName| passed as parameters.
  4. Let |hashData| be the result of running the algorithm in Section [[[#HashingAlg]]] with |transformedData|, |proofConfig|, and |hashName| passed as a parameters.
  5. Let |proofBytes| be the result of running the algorithm in Section [[[#ProofSerializationAlg]]] with |hashData|, |options|, and |sigFunc| passed as parameters.
  6. Let |proof|.|proofValue| be a base64-url-encoded Multibase encoding of the |proofBytes|.
  7. Return |proof| as the [=data integrity proof=].

Verify Proof (ML-DSA)

The following algorithm specifies how to verify a [=data integrity proof=] given an secured data document. Required inputs are an secured data document ([=map=] |securedDocument|). This algorithm returns a verification result, which is a [=struct=] whose [=struct/items=] are:

verified
`true` or `false`
verifiedDocument
Null, if [=verification result/verified=] is `false`; otherwise, an [=unsecured data document=]
  1. Let |unsecuredDocument| be a copy of |securedDocument| with the `proof` value removed.
  2. Let |proofOptions| be a copy of |securedDocument|.|proof| with `proofValue` removed.
  3. Set |cryptosuiteName| to |securedDocument|.|proof|.|cryptosuite|, which must be one of those listed in [[[#MLSuitesTable]]]. From |cryptosuiteName|, set the values of |canonScheme|, |hashName|, and |verifyFunc|, as found in [[[#MLSuitesTable]]].
  4. Let |proofBytes| be the Multibase decoded base64-url value in |securedDocument|.|proof|.|proofValue|.
  5. Let |transformedData| be the result of running the algorithm in Section [[[#TransformationAlg]]] with |unsecuredDocument|, and |cypherSuiteName|, |canonScheme|, and |hashName| |proofOptions| passed as parameters.
  6. Let |proofConfig| be the result of running the algorithm in Section [[[#ProofConfigurationAlg]]] with |options|, |cypherSuiteName|, |canonScheme|, and |hashName| passed as parameters.
  7. Let |hashData| be the result of running the algorithm in Section [[[#HashingAlg]]] with |transformedData|, |proofConfig|, and |hashName| passed as a parameters.
  8. Let |verified:boolean| be the result of running the algorithm in Section [[[#ProofVerificationAlg]]] with |hashData|, |proofBytes|, |proofConfig|, and |verifyFunc| as parameters.
  9. Return a [=verification result=] with [=struct/items=]:
    [=verified=]
    |verified|
    [=verifiedDocument=]
    |unsecuredDocument| if |verified| is `true`, otherwise Null

SLH-DSA Cryptosuites

The Stateless Hash-Based Digital Signature Standard defined in [[[FIPS-205]]] [[FIPS-205]] defines parameter sets for three different claimed security strengths, optimized for size or speed, and a specified hash function family. This specification considers a subset of these parameter sets, optimized for smaller size, and based on the SHA2 hash function family, as shown in [[[#SLHSigTable]]].

SLH-DSA Signatures Summary, all sizes in bytes.
Name Security Private Key Public Key Signature
SLH-DSA-SHA2-128s Category 1 64 32 7856
SLH-DSA-SHA2-192s Category 3 96 48 16224
SLH-DSA-SHA2-256s Category 5 128 64 29792

Supporting both Universal RDF Dataset Canonicalization Algorithm [[RDF-CANON]], "`rdfc`", JSON Canonicalization Scheme [[RFC8785]], "`jcs`", and a maximum security category of 1, leads to the family of ML-DSA cryptosuites given in [[[#SLHSuiteTable]]].

Supported SLH-DSA Cryptosuites.
Name Canonizalization Signature/Verification Hash
`slhdsa128-rdfc-2024` RDFC SLH-DSA-SHA2-128s SHA-256
`slhdsa128-jcs-2024` JCS SLH-DSA-SHA2-128s SHA-256

Create Proof (SLH-DSA)

The following algorithm specifies how to create a [=data integrity proof=] given an unsecured data document and an SLH-DSA cryptosuite chosen from [[[#SLHSuiteTable]]]. The choice of cryptosuite sets the values of |canonScheme|, |hashName|, |sigFunc|, and |verifyFunc| as found in [[[#SLHSuiteTable]]], for use in the algorithm below. Additional required inputs are an unsecured data document ([=map=] |unsecuredDocument|), and a set of proof options ([=map=] |options|). A [=data integrity proof=] ([=map=]), or an error, is produced as output.

  1. Let |proof| be a clone of the proof options, |options|.
  2. Let |proofConfig| be the result of running the algorithm in Section [[[#ProofConfigurationAlg]]] with |options|, the |cypherSuiteName|, |canonScheme|, and |hashName| passed as parameters.
  3. Let |transformedData| be the result of running the algorithm in Section [[[#TransformationAlg]]] with |unsecuredDocument|, |options|, |cypherSuiteName|, |canonScheme|, and |hashName| passed as parameters.
  4. Let |hashData| be the result of running the algorithm in Section [[[#HashingAlg]]] with |transformedData|, |proofConfig|, and |hashName| passed as a parameters.
  5. Let |proofBytes| be the result of running the algorithm in Section [[[#ProofSerializationAlg]]] with |hashData|, |options|, and |sigFunc| passed as parameters.
  6. Let |proof|.|proofValue| be a base64-url-encoded Multibase encoding of the |proofBytes|.
  7. Return |proof| as the [=data integrity proof=].

Verify Proof (SLH-DSA)

The following algorithm specifies how to verify a [=data integrity proof=] given an secured data document. Required inputs are an secured data document ([=map=] |securedDocument|). This algorithm returns a verification result, which is a [=struct=] whose [=struct/items=] are:

verified
`true` or `false`
verifiedDocument
Null, if [=verification result/verified=] is `false`; otherwise, an [=unsecured data document=]
  1. Let |unsecuredDocument| be a copy of |securedDocument| with the `proof` value removed.
  2. Let |proofOptions| be a copy of |securedDocument|.|proof| with `proofValue` removed.
  3. Set |cryptosuiteName| to |securedDocument|.|proof|.|cypnersuite|, it must be one of those listed in [[[#SLHSuiteTable]]]. From |cryptosuiteName| set the values of |canonScheme|, |hashName|, and |verifyFunc| per [[[#SLHSuiteTable]]].
  4. Let |proofBytes| be the Multibase base64-url-decoded decoding of |securedDocument|.|proof|.|proofValue|.
  5. Let |transformedData| be the result of running the algorithm in Section [[[#TransformationAlg]]] with |unsecuredDocument|, |proofOptions|, |cypherSuiteName|, |canonScheme|, and |hashName| passed as parameters.
  6. Let |proofConfig| be the result of running the algorithm in Section [[[#ProofConfigurationAlg]]] with |options| |cypherSuiteName|, |canonScheme|, and |hashName| passed as parameters.
  7. Let |hashData| be the result of running the algorithm in Section [[[#HashingAlg]]] with |transformedData|, |proofConfig| and |hashName| passed as a parameters.
  8. Let |verified:boolean| be the result of running the algorithm in Section [[[#ProofVerificationAlg]]] algorithm with |hashData|, |proofBytes|, |proofConfig|, and |verifyFunc| as parameters.
  9. Return a [=verification result=] with [=struct/items=]:
    [=verified=]
    |verified|
    [=verifiedDocument=]
    |unsecuredDocument| if |verified| is `true`, otherwise Null

FALCON Cryptosuites

The [[FALCON]] signature algorithm is undergoing standardization by NIST. The information presented here is based on the Post-Quantum Cryptography Round 3 Submission information. This section will be updated when the NIST specification is issued.

[[FALCON]] is a lattice-based signature scheme. It stands for the following acronym: FAst Fourier Lattice-based COmpact signatures over NTRU. FALCON defines parameter sets for two different claimed security strengths. The claimed security strengths, private key, public key, and signature sizes are summarized in [[[#FalconSummaryTable]]].

FALCON Signatures Summary, all sizes in bytes.
Name Security Private Key Public Key Signature
FALCON-512 Category 1 1281 897 666
FALCON-1024 Category 5 2305 1793 1280

Private key size information from openquantumsafe.org.

Supporting both the Universal RDF Dataset Canonicalization Algorithm [[RDF-CANON]], "`rdfc`", the JSON Canonicalization Scheme [[RFC8785]], "`jcs`", and a maximum security category of 1, leads to the family of FALCON cryptosuites given in [[[#FALCONSuitesTable]]].

Supported FALCON Cryptosuites.
Name Canonalization Signature/Verification Hash
`falcon512-rdfc-2024` RDFC FALCON-512 SHA-256
`falcon512-jcs-2024` JCS FALCON-512 SHA-256

Create Proof (FALCON)

The following algorithm specifies how to create a [=data integrity proof=] given an unsecured data document and a FALCON cryptosuite chosen from [[[#FALCONSuitesTable]]]. The choice of cryptosuite sets the values of |canonScheme|, |hashName|, |sigFunc|, and |verifyFunc| per [[[#FALCONSuitesTable]]], which are used in the algorithm below. Additional required inputs are an unsecured data document ([=map=] |unsecuredDocument|), and a set of proof options ([=map=] |options|). A [=data integrity proof=] ([=map=]), or an error, is produced as output.

  1. Let |proof| be a clone of the proof options, |options|.
  2. Let |proofConfig| be the result of running the algorithm in Section [[[#ProofConfigurationAlg]]] with |options|, the |cypherSuiteName|, |canonScheme|, and |hashName| passed as parameters.
  3. Let |transformedData| be the result of running the algorithm in Section [[[#TransformationAlg]]] with |unsecuredDocument|, |options|, the |cypherSuiteName|, |canonScheme|, and |hashName| passed as parameters.
  4. Let |hashData| be the result of running the algorithm in Section [[[#HashingAlg]]] with |transformedData|, |proofConfig|, and |hashName| passed as a parameters.
  5. Let |proofBytes| be the result of running the algorithm in Section [[[#ProofSerializationAlg]]] with |hashData|, |options|, and |sigFunc| passed as parameters.
  6. Let |proof|.|proofValue| be a base64-url-encoded Multibase encoding of the |proofBytes|.
  7. Return |proof| as the [=data integrity proof=].

Verify Proof (FALCON)

The following algorithm specifies how to verify a [=data integrity proof=] given an secured data document. Required inputs are an secured data document ([=map=] |securedDocument|). This algorithm returns a verification result, which is a [=struct=] whose [=struct/items=] are:

verified
`true` or `false`
verifiedDocument
Null, if [=verification result/verified=] is `false`; otherwise, an [=unsecured data document=]
  1. Let |unsecuredDocument| be a copy of |securedDocument| with the `proof` value removed.
  2. Let |proofOptions| be a copy of |securedDocument|.|proof| with `proofValue` removed.
  3. Set |cryptosuiteName| to |securedDocument|.|proof|.|cryptosuite|, which must be one of those listed in [[[#FALCONSuitesTable]]]. From |cryptosuiteName|, set the values of |canonScheme|, |hashName|, and |verifyFunc|, as found in [[[#FALCONSuitesTable]]].
  4. Let |proofBytes| be the Multibase decoded base64-url value in |securedDocument|.|proof|.|proofValue|.
  5. Let |transformedData| be the result of running the algorithm in Section [[[#TransformationAlg]]] with |unsecuredDocument|, and |cypherSuiteName|, |canonScheme|, and |hashName| |proofOptions| passed as parameters.
  6. Let |proofConfig| be the result of running the algorithm in Section [[[#ProofConfigurationAlg]]] with |options|, |cypherSuiteName|, |canonScheme|, and |hashName| passed as parameters.
  7. Let |hashData| be the result of running the algorithm in Section [[[#HashingAlg]]] with |transformedData|, |proofConfig|, and |hashName| passed as a parameters.
  8. Let |verified:boolean| be the result of running the algorithm in Section [[[#ProofVerificationAlg]]] with |hashData|, |proofBytes|, |proofConfig|, and |verifyFunc| as parameters.
  9. Return a [=verification result=] with [=struct/items=]:
    [=verified=]
    |verified|
    [=verifiedDocument=]
    |unsecuredDocument| if |verified| is `true`, otherwise Null

SQIsign Cryptosuites

The SQIsign signature algorithm has been submitted to NIST. SQIsign aims for very compact key and signature sizes. The information presented here is based on specification v2.01, 2025-07-07. This section will be updated as appropriate.

SQIsign relies on the hardness of a computational problem from number theory: computing the endomorphism ring of a supersingular elliptic curve, the endomorphism ring problem. SQIsign defines parameter sets for three different claimed security strengths. The claimed security strengths, private key, public key, and signature sizes are summarized in [[[#SQISummaryTable]]].

SQIsign Signatures Summary, all sizes in bytes.
Name Security Private Key Public Key Signature
SQIsign-I Category 1 353 65 148
SQIsign-III Category 3 529 97 224
SQIsign-V Category 5 701 129 292

Supporting both the Universal RDF Dataset Canonicalization Algorithm [[RDF-CANON]], "`rdfc`", the JSON Canonicalization Scheme [[RFC8785]], "`jcs`", and a maximum security category of 1, leads to the family of SQIsign cryptosuites given in [[[#SQISuitesTable]]].

Supported SQIsign Cryptosuites.
Name Canonalization Signature/Verification Hash
`sqisign1-rdfc-2024` RDFC SQIsign-I SHA-256
`sqisign1-jcs-2024` JCS SQIsign-I SHA-256

Create Proof (SQIsign)

The following algorithm specifies how to create a [=data integrity proof=] given an unsecured data document and a SQIsign cryptosuite chosen from [[[#SQISuitesTable]]]. The choice of cryptosuite sets the values of |canonScheme|, |hashName|, |sigFunc|, and |verifyFunc| per [[[#SQISuitesTable]]], which are used in the algorithm below. Additional required inputs are an unsecured data document ([=map=] |unsecuredDocument|), and a set of proof options ([=map=] |options|). A [=data integrity proof=] ([=map=]), or an error, is produced as output.

  1. Let |proof| be a clone of the proof options, |options|.
  2. Let |proofConfig| be the result of running the algorithm in Section [[[#ProofConfigurationAlg]]] with |options|, the |cypherSuiteName|, |canonScheme|, and |hashName| passed as parameters.
  3. Let |transformedData| be the result of running the algorithm in Section [[[#TransformationAlg]]] with |unsecuredDocument|, |options|, the |cypherSuiteName|, |canonScheme|, and |hashName| passed as parameters.
  4. Let |hashData| be the result of running the algorithm in Section [[[#HashingAlg]]] with |transformedData|, |proofConfig|, and |hashName| passed as a parameters.
  5. Let |proofBytes| be the result of running the algorithm in Section [[[#ProofSerializationAlg]]] with |hashData|, |options|, and |sigFunc| passed as parameters.
  6. Let |proof|.|proofValue| be a base64-url-encoded Multibase encoding of the |proofBytes|.
  7. Return |proof| as the [=data integrity proof=].

Verify Proof (SQIsign)

The following algorithm specifies how to verify a [=data integrity proof=] given an secured data document. Required inputs are an secured data document ([=map=] |securedDocument|). This algorithm returns a verification result, which is a [=struct=] whose [=struct/items=] are:

verified
`true` or `false`
verifiedDocument
Null, if [=verification result/verified=] is `false`; otherwise, an [=unsecured data document=]
  1. Let |unsecuredDocument| be a copy of |securedDocument| with the `proof` value removed.
  2. Let |proofOptions| be a copy of |securedDocument|.|proof| with `proofValue` removed.
  3. Set |cryptosuiteName| to |securedDocument|.|proof|.|cryptosuite|, which must be one of those listed in [[[#SQISuitesTable]]]. From |cryptosuiteName|, set the values of |canonScheme|, |hashName|, and |verifyFunc|, as found in [[[#SQISuitesTable]]].
  4. Let |proofBytes| be the Multibase decoded base64-url value in |securedDocument|.|proof|.|proofValue|.
  5. Let |transformedData| be the result of running the algorithm in Section [[[#TransformationAlg]]] with |unsecuredDocument|, and |cypherSuiteName|, |canonScheme|, and |hashName| |proofOptions| passed as parameters.
  6. Let |proofConfig| be the result of running the algorithm in Section [[[#ProofConfigurationAlg]]] with |options|, |cypherSuiteName|, |canonScheme|, and |hashName| passed as parameters.
  7. Let |hashData| be the result of running the algorithm in Section [[[#HashingAlg]]] with |transformedData|, |proofConfig|, and |hashName| passed as a parameters.
  8. Let |verified:boolean| be the result of running the algorithm in Section [[[#ProofVerificationAlg]]] with |hashData|, |proofBytes|, |proofConfig|, and |verifyFunc| as parameters.
  9. Return a [=verification result=] with [=struct/items=]:
    [=verified=]
    |verified|
    [=verifiedDocument=]
    |unsecuredDocument| if |verified| is `true`, otherwise Null

Security Considerations

Before reading this section, readers are urged to familiarize themselves with general security advice provided in the Security Considerations section of the Data Integrity specification.

The following section describes security considerations that developers implementing this specification should be aware of in order to create secure software or protocols based on verifiable credentials signed using the cryptosuites defined here.

Signature Security Properties

All signature suites in this specification are designed to satisfy either existential unforgeability under chosen-message attacks (EUF-CMA) or strong unforgeability under chosen message attacks (SUF-CMA) or both as defined below.

EUF-CMA (existential unforgeability under chosen message attacks) is usually the minimal security property required of a signature scheme. It guarantees that any efficient adversary who has the public key p k of the signer and received an arbitrary number of signatures on messages of its choice (in an adaptive manner): { m i , σ i } i = 1 N , cannot output a valid signature σ ∗ for a new message m ∗ ∉ { m i } i = 1 N (except with negligible probability). If the attacker outputs a valid signature on a new message: ( m ∗ , σ ∗ ) , it is called an existential forgery.

SUF-CMA (strong unforgeability under chosen message attacks) is a stronger notion than EUF-CMA. It guarantees that for any efficient adversary who has the public key p k of the signer and received an arbitrary number of signatures on messages of its choice: { m i , σ i } i = 1 N , it cannot output a new valid signature pair ( m ∗ , σ ∗ ) , such that ( m ∗ , σ ∗ ) ∉ { m i , σ i } i = 1 N (except with negligible probability). Strong unforgeability implies that an adversary not only cannot sign new messages, but also cannot find a new signature on an old message. See [[Provable_Ed25519]] for a real world attack that would have been circumvented with SUF-CMA security over EUF-CMA security.

Besides EUF-CMA and SUF-CMA there are additional properties a digital signature scheme can possess that may be essential for overall software or protocol security depending on the application. These are discussed in [[BUFF]], which is also referenced by [[FIPS-204]] and [[FIPS-205]]. These additional properties are defined in [[BUFF]] as: exclusive ownership, message-bound signatures, and non re-signability.

Exclusive Ownership (EO): the property that a signature only verifies under a single public key. Without this property a system could be vunerable to an attack that allows constructing another key pair under which a given signature verifies, but never breaks the EUF-CMA property. Such an attack is documented in both [[BUFF]] and in [[Provable_Ed25519]] where it is called a "key substitution attack".

Message-Bound Signatures (MBS): the property that a signature is only valid for a unique message. This property is key for data integrity and all signature schemes chosen here currently support it. From [[BUFF]]: "A possible cause can be the presence of weak keys that verify multiple or even all messages. The absence of this property can lead to problems in protocols that depend on uniqueness properties in the presence of adversarially chosen keys."

Non Re-signability (NR): meaning that one cannot produce a signature under another key given a signature for some unknown message m, i.e., that an adversary cannot produce a legitimate signature verifying under its public key for a message it does not know. See [[BUFF]] for an example of a system that could be vulnerable without this property.

In [[[#SecurityProperties]]] we summarize the known security properties of the signature schemes in this specification.

Security Properties of Signature Schemes.
Name EUF-CMA SUF-CMA EO MBS NR
ML-DSA Yes Yes Yes Yes Yes
SLH-DSA Yes No Unknown Yes Unknown
FALCON* Yes No No Yes No
SQIsign Yes No Yes Yes Yes

Note*: This is based on the "third round FALCON" currently used hear and according to [[BUFF]] will be updated when FIPS-206 is released.

Privacy Considerations

Before reading this section, readers are urged to familiarize themselves with general privacy advice provided in the Privacy Considerations section of the Data Integrity specification.

The following section describes privacy considerations that developers implementing this specification should be aware of in order to avoid violating privacy assumptions.

Test Vectors

Test Vector Common Inputs

Inputs used in two or more test vectors are given in this section. They include the unsigned document, general proof options, and cryptographic keys.

Unsecured Data Document

The common unsecured data document used for generating all test vectors that require this input is given below.
Proof Options

A general template for the proof options used by test vectors that require this input is given below.

For each specific test case the `cryptosuite` and `verificationMethod` fields need to be set. For example, for the `slhdsa128-rdfc-2024` cryptosuite using the appropriate public key information from section [[[#TestKeys]]] the specific proof options is given below.
Example Cryptographic Keys

Cryptographic keys for used to generate output for specific signature suites are given below. This includes public and private (secret) keys in hexadeximal format and the public key as a `publicKeyMultibase`.

Common Algorithms: Proof Configuration

The Proof Configuration algorithm output is dependent on the specific proof options as well as the parameters, hence an output test vector for Proof Configuration is given for each supported `cryptosuite`.

Proof Configuration (`rdfc`, `sha-256`)
Proof Configuration (`jcs`)

Common Algorithms: Transform

In addition to the common unsecured data document the Transform algorithm takes parameters |canonScheme| and |hashName|. Only in the case of |canonScheme| equal to `rdfc` does the |hashName| parameter matter. This is reflected in the set of Transformation output test vectors given below.

Transform (`rdfc`, `sha-256`)
Transform (`rdfc`, `sha-384`)
Transform (`rdfc`, `sha-512`)
Transform (`jcs`)

Common Algorithms: Hashing

The Hashing algorithm takes as inputs the results of the Proof Configuration and Transformation algorithms. Since the Proof Configuration algorithm output is cryptosuite specific the Hashing algorithm output is given for each cryptosuite test case. The Hashing output for each cryptosuite test case is given in hexadecimal format below.

The first half of the hexadecimal Hashing result is the hash of the output of the Proof Configuration algorithm, while the second half of the hexidecimal value is the hash of the output from the Transformation algorithm and both can be useful information when debugging.

Create Proof

The Create Proof algorithm output is cryptosuite specific and uses the outputs of the Proof Configuration, Transformation, Hashing, and Proof Serialization algorithms. The output for each cryptosuite test case is given below.

The output of the Proof Serialization common algorithm is not given separately since it is contained in the `proofValue` attribute in the following examples and can be quite lengthy for some quantum safe signature algorithms.

Cryptosuite `mldsa44-rdfc-2024`
Cryptosuite `mldsa44-jcs-2024`
Cryptosuite `slhdsa128-rdfc-2024`
Cryptosuite `slhdsa128-jcs-2024`
Cryptosuite `falcon512-rdfc-2024`
Cryptosuite `falcon512-jcs-2024`
Cryptosuite `sqisign1-rdfc-2024`
Cryptosuite `sqisign1-jcs-2024`

Revision History

This section contains the substantive changes that have been made to this specification over time.

Added cryptosuite algorithms for Stateless Hash-Based Signatures, Falcon, and SQISign.