From baba7b8e9b55070a15b2483214c4c9ab7dc2ec3a Mon Sep 17 00:00:00 2001 From: Massimiliano Pala Date: Sun, 7 Jul 2024 18:02:19 -0400 Subject: [PATCH 01/10] Updated abstract to better reflect the status of the document (two algorithms, and pqc deployments). --- draft-ietf-lamps-pq-composite-sigs.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-lamps-pq-composite-sigs.md b/draft-ietf-lamps-pq-composite-sigs.md index f272f39..e05e494 100644 --- a/draft-ietf-lamps-pq-composite-sigs.md +++ b/draft-ietf-lamps-pq-composite-sigs.md @@ -140,9 +140,9 @@ informative: --- abstract -This document defines Post-Quantum / Traditional composite Key Signaturem algorithms suitable for use within X.509, PKIX and CMS protocols. Composite algorithms are provided which combine ML-DSA with RSA, ECDSA, Ed25519, and Ed448. The provided set of composite algorithms should meet most X.509, PKIX, and CMS needs. - +This document introduces a family of Composite signature schemes designed to enhance security by integrating multiple cryptographic elements such as public keys and signatures that integrate security properties from two different algorithms. These schemes effectively mitigate risks associated with the adoption of post-quantum cryptography. Composite schemes are fully compatible with existing X.509, PKIX, and CMS protocols, requiring no modifications in the number or type of messages. This document defines thirteen specific pairwise combinations that blend ML-DSA with traditional algorithms such as RSA, ECDSA, Ed25519, and Ed448. These combinations are tailored to meet current security standards and regulatory requirements. + From 33c3fc9fcdda58b73a6ac8ecfed8043ac6d0628a Mon Sep 17 00:00:00 2001 From: Massimiliano Pala Date: Sun, 7 Jul 2024 18:34:21 -0400 Subject: [PATCH 02/10] Updated introduction with some more explanation around Composite crypto. Updated structure for the Introduction, moved document changes at the end of the introduction. --- draft-ietf-lamps-pq-composite-sigs.md | 60 ++++++++++++++++----------- 1 file changed, 35 insertions(+), 25 deletions(-) diff --git a/draft-ietf-lamps-pq-composite-sigs.md b/draft-ietf-lamps-pq-composite-sigs.md index e05e494..013716c 100644 --- a/draft-ietf-lamps-pq-composite-sigs.md +++ b/draft-ietf-lamps-pq-composite-sigs.md @@ -140,35 +140,18 @@ informative: --- abstract -This document introduces a family of Composite signature schemes designed to enhance security by integrating multiple cryptographic elements such as public keys and signatures that integrate security properties from two different algorithms. These schemes effectively mitigate risks associated with the adoption of post-quantum cryptography. Composite schemes are fully compatible with existing X.509, PKIX, and CMS protocols, requiring no modifications in the number or type of messages. This document defines thirteen specific pairwise combinations that blend ML-DSA with traditional algorithms such as RSA, ECDSA, Ed25519, and Ed448. These combinations are tailored to meet current security standards and regulatory requirements. - +This document introduces a set of signature schemes designed to leverage pairs of cryptographic elements such as public keys and signatures to combine security properties from two different algorithms. These schemes effectively mitigate risks associated with the adoption of post-quantum cryptography and are fully compatible with existing X.509, PKIX, and CMS protocols, thus requiring no modifications in the number or type of messages. This document defines thirteen specific pairwise combinations that blend ML-DSA with traditional algorithms such as RSA, ECDSA, Ed25519, and Ed448. These combinations are tailored to meet security best practices and regulatory requirements. + --- middle -# Document Changes - -## Changes since the -01 version -* Added a "Use in CMS" section -* Removed a Falon reference from the ASN.1 document (which was a typo in reference to Falcon) -* Added SMIME-CAPS into the sa-CompositeSignature definition in the ASN.1 module -* Fixed nits and other typos -* Added PSS parameter Salt Lengths -* Changed the OID concatenation section to Domain Separators for clarity -* Accepted some edits by José Ignacio Escribano - -## Changes since adoption by the lamps working group -* Added back in the version 13 changes which were dropped by mistake in the initial -00 adopted version -* Added Scott Fluher as an author due to his valuable contributions and participation in the draft writing process -* Removed the reference to Parallel PKI's in implementation considerations as it isn't adding value to the discussion -* Resolved comments from Kris Kwiatkowski regarding FIPS - # Introduction {#sec-intro} -During the transition to post-quantum cryptography, there will be uncertainty as to the strength of cryptographic algorithms; we will no longer fully trust traditional cryptography such as RSA, Diffie-Hellman, DSA and their elliptic curve variants, but we will also not fully trust their post-quantum replacements until they have had sufficient scrutiny and time to discover and fix implementation bugs. Unlike previous cryptographic algorithm migrations, the choice of when to migrate and which algorithms to migrate to, is not so clear. Even after the migration period, it may be advantageous for an entity's cryptographic identity to be composed of multiple public-key algorithms. + + +The advent of quantum computing poses a significant threat to current cryptographic systems. Traditional cryptographic algorithms such as RSA, Diffie-Hellman, DSA, and their elliptic curve variants are vulnerable to quantum attacks. During the transition to post-quantum cryptography (PQC), there is considerable uncertainty regarding the robustness of both existing and new cryptographic algorithms. While we can no longer fully trust traditional cryptography, we also cannot immediately place complete trust in post-quantum replacements until they have undergone extensive scrutiny and real-world testing to uncover and rectify potential implementation flaws. + +Unlike previous migrations between cryptographic algorithms, the decision of when to migrate and which algorithms to adopt is far from straightforward. Even after the migration period, it may be advantageous for an entity's cryptographic identity to incorporate multiple public-key algorithms to enhance security. -## Terminology {#sec-terminology} -The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 {{RFC2119}} {{RFC8174}} when, and only when, they appear in all capitals, as shown here. +Cautious implementers may opt to combine cryptographic algorithms in such a way that an attacker would need to break all of them simultaneously to compromise the protected data. These mechanisms are referred to as Post-Quantum/Traditional (PQ/T) Hybrids {{I-D.driscoll-pqt-hybrid-terminology}}. -The following terms are used in this document: +Certain jurisdictions are already recommending or mandating that PQC lattice schemes be used exclusively within a PQ/T hybrid framework. The use of Composite scheme provides a straightforward implementation of hybrid solutions compatible with (and advocated by) some governments and cybersecurity agencies [BSI2021]. + +## Conventions and Terminology {#sec-terminology} + + + +{::boilerplate bcp14+} + +This document is consistent with the terminology defined in {{-draft-driscoll-pqt-hybrid-terminology}}. In addition, the following terminology is used throughout this document: ALGORITHM: A standardized cryptographic primitive, as well as @@ -253,8 +249,22 @@ STRIPPING ATTACK: substituting a composite public key or signature for a version with fewer components. +## Changes since the -01 version +* Added a "Use in CMS" section +* Removed a Falon reference from the ASN.1 document (which was a typo in reference to Falcon) +* Added SMIME-CAPS into the sa-CompositeSignature definition in the ASN.1 module +* Fixed nits and other typos +* Added PSS parameter Salt Lengths +* Changed the OID concatenation section to Domain Separators for clarity +* Accepted some edits by José Ignacio Escribano + +## Changes since adoption by the lamps working group +* Added back in the version 13 changes which were dropped by mistake in the initial -00 adopted version +* Added Scott Fluher as an author due to his valuable contributions and participation in the draft writing process +* Removed the reference to Parallel PKI's in implementation considerations as it isn't adding value to the discussion +* Resolved comments from Kris Kwiatkowski regarding FIPS -## Composite Design Philosophy +# Composite Signature Schemes {{I-D.driscoll-pqt-hybrid-terminology}} defines composites as: From 23bed3b41023a39c9ff229c2fafb4803a39c7bdb Mon Sep 17 00:00:00 2001 From: Massimiliano Pala Date: Sun, 7 Jul 2024 19:21:12 -0400 Subject: [PATCH 03/10] Updated Composite cryptographic primitives description. Extended KeyGen() description and added pseudo algorithm for KeyGen(). --- draft-ietf-lamps-pq-composite-sigs.md | 53 +++++++++++++++++++++++---- 1 file changed, 45 insertions(+), 8 deletions(-) diff --git a/draft-ietf-lamps-pq-composite-sigs.md b/draft-ietf-lamps-pq-composite-sigs.md index 013716c..519210e 100644 --- a/draft-ietf-lamps-pq-composite-sigs.md +++ b/draft-ietf-lamps-pq-composite-sigs.md @@ -266,19 +266,21 @@ STRIPPING ATTACK: # Composite Signature Schemes -{{I-D.driscoll-pqt-hybrid-terminology}} defines composites as: + -Composite keys as defined here follow this definition and should be regarded as a single key that performs a single cryptographic operation such key generation, signing, verifying, encapsulating, or decapsulating -- using its internal sequence of component keys as if they form a single key. This generally means that the complexity of combining algorithms can and should be handled by the cryptographic library or cryptographic module, and the single composite public key, private key, and ciphertext can be carried in existing fields in protocols such as PKCS#10 [RFC2986], CMP [RFC4210], X.509 [RFC5280], CMS [RFC5652], and the Trust Anchor Format [RFC5914]. In this way, composites achieve "protocol backwards-compatibility" in that they will drop cleanly into any protocol that accepts signature algorithms without requiring any modification of the protocol to handle multiple keys. +The engineering principle behind the definition of Composite schemes is to define a new family of algorithms that combines the use of cryptographic operations from two different ones: ML-DSA one and a traditional one.The complexity of combining security properties from the selected two algorithms is handled at the cryptographic library or cryptographic module, thus no changes are expected at the application or protocol level. Composite schemes are fully compatible with the X.509 model: composite public keys, composite private keys, and ciphertexts can be carried in existing data structures and protocols such as PKCS#10 [RFC2986], CMP [RFC4210], X.509 [RFC5280], CMS [RFC5652], and the Trust Anchor Format [RFC5914]. -## Composite Signatures {#sec-sigs} + -Here we define the signature mechanism in which a signature is a cryptographic primitive that consists of three algorithms: +## Cryptographic Primitives {#sec-sigs} + +Composite schemes are defined as cryptographic primitives that consists of three algorithms: * KeyGen() -> (pk, sk): A probabilistic key generation algorithm, which generates a public key pk and a secret key sk. @@ -287,7 +289,7 @@ Here we define the signature mechanism in which a signature is a cryptographic p as input a secret key sk and a Message, and outputs a signature * Verify(pk, Message, signature) -> true or false: A verification algorithm - which takes as input a public key, a Message and signature and outputs true + which takes as input a public key, a Message, and a signature and outputs true if the signature verifies correctly. Thus it proves the Message was signed with the secret key associated with the public key and verifies the integrity of the Message. If the signature and public key cannot verify the Message, @@ -295,10 +297,45 @@ Here we define the signature mechanism in which a signature is a cryptographic p A composite signature allows two underlying signature algorithms to be combined into a single cryptographic signature operation and can be used for applications that require signatures. -### Composite KeyGen +### Composite Key Generation + +To generate a new keypair for Composite schemes, the `KeyGen() -> (pk, sk)` function is used. The KeyGen() function calls the two key generation functions of the component algorithms for the Composite keypair. The generated composite public key structure is described in {{sec-composite-pub-keys}}, while the generated composite secret key structure is defined in {{sec-priv-key}}. + +The following process is used to generate composite kepair values. + +~~~ +KeyGen() -> (pk, sk) +Input: + sk_1, sk_2 Private keys for each component. + + pk_1, pk_2 Public keys for each component. + + A1, A2 Component signature algorithms. -The `KeyGen() -> (pk, sk)` of a composite signature algorithm will perform the `KeyGen()` of the respective component signature algorithms and it produces a composite public key `pk` as per {{sec-composite-pub-keys}} and a composite secret key `sk` is per {{sec-priv-key}}. The component keys MUST be uniquely generated for each component key of a Composite and MUST NOT be used in any other keys or as a standalone key. +Output: + (pk, sk) The composite keypair. + +KeyGen(): + + (pk_1, sk_1) <- A1.KeyGen() + (pk_2, sk_2) <- A2.KeyGen() + + if NOT (pk_1, sk_1) or NOT (pk_2, sk_2): + // Component key generation failure + return NULL + + (pk, sk) <- encode[(pk_1, sk_1), (pk_2, sk_2)] + if NOT (pk, sk): + // Encoding failure + return False + + // Success + return (pk, sk) + +~~~ +{: #alg-composite-keygen title="Composite KeyGen(pk, sk)"} +The component keys MUST be uniquely generated for each component key of a Composite and MUST NOT be used in any other keys or as a standalone key. ### Composite Sign {#sec-comp-sig-gen} From 020eb3356b6690b5d82e2cc187810c50d117e984 Mon Sep 17 00:00:00 2001 From: Massimiliano Pala Date: Sun, 7 Jul 2024 19:35:03 -0400 Subject: [PATCH 04/10] Updated signatures' process description to better reflect the changes in the algorithm. --- draft-ietf-lamps-pq-composite-sigs.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/draft-ietf-lamps-pq-composite-sigs.md b/draft-ietf-lamps-pq-composite-sigs.md index 519210e..471d735 100644 --- a/draft-ietf-lamps-pq-composite-sigs.md +++ b/draft-ietf-lamps-pq-composite-sigs.md @@ -339,7 +339,11 @@ The component keys MUST be uniquely generated for each component key of a Compos ### Composite Sign {#sec-comp-sig-gen} -Generation of a composite signature involves applying each component algorithm's signature process to the input message according to its specification, and then placing each component signature value into the CompositeSignatureValue structure defined in {{sec-composite-sig-structs}}. + + +In multi-algorithm environments, signatures require additional security properties such as non-separability and key binding to mitigate the possibility for new type of attacks that target the new multi-algorithms model. Composite signatures construct provide additional properties such as non-separability and key-binding. For more information, please refer to {{I-D.hale-pquip-hybrid-signature-spectrums}} and the use of labels as defined in {{Bindel2017}} + +To this end, the Composite signature generation starts with the pre-hashing the message to be signed together with key-binding data. After that, the signature process for each component algorithm is invoked and the values are then placed in the CompositeSignatureValue structure defined in {{sec-composite-sig-structs}}. The following process is used to generate composite signature values. From 3fd338d916be6e80032c464eaf2893ee13b43ad5 Mon Sep 17 00:00:00 2001 From: Massimiliano Pala Date: Sun, 7 Jul 2024 19:38:04 -0400 Subject: [PATCH 05/10] Fix for references. --- draft-ietf-lamps-pq-composite-sigs.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-lamps-pq-composite-sigs.md b/draft-ietf-lamps-pq-composite-sigs.md index 471d735..9214c25 100644 --- a/draft-ietf-lamps-pq-composite-sigs.md +++ b/draft-ietf-lamps-pq-composite-sigs.md @@ -183,7 +183,7 @@ The advent of quantum computing poses a significant threat to current cryptograp Unlike previous migrations between cryptographic algorithms, the decision of when to migrate and which algorithms to adopt is far from straightforward. Even after the migration period, it may be advantageous for an entity's cryptographic identity to incorporate multiple public-key algorithms to enhance security. -Cautious implementers may opt to combine cryptographic algorithms in such a way that an attacker would need to break all of them simultaneously to compromise the protected data. These mechanisms are referred to as Post-Quantum/Traditional (PQ/T) Hybrids {{I-D.driscoll-pqt-hybrid-terminology}}. +Cautious implementers may opt to combine cryptographic algorithms in such a way that an attacker would need to break all of them simultaneously to compromise the protected data. These mechanisms are referred to as Post-Quantum/Traditional (PQ/T) Hybrids {{I-D.draft-driscoll-pqt-hybrid-terminology}}. Certain jurisdictions are already recommending or mandating that PQC lattice schemes be used exclusively within a PQ/T hybrid framework. The use of Composite scheme provides a straightforward implementation of hybrid solutions compatible with (and advocated by) some governments and cybersecurity agencies [BSI2021]. @@ -195,7 +195,7 @@ The following terms are used in this document: --> {::boilerplate bcp14+} -This document is consistent with the terminology defined in {{-draft-driscoll-pqt-hybrid-terminology}}. In addition, the following terminology is used throughout this document: +This document is consistent with the terminology defined in {{I-D.draft-driscoll-pqt-hybrid-terminology}}. In addition, the following terminology is used throughout this document: ALGORITHM: A standardized cryptographic primitive, as well as From 3f6ebffe695d4030f1afda720d9fcc66c3763736 Mon Sep 17 00:00:00 2001 From: "Dr. Massimiliano Pala" Date: Mon, 8 Jul 2024 08:26:17 -0600 Subject: [PATCH 06/10] Updated Cryptographic Primitives and Design Principles sections in the effort of providing better separation of the two. Moved the algorithm selection criteria considerations to the security section. --- draft-ietf-lamps-pq-composite-sigs.md | 174 +++++++++++++++----------- 1 file changed, 103 insertions(+), 71 deletions(-) diff --git a/draft-ietf-lamps-pq-composite-sigs.md b/draft-ietf-lamps-pq-composite-sigs.md index 9214c25..a8b126b 100644 --- a/draft-ietf-lamps-pq-composite-sigs.md +++ b/draft-ietf-lamps-pq-composite-sigs.md @@ -142,7 +142,7 @@ informative: -This document introduces a set of signature schemes designed to leverage pairs of cryptographic elements such as public keys and signatures to combine security properties from two different algorithms. These schemes effectively mitigate risks associated with the adoption of post-quantum cryptography and are fully compatible with existing X.509, PKIX, and CMS protocols, thus requiring no modifications in the number or type of messages. This document defines thirteen specific pairwise combinations that blend ML-DSA with traditional algorithms such as RSA, ECDSA, Ed25519, and Ed448. These combinations are tailored to meet security best practices and regulatory requirements. +This document introduces a set of signature schemes that use pairs of cryptographic elements such as public keys and signatures to combine their security properties. These schemes effectively mitigate risks associated with the adoption of post-quantum cryptography and are fully compatible with existing X.509, PKIX, and CMS data structures and protocols. This document defines thirteen specific pairwise combinations, namely ML-DSA Composite Schemes, that blend ML-DSA with traditional algorithms such as RSA, ECDSA, Ed25519, and Ed448. These combinations are tailored to meet security best practices and regulatory requirements. @@ -264,21 +264,23 @@ STRIPPING ATTACK: * Removed the reference to Parallel PKI's in implementation considerations as it isn't adding value to the discussion * Resolved comments from Kris Kwiatkowski regarding FIPS -# Composite Signature Schemes + +> type in a multi-algorithm scheme. -- The engineering principle behind the definition of Composite schemes is to define a new family of algorithms that combines the use of cryptographic operations from two different ones: ML-DSA one and a traditional one.The complexity of combining security properties from the selected two algorithms is handled at the cryptographic library or cryptographic module, thus no changes are expected at the application or protocol level. Composite schemes are fully compatible with the X.509 model: composite public keys, composite private keys, and ciphertexts can be carried in existing data structures and protocols such as PKCS#10 [RFC2986], CMP [RFC4210], X.509 [RFC5280], CMS [RFC5652], and the Trust Anchor Format [RFC5914]. - +!-- End of Introduction section -- - +## Composite Signatures {#sec-sigs} --> -## Cryptographic Primitives {#sec-sigs} +# Composite Signature Schemes Design Principles + +The engineering principle behind the definition of Composite schemes is to define a new family of algorithms that combines the use of cryptographic operations from two different ones: ML-DSA one and a traditional one.The complexity of combining security properties from the selected two algorithms is handled at the cryptographic library or cryptographic module, thus no changes are expected at the application or protocol level. Composite schemes are fully compatible with the X.509 model: composite public keys, composite private keys, and ciphertexts can be carried in existing data structures and protocols such as PKCS#10 [RFC2986], CMP [RFC4210], X.509 [RFC5280], CMS [RFC5652], and the Trust Anchor Format [RFC5914]. Composite schemes are defined as cryptographic primitives that consists of three algorithms: @@ -295,16 +297,62 @@ Composite schemes are defined as cryptographic primitives that consists of three of the Message. If the signature and public key cannot verify the Message, it returns false. -A composite signature allows two underlying signature algorithms to be combined into a single cryptographic signature operation and can be used for applications that require signatures. +A composite signature allows the security properties of the two underlying algorithms to be combined via standard signature operations such as generation and verify and can be used in all applications that use signatures without the need for changes in data structures or protocol messages. + +## Domain Separators {#sec-oid-concat} + +Composite signature schemes use the concept of Domain separator to bind the value of the signature to the specific combination of algorithms identified by the scheme's OID value. Domain separators are represented as the DER encoding of the signature's algorithm. + +The following table shows the HEX encoding for each Signature AlgorithmID. + +| Composite Signature AlgorithmID | Domain Separator (in Hex encoding)| +| ----------- | ----------- | +| id-MLDSA44-RSA2048-PSS-SHA256 | 060B6086480186FA6B50080101| +| id-MLDSA44-RSA2048-PKCS15-SHA256 |060B6086480186FA6B50080102| +| id-MLDSA44-Ed25519-SHA512 |060B6086480186FA6B50080103| +| id-MLDSA44-ECDSA-P256-SHA256 |060B6086480186FA6B50080104| +| id-MLDSA44-ECDSA-brainpoolP256r1-SHA256 |060B6086480186FA6B50080105| +| id-MLDSA65-RSA3072-PSS-SHA512 |060B6086480186FA6B50080106| +| id-MLDSA65-RSA3072-PKCS15-SHA512 |060B6086480186FA6B50080107| +| id-MLDSA65-ECDSA-P256-SHA512 |060B6086480186FA6B50080108| +| id-MLDSA65-ECDSA-brainpoolP256r1-SHA512 |060B6086480186FA6B50080109| +| id-MLDSA65-Ed25519-SHA512 |060B6086480186FA6B5008010A| +| id-MLDSA87-ECDSA-P384-SHA512 |060B6086480186FA6B5008010B| +| id-MLDSA87-ECDSA-brainpoolP384r1-SHA512 |060B6086480186FA6B5008010C| +| id-MLDSA87-Ed448-SHA512 |060B6086480186FA6B5008010D| +{: #tab-sig-alg-oids title="Composite Signature Domain Separators"} -### Composite Key Generation +## Composite Schemes PreHashing {#sec-prehash} -To generate a new keypair for Composite schemes, the `KeyGen() -> (pk, sk)` function is used. The KeyGen() function calls the two key generation functions of the component algorithms for the Composite keypair. The generated composite public key structure is described in {{sec-composite-pub-keys}}, while the generated composite secret key structure is defined in {{sec-priv-key}}. +Composite schemes' signature generation process and composite signature verification process are designed to provide security properties meant to address specific issues related to the use multiple algorithms and they require the use of pre-hasing. In Composite schemes, the value of the DER encoding of the selected signature scheme is concatenated with the calculated Hash over the original message. -The following process is used to generate composite kepair values. +The output is then used as input for the `Sign()` and `Verify()` functions. + + + + + +# Cryptographic Primitives {#sec-sigs} + +## Key Generation + +To generate a new keypair for Composite schemes, the `KeyGen() -> (pk, sk)` function is used. The KeyGen() function calls the two key generation functions of the component algorithms for the Composite keypair in no particular order. Multi-process or multi-threaded applications might choose to execute the key generation functions in parallel for better key generation performance. + +The generated public key structure is described in {{sec-composite-pub-keys}}, while the corrsponding composite secret key structure is defined in {{sec-priv-key}}. + +The following process is used to generate composite kepair values: ~~~ KeyGen() -> (pk, sk) + Input: sk_1, sk_2 Private keys for each component. @@ -315,7 +363,7 @@ Input: Output: (pk, sk) The composite keypair. -KeyGen(): +Function KeyGen(): (pk_1, sk_1) <- A1.KeyGen() (pk_2, sk_2) <- A2.KeyGen() @@ -335,15 +383,17 @@ KeyGen(): ~~~ {: #alg-composite-keygen title="Composite KeyGen(pk, sk)"} -The component keys MUST be uniquely generated for each component key of a Composite and MUST NOT be used in any other keys or as a standalone key. +The key generation functions MUST be executed for both algorithms. Compliant parties MUST NOT use or import component keys that are used in other context, combinations, or by themselves (i.e., not only in X.509 certificates). -### Composite Sign {#sec-comp-sig-gen} +## Signature Generation {#sec-comp-sig-gen} -In multi-algorithm environments, signatures require additional security properties such as non-separability and key binding to mitigate the possibility for new type of attacks that target the new multi-algorithms model. Composite signatures construct provide additional properties such as non-separability and key-binding. For more information, please refer to {{I-D.hale-pquip-hybrid-signature-spectrums}} and the use of labels as defined in {{Bindel2017}} +Composite schemes' signatures provide important properties for multi-key environments such as non-separability and key-binding. For more information on the additional security properties and their applicability to multi-key or hybrid environments, please refer to {{I-D.hale-pquip-hybrid-signature-spectrums}} and the use of labels as defined in {{Bindel2017}} + +Composite signature generation starts with the pre-hashing the message that is concatenated with the to be signed together with key-binding data. After that, the signature process for each component algorithm is invoked and the values are then placed in the CompositeSignatureValue structure defined in {{sec-composite-sig-structs}}. -To this end, the Composite signature generation starts with the pre-hashing the message to be signed together with key-binding data. After that, the signature process for each component algorithm is invoked and the values are then placed in the CompositeSignatureValue structure defined in {{sec-composite-sig-structs}}. +A composite signature's value MUST include two signature components and MUST be in the same order as the components from the corresponding signing key. The following process is used to generate composite signature values. @@ -370,35 +420,39 @@ Output: Signature Generation Process: - 1. Compute a Hash of the Message + 1. Compute the new Message M' by concatenating the Domain identifier (i.e., the DER encoding of the Composite scheme) with the Hash of the Message - M' = HASH(Message) + M' := DER(OID) || HASH(Message) - 2. Generate the 2 component signatures independently, - according to their algorithm specifications. + 2. Generate the 2 component signatures independently, by calculating the signature over M' + according to their algorithm specifications that might involve the use of the hash-n-sign paradigm. - S1 := Sign( K1, A1, DER(OID) || M' ) - S2 := Sign( K2, A2, DER(OID) || M' ) + S1 := Sign( K1, A1, M' ) + S2 := Sign( K2, A2, M' ) 3. Encode each component signature S1 and S2 into a BIT STRING according to its algorithm specification. - signature ::= Sequence { S1, S2 } + signature := NULL + + IF (S1 != NULL) and (S2 != NULL): + signature := Sequence { S1, S2 } 4. Output signature + + return signature ~~~ {: #alg-composite-sign title="Composite Sign(sk, Message)"} -Note on composite inputs: the method of providing the list of component keys and algorithms is flexible and beyond the scope of this pseudo-code. When passed to the Composite Sign(sk, Message) API the sk is a CompositePrivateKey. It is possible to construct a CompositePrivateKey from component keys stored in separate software or hardware keystores. Variations in the process to accommodate particular private key storage mechanisms are considered to be conformant to this document so long as it produces the same output as the process sketched above. - -Since recursive composite public keys are disallowed, no component signature may itself be a composite; ie the signature generation process MUST fail if one of the private keys K1 or K2 is a composite. + -A composite signature MUST produce, and include in the output, a signature value for every component key in the corresponding CompositePublicKey, and they MUST be in the same order; ie in the output, S1 MUST correspond to K1, S2 to K2. +It is possible to construct `CompositePrivateKey`(s) to generate signatures from component keys stored in separate software or hardware keystores. Variations in the process to accommodate particular private key storage mechanisms are considered to be conformant to this document so long as it produces the same output as the process sketched above. + -### Composite Verify {#sec-comp-sig-verify} +### Signature Verify {#sec-comp-sig-verify} -Verification of a composite signature involves applying each component algorithm's verification process according to its specification. +Verification of a composite signature involves reconstructing the M' message first by concatenating the Domain separator (i.e., the DER encoding of the used Composite scheme's OID) with the Hash of the original message and then applying each component algorithm's verification process to the new message M'. Compliant applications MUST output "Valid signature" (true) if and only if all component signatures were successfully validated, and "Invalid signature" (false) otherwise. @@ -442,15 +496,15 @@ Signature Verification Procedure:: 2. Compute a Hash of the Message - M' = HASH(Message) + M' = DER(OID) || HASH(Message) 3. Check each component signature individually, according to its algorithm specification. If any fail, then the entire signature validation fails. - if not verify( P1, DER(OID) || M', S1, A1 ) then + if not verify( P1, M', S1, A1 ) then output "Invalid signature" - if not verify( P2, DER(OID) || M', S2, A2 ) then + if not verify( P2, M', S2, A2 ) then output "Invalid signature" if all succeeded, then @@ -458,46 +512,11 @@ Signature Verification Procedure:: ~~~ {: #alg-composite-verify title="Composite Verify(pk, Message, signature)"} -Note on composite inputs: the method of providing the list of component keys and algorithms is flexible and beyond the scope of this pseudo-code. When passed to the Composite Verify(pk, Message, signature) API the pk is a CompositePublicKey. It is possible to construct a CompositePublicKey from component keys stored in separate software or hardware keystores. Variations in the process to accommodate particular private key storage mechanisms are considered to be conformant to this document so long as it produces the same output as the process sketched above. - -Since recursive composite public keys are disallowed, no component signature may itself be a composite; ie the signature generation process MUST fail if one of the private keys K1 or K2 is a composite. - -## Domain Separators {#sec-oid-concat} - -As mentioned above, the OID input value is used as a domain separator for the Composite Signature Generation and verification process and is the DER encoding of the OID. The following table shows the HEX encoding for each Signature AlgorithmID. - -| Composite Signature AlgorithmID | Domain Separator (in Hex encoding)| -| ----------- | ----------- | -| id-MLDSA44-RSA2048-PSS-SHA256 | 060B6086480186FA6B50080101| -| id-MLDSA44-RSA2048-PKCS15-SHA256 |060B6086480186FA6B50080102| -| id-MLDSA44-Ed25519-SHA512 |060B6086480186FA6B50080103| -| id-MLDSA44-ECDSA-P256-SHA256 |060B6086480186FA6B50080104| -| id-MLDSA44-ECDSA-brainpoolP256r1-SHA256 |060B6086480186FA6B50080105| -| id-MLDSA65-RSA3072-PSS-SHA512 |060B6086480186FA6B50080106| -| id-MLDSA65-RSA3072-PKCS15-SHA512 |060B6086480186FA6B50080107| -| id-MLDSA65-ECDSA-P256-SHA512 |060B6086480186FA6B50080108| -| id-MLDSA65-ECDSA-brainpoolP256r1-SHA512 |060B6086480186FA6B50080109| -| id-MLDSA65-Ed25519-SHA512 |060B6086480186FA6B5008010A| -| id-MLDSA87-ECDSA-P384-SHA512 |060B6086480186FA6B5008010B| -| id-MLDSA87-ECDSA-brainpoolP384r1-SHA512 |060B6086480186FA6B5008010C| -| id-MLDSA87-Ed448-SHA512 |060B6086480186FA6B5008010D| -{: #tab-sig-alg-oids title="Composite Signature Domain Separators"} - -## PreHashing the Message {#sec-prehash} -As noted in the composite signature generation process and composite signature verification process, the Message should be pre-hashed into M' with the digest algorithm specified in the composite signature algorithm identifier. The choice of the digest algorithm was chosen with the following criteria: - -1. For composites paired with RSA or ECDSA, the hashing algorithm SHA256 or SHA512 is used as part of the RSA or ECDSA signature algorithm and is therefore also used as the composite prehashing algorithm. - -1. For ML-DSA signing a digest of the message is allowed as long as the hash function provides at least y bits of classical security strength against both collision and second preimage attacks. For MLDSA44 y is 128 bits, for MLDSA65 y is 192 bits and for MLDSA87 y is 256 bits. Therefore SHA256 is paired with RSA and ECDSA with MLDSA44 and SHA512 is paired with RSA and ECDSA with MLDSA65 and MLDSA87 to match the appropriate security strength. - -1. Ed25519 [RFC8032] uses SHA512 internally, therefore SHA512 is used to pre-hash the message when Ed25519 is a component algorithm. - -1. Ed448 [RFC8032] uses SHAKE256 internally, but to reduce the set of prehashing algorihtms, SHA512 was selected to pre-hash the message when Ed448 is a component algorithm. - - - + +It is possible to construct `CompositePublicKey`(s) to verify signatures from component keys stored in separate software or hardware keystores. Variations in the process to accommodate particular private key storage mechanisms are considered to be conformant to this document so long as it produces the same output as the process sketched above. + @@ -946,6 +965,19 @@ EDNOTE to IANA: OIDs will need to be replaced in both the ASN.1 module and in {{ # Security Considerations +## Algorithm Selection Criteria + +The composite algorithm combinations defined in this document were chosen according to the following guidelines: + +1. A single RSA combination is provided at a key size of 3072 bits, matched with NIST PQC Level 3 algorithms. +1. Elliptic curve algorithms are provided with combinations on each of the NIST [RFC6090], Brainpool [RFC5639], and Edwards [RFC7748] curves. NIST PQC Levels 1 - 3 algorithms are matched with 256-bit curves, while NIST levels 4 - 5 are matched with 384-bit elliptic curves. This provides a balance between matching classical security levels of post-quantum and traditional algorithms, and also selecting elliptic curves which already have wide adoption. +1. NIST level 1 candidates are provided, matched with 256-bit elliptic curves, intended for constrained use cases. + +If other combinations are needed, a separate specification should be submitted to the IETF LAMPS working group. To ease implementation, these specifications are encouraged to follow the construction pattern of the algorithms specified in this document. + +The composite structures defined in this specification allow only for pairs of algorithms. This also does not preclude future specification from extending these structures to define combinations with three or more components. + + ## Policy for Deprecated and Acceptable Algorithms Traditionally, a public key, certificate, or signature contains a single cryptographic algorithm. If and when an algorithm becomes deprecated (for example, RSA-512, or SHA1), then clients performing signatures or verifications should be updated to adhere to appropriate policies. From 9b4942e20104293642debf9f8b9b969bc7fa894d Mon Sep 17 00:00:00 2001 From: "Dr. Massimiliano Pala" Date: Mon, 8 Jul 2024 08:28:10 -0600 Subject: [PATCH 07/10] Updated refs (removed the extra 'draft-' from the refs in the text). --- draft-ietf-lamps-pq-composite-sigs.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-lamps-pq-composite-sigs.md b/draft-ietf-lamps-pq-composite-sigs.md index a8b126b..375c9bb 100644 --- a/draft-ietf-lamps-pq-composite-sigs.md +++ b/draft-ietf-lamps-pq-composite-sigs.md @@ -183,7 +183,7 @@ The advent of quantum computing poses a significant threat to current cryptograp Unlike previous migrations between cryptographic algorithms, the decision of when to migrate and which algorithms to adopt is far from straightforward. Even after the migration period, it may be advantageous for an entity's cryptographic identity to incorporate multiple public-key algorithms to enhance security. -Cautious implementers may opt to combine cryptographic algorithms in such a way that an attacker would need to break all of them simultaneously to compromise the protected data. These mechanisms are referred to as Post-Quantum/Traditional (PQ/T) Hybrids {{I-D.draft-driscoll-pqt-hybrid-terminology}}. +Cautious implementers may opt to combine cryptographic algorithms in such a way that an attacker would need to break all of them simultaneously to compromise the protected data. These mechanisms are referred to as Post-Quantum/Traditional (PQ/T) Hybrids {{I-D.driscoll-pqt-hybrid-terminology}}. Certain jurisdictions are already recommending or mandating that PQC lattice schemes be used exclusively within a PQ/T hybrid framework. The use of Composite scheme provides a straightforward implementation of hybrid solutions compatible with (and advocated by) some governments and cybersecurity agencies [BSI2021]. @@ -195,7 +195,7 @@ The following terms are used in this document: --> {::boilerplate bcp14+} -This document is consistent with the terminology defined in {{I-D.draft-driscoll-pqt-hybrid-terminology}}. In addition, the following terminology is used throughout this document: +This document is consistent with the terminology defined in {{I-D.driscoll-pqt-hybrid-terminology}}. In addition, the following terminology is used throughout this document: ALGORITHM: A standardized cryptographic primitive, as well as From bce8d4315ba478d18d23be569ef5380bd473880f Mon Sep 17 00:00:00 2001 From: "Dr. Massimiliano Pala" Date: Mon, 8 Jul 2024 08:32:19 -0600 Subject: [PATCH 08/10] Removed commented text that was moved to the security considerations and removed quotes for Sign() and Verify() function names on L 319. --- draft-ietf-lamps-pq-composite-sigs.md | 18 +----------------- 1 file changed, 1 insertion(+), 17 deletions(-) diff --git a/draft-ietf-lamps-pq-composite-sigs.md b/draft-ietf-lamps-pq-composite-sigs.md index 375c9bb..5e6675d 100644 --- a/draft-ietf-lamps-pq-composite-sigs.md +++ b/draft-ietf-lamps-pq-composite-sigs.md @@ -326,7 +326,7 @@ The following table shows the HEX encoding for each Signature AlgorithmID. Composite schemes' signature generation process and composite signature verification process are designed to provide security properties meant to address specific issues related to the use multiple algorithms and they require the use of pre-hasing. In Composite schemes, the value of the DER encoding of the selected signature scheme is concatenated with the calculated Hash over the original message. -The output is then used as input for the `Sign()` and `Verify()` functions. +The output is then used as input for the Sign() and Verify() functions. - - - # Composite Signature Structures {#sec-composite-structs} In order for signatures to be composed of multiple algorithms, we define encodings consisting of a sequence of signature primitives (aka "component algorithms") such that these structures can be used as a drop-in replacement for existing signature fields such as those found in PKCS#10 [RFC2986], CMP [RFC4210], X.509 [RFC5280], CMS [RFC5652]. From 097ac8d2dfdf44f8ffba8a5a296590fe4537d657 Mon Sep 17 00:00:00 2001 From: "Dr. Massimiliano Pala" Date: Mon, 8 Jul 2024 08:36:13 -0600 Subject: [PATCH 09/10] Removed commented text. --- draft-ietf-lamps-pq-composite-sigs.md | 69 +-------------------------- 1 file changed, 1 insertion(+), 68 deletions(-) diff --git a/draft-ietf-lamps-pq-composite-sigs.md b/draft-ietf-lamps-pq-composite-sigs.md index 5e6675d..7f442c5 100644 --- a/draft-ietf-lamps-pq-composite-sigs.md +++ b/draft-ietf-lamps-pq-composite-sigs.md @@ -140,8 +140,6 @@ informative: --- abstract - - This document introduces a set of signature schemes that use pairs of cryptographic elements such as public keys and signatures to combine their security properties. These schemes effectively mitigate risks associated with the adoption of post-quantum cryptography and are fully compatible with existing X.509, PKIX, and CMS data structures and protocols. This document defines thirteen specific pairwise combinations, namely ML-DSA Composite Schemes, that blend ML-DSA with traditional algorithms such as RSA, ECDSA, Ed25519, and Ed448. These combinations are tailored to meet security best practices and regulatory requirements. @@ -151,34 +149,6 @@ This document introduces a set of signature schemes that use pairs of cryptograp # Introduction {#sec-intro} - - The advent of quantum computing poses a significant threat to current cryptographic systems. Traditional cryptographic algorithms such as RSA, Diffie-Hellman, DSA, and their elliptic curve variants are vulnerable to quantum attacks. During the transition to post-quantum cryptography (PQC), there is considerable uncertainty regarding the robustness of both existing and new cryptographic algorithms. While we can no longer fully trust traditional cryptography, we also cannot immediately place complete trust in post-quantum replacements until they have undergone extensive scrutiny and real-world testing to uncover and rectify potential implementation flaws. Unlike previous migrations between cryptographic algorithms, the decision of when to migrate and which algorithms to adopt is far from straightforward. Even after the migration period, it may be advantageous for an entity's cryptographic identity to incorporate multiple public-key algorithms to enhance security. @@ -189,10 +159,6 @@ Certain jurisdictions are already recommending or mandating that PQC lattice sch ## Conventions and Terminology {#sec-terminology} - - {::boilerplate bcp14+} This document is consistent with the terminology defined in {{I-D.driscoll-pqt-hybrid-terminology}}. In addition, the following terminology is used throughout this document: @@ -264,21 +230,8 @@ STRIPPING ATTACK: * Removed the reference to Parallel PKI's in implementation considerations as it isn't adding value to the discussion * Resolved comments from Kris Kwiatkowski regarding FIPS - - -# Composite Signature Schemes Design Principles +# Composite Signature Schemes The engineering principle behind the definition of Composite schemes is to define a new family of algorithms that combines the use of cryptographic operations from two different ones: ML-DSA one and a traditional one.The complexity of combining security properties from the selected two algorithms is handled at the cryptographic library or cryptographic module, thus no changes are expected at the application or protocol level. Composite schemes are fully compatible with the X.509 model: composite public keys, composite private keys, and ciphertexts can be carried in existing data structures and protocols such as PKCS#10 [RFC2986], CMP [RFC4210], X.509 [RFC5280], CMS [RFC5652], and the Trust Anchor Format [RFC5914]. @@ -328,18 +281,6 @@ Composite schemes' signature generation process and composite signature verifica The output is then used as input for the Sign() and Verify() functions. - - - - # Cryptographic Primitives {#sec-sigs} ## Key Generation @@ -387,8 +328,6 @@ The key generation functions MUST be executed for both algorithms. Compliant par ## Signature Generation {#sec-comp-sig-gen} - - Composite schemes' signatures provide important properties for multi-key environments such as non-separability and key-binding. For more information on the additional security properties and their applicability to multi-key or hybrid environments, please refer to {{I-D.hale-pquip-hybrid-signature-spectrums}} and the use of labels as defined in {{Bindel2017}} Composite signature generation starts with the pre-hashing the message that is concatenated with the to be signed together with key-binding data. After that, the signature process for each component algorithm is invoked and the values are then placed in the CompositeSignatureValue structure defined in {{sec-composite-sig-structs}}. @@ -444,12 +383,8 @@ Signature Generation Process: ~~~ {: #alg-composite-sign title="Composite Sign(sk, Message)"} - - It is possible to construct `CompositePrivateKey`(s) to generate signatures from component keys stored in separate software or hardware keystores. Variations in the process to accommodate particular private key storage mechanisms are considered to be conformant to this document so long as it produces the same output as the process sketched above. - - ### Signature Verify {#sec-comp-sig-verify} Verification of a composite signature involves reconstructing the M' message first by concatenating the Domain separator (i.e., the DER encoding of the used Composite scheme's OID) with the Hash of the original message and then applying each component algorithm's verification process to the new message M'. @@ -512,8 +447,6 @@ Signature Verification Procedure:: ~~~ {: #alg-composite-verify title="Composite Verify(pk, Message, signature)"} - - It is possible to construct `CompositePublicKey`(s) to verify signatures from component keys stored in separate software or hardware keystores. Variations in the process to accommodate particular private key storage mechanisms are considered to be conformant to this document so long as it produces the same output as the process sketched above. # Composite Signature Structures {#sec-composite-structs} From 802ab8bd4a71b71afb51f0511dd7fccd1cd50d25 Mon Sep 17 00:00:00 2001 From: Mike Ounsworth Date: Mon, 8 Jul 2024 11:11:53 -0500 Subject: [PATCH 10/10] Moving the changelog back to the top --- draft-ietf-lamps-pq-composite-sigs.md | 34 +++++++++++++-------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/draft-ietf-lamps-pq-composite-sigs.md b/draft-ietf-lamps-pq-composite-sigs.md index 7f442c5..f8cdcc5 100644 --- a/draft-ietf-lamps-pq-composite-sigs.md +++ b/draft-ietf-lamps-pq-composite-sigs.md @@ -147,6 +147,22 @@ This document introduces a set of signature schemes that use pairs of cryptograp --- middle +## Changes since the -01 version +* Added a "Use in CMS" section +* Removed a Falon reference from the ASN.1 document (which was a typo in reference to Falcon) +* Added SMIME-CAPS into the sa-CompositeSignature definition in the ASN.1 module +* Fixed nits and other typos +* Added PSS parameter Salt Lengths +* Changed the OID concatenation section to Domain Separators for clarity +* Accepted some edits by José Ignacio Escribano + +## Changes since adoption by the lamps working group +* Added back in the version 13 changes which were dropped by mistake in the initial -00 adopted version +* Added Scott Fluher as an author due to his valuable contributions and participation in the draft writing process +* Removed the reference to Parallel PKI's in implementation considerations as it isn't adding value to the discussion +* Resolved comments from Kris Kwiatkowski regarding FIPS + + # Introduction {#sec-intro} The advent of quantum computing poses a significant threat to current cryptographic systems. Traditional cryptographic algorithms such as RSA, Diffie-Hellman, DSA, and their elliptic curve variants are vulnerable to quantum attacks. During the transition to post-quantum cryptography (PQC), there is considerable uncertainty regarding the robustness of both existing and new cryptographic algorithms. While we can no longer fully trust traditional cryptography, we also cannot immediately place complete trust in post-quantum replacements until they have undergone extensive scrutiny and real-world testing to uncover and rectify potential implementation flaws. @@ -215,22 +231,6 @@ STRIPPING ATTACK: substituting a composite public key or signature for a version with fewer components. -## Changes since the -01 version -* Added a "Use in CMS" section -* Removed a Falon reference from the ASN.1 document (which was a typo in reference to Falcon) -* Added SMIME-CAPS into the sa-CompositeSignature definition in the ASN.1 module -* Fixed nits and other typos -* Added PSS parameter Salt Lengths -* Changed the OID concatenation section to Domain Separators for clarity -* Accepted some edits by José Ignacio Escribano - -## Changes since adoption by the lamps working group -* Added back in the version 13 changes which were dropped by mistake in the initial -00 adopted version -* Added Scott Fluher as an author due to his valuable contributions and participation in the draft writing process -* Removed the reference to Parallel PKI's in implementation considerations as it isn't adding value to the discussion -* Resolved comments from Kris Kwiatkowski regarding FIPS - - # Composite Signature Schemes The engineering principle behind the definition of Composite schemes is to define a new family of algorithms that combines the use of cryptographic operations from two different ones: ML-DSA one and a traditional one.The complexity of combining security properties from the selected two algorithms is handled at the cryptographic library or cryptographic module, thus no changes are expected at the application or protocol level. Composite schemes are fully compatible with the X.509 model: composite public keys, composite private keys, and ciphertexts can be carried in existing data structures and protocols such as PKCS#10 [RFC2986], CMP [RFC4210], X.509 [RFC5280], CMS [RFC5652], and the Trust Anchor Format [RFC5914]. @@ -279,7 +279,7 @@ The following table shows the HEX encoding for each Signature AlgorithmID. Composite schemes' signature generation process and composite signature verification process are designed to provide security properties meant to address specific issues related to the use multiple algorithms and they require the use of pre-hasing. In Composite schemes, the value of the DER encoding of the selected signature scheme is concatenated with the calculated Hash over the original message. -The output is then used as input for the Sign() and Verify() functions. +The output is then used as input for the Sign() and Verify() functions. # Cryptographic Primitives {#sec-sigs}