From f7c84359f9d00cfd894df527a335d4012bb439f8 Mon Sep 17 00:00:00 2001 From: John Gray <55205977+johngray-dev@users.noreply.github.com> Date: Fri, 22 Nov 2024 09:02:34 -0500 Subject: [PATCH 01/24] Update draft-ietf-lamps-pq-composite-sigs.md First stab at removing SEQUENCE ASN.1 encodings --- draft-ietf-lamps-pq-composite-sigs.md | 159 ++++++++++++++++++++++---- 1 file changed, 135 insertions(+), 24 deletions(-) diff --git a/draft-ietf-lamps-pq-composite-sigs.md b/draft-ietf-lamps-pq-composite-sigs.md index efc1af7..a0fc1ee 100644 --- a/draft-ietf-lamps-pq-composite-sigs.md +++ b/draft-ietf-lamps-pq-composite-sigs.md @@ -261,6 +261,18 @@ Composite schemes are defined as cryptographic primitives that consist of three of the Message. If the signature and public key cannot verify the Message, it returns false. +We define the following algorithms which we use to serialize and deserialize the public and private keys + + * `SerializeKey(key) -> bytes`: Produce a fixed-length byte string encoding the public or private key. + + * `DeserializeKey(bytes) -> pk`: Parse a fixed-length byte string to recover a public or private key. This function can fail if the input byte string is malformed. + +We define the following algorithms which are used to serialize and deseralize the compsoite signature value + + * `SerializeSignature(key) -> bytes`: Produce a fixed-length byte string encoding the public or private key. + + * `DeserializeKey(bytes) -> pk`: Parse a fixed-length byte string to recover a public or private key. This function can fail if the input byte string is malformed. + A composite signature allows the security properties of the two underlying algorithms to be combined via standard signature operations `Sign()` and `Verify()`. This specification uses the Post-Quantum signature scheme ML-DSA as specified in [FIPS.204] and {{I-D.ietf-lamps-dilithium-certificates}}. For Traditional signature schemes, this document uses the RSA PKCS#1v1.5 and RSA-PSS algorithms defined in [RFC8017], the Elliptic Curve Digital Signature Algorithm ECDSA scheme defined in section 6 of [FIPS.186-5], and Ed25519 / Ed448 which are defined in [RFC8410]. A simple "signature combiner"function which prepends a domain separator value specific to the composite algorithm is used to bind the two component signatures to the composite algorithm and achieve weak non-separablity. @@ -655,6 +667,100 @@ Signature Verification Process: Note that in step 4 above, the function fails early if the first component fails to verify. Since no private keys are involved in a signature verification, there are no timing attacks to consider, so this is ok. +## SerializeKey and DeserializeKey + +The serialization routine for keys simply concatenates the fixed-length public or private keys of the component signatures, as defined below: +~~~ +Composite-ML-DSA.SerializeKey(key) -> bytes + +Explicit Input: + + key Composite ML-DSA public key or private key + +Implicit inputs: + + ML-DSA A placeholder for the specific ML-DSA algorithm and + parameter set to use, for example, could be "ML-DSA-65". + + Trad A placeholder for the specific traditional algorithm and + parameter set to use, for example "RSA" or "ECDSA". + +Output: + + bytes The encoded public key + +Serialization Process: + + 1. Separate the keys + + (mldsaKey, tradKey) = key + + 2. Serialize each of the constituent public keys + + mldsaEncodedKey = MLDSA.SerializeKey(mldsaKey) + tradEncodedKey = Trad.SerializeKey(tradKey) + + 3. Calculate the length encoding of the mldsaEncodedPK (or use the value from table ) + + encodedLength = IntegerToBytes(mldsaEncodePK.length, 3) + + 4. Combine and output the encoded public key + + bytes = encodedLength || mldsaEncodedPK || tradEncodedPK + output bytes +~~~ +{: #alg-composite-serialize title="Composite SerializeKey(pk)"} + +Deserialization reverses this process, raising an error in the event that the input is malformed. + +~~~ +Composite-ML-DSA.DeserializeKey(bytes) -> pk + +Explicit Input: + + bytes An encoded public key or private key + +Implicit inputs: + + ML-DSA A placeholder for the specific ML-DSA algorithm and + parameter set to use, for example, could be "ML-DSA-65". + + Trad A placeholder for the specific traditional algorithm and + parameter set to use, for example "RSA" or "ECDSA". + +Output: + + key The composite ML-DSA public key or private key + +Deserialization Process: + + 1. Validate the length of the the input byte string + + if bytes is not the correct length: + output "Deserialization error" + + 2. Parse each constituent encoded key + + (mldsaEncodedKey, tradEncodedKey) = bytes + + 3. Deserialize the constituent public or private keys + + mldsaKey = MLDSA.DeserializeKey(mldsaEncodedKey) + tradKey = Trad.DeserializeKey(tradEncodedKey) + + 4. If either ML-DSA.DeserializeKey() or + Trad.DeserializeKey() return an error, + then this process must return an error. + + if NOT mldsaKey or NOT tradKey: + output "Deserialization error" + + 5. Output the composite ML-DSA public key + + output (mldsaPK, tradPK) +~~~ +{: #alg-composite-deserialize title="Composite DeserializeKey(bytes)"} + # Composite Key Structures {#sec-composite-structs} @@ -666,35 +772,40 @@ In order to form composite public keys and signature values, we define ASN.1-bas The wire encoding of a Composite ML-DSA public key is: ~~~ ASN.1 -CompositeSignaturePublicKey ::= SEQUENCE SIZE (2) OF BIT STRING +CompositeSignaturePublicKey ::= BIT STRING ~~~ {: artwork-name="CompositeSignaturePublicKey-asn.1-structures"} -Since RSA and ECDSA component public keys are themselves in a DER encoding, the following ASN.1 structures show the internal structure of the various public key types used in this specification: +Since RSA and ECDSA component public keys are themselves in a DER encoding, the following show the internal structure of the various public key types used in this specification: ~~~ ASN.1 -RsaCompositeSignaturePublicKey ::= SEQUENCE { - firstPublicKey BIT STRING (ENCODED BY id-raw-key), - secondPublicKey BIT STRING (CONTAINING RSAPublicKey) - } - -EcCompositeSignaturePublicKey ::= SEQUENCE { - firstPublicKey BIT STRING (ENCODED BY id-raw-key), - secondPublicKey BIT STRING (CONTAINING ECPoint) - } - -EdCompositeSignaturePublicKey ::= SEQUENCE { - firstPublicKey BIT STRING (ENCODED BY id-raw-key), - secondPublicKey BIT STRING (ENCODED BY id-raw-key) - } +RsaCompositeSignaturePublicKey ::= BIT STRING + + The BIT STRING itself is generated by the concatenation of an ML-DSA key and an RSAPublicKey + + RsaCompositeSignaturePublicKey ::= BIT STRING (ENCODED BY id-raw-key) || BIT STRING (CONTAINING RSAPublicKey) + + +EcCompositeSignaturePublicKey ::= BIT STRING + + The BIT STRING itself is generated by the concatenation of an ML-DSA key and an ECDSAPublicKey + + RsaCompositeSignaturePublicKey ::= BIT STRING (ENCODED BY id-raw-key) || BIT STRING (CONTAINING ECPoint) + + +EdCompositeSignaturePublicKey ::= BIT STRING + + The BIT STRING itself is generated by the concatenation of an ML-DSA key and an Edwards public key + + RsaCompositeSignaturePublicKey ::= BIT STRING (ENCODED BY id-raw-key) || BIT STRING (ENCODED BY id-raw-key) ~~~ -`id-raw-key` is defined by this document. It signifies that the public key has no ASN.1 wrapping and the raw bits are placed here according to the encoding of the underlying algorithm specification. In some situations and protocols, the key might be wrapped in ASN.1 or -may have some other additional decoration or encoding. If so, such wrapping MUST be removed prior to encoding the key itself as a BIT STRING. -For use with this document, ML-DSA keys MUST be be the raw BIT STRING representation as specified in {{I-D.ietf-lamps-dilithium-certificates}} and Edwards Curve keys MUST be the raw BIT STRING representation as specified in [RFC8410]. +`id-raw-key` is defined by this document. It signifies that the public key has no ASN.1 wrapping and the raw bits are placed here according to the encoding of the underlying algorithm specification. In some situations and protocols, the key might be wrapped in ASN.1 or may have some other additional decoration or encoding. If so, such wrapping MUST be removed prior to encoding the key itself as a BIT STRING. + +For use with this document, ML-DSA keys MUST be the raw BIT STRING representation as specified in {{I-D.ietf-lamps-dilithium-certificates}} and Edwards Curve keys MUST be the raw BIT STRING representation as specified in [RFC8410]. -Some applications may need to reconstruct the `SubjectPublicKeyInfo` objects corresponding to each component public key. {{tab-sig-algs}} or {{tab-hash-sig-algs}} in {{sec-alg-ids}} provides the necessary mapping between composite and their component algorithms for doing this reconstruction. This also motivates the design choice of `SEQUENCE OF BIT STRING` instead of `SEQUENCE OF OCTET STRING`; using `BIT STRING` allows for easier transcription between CompositeSignaturePublicKey and SubjectPublicKeyInfo. +Some applications may need to reconstruct the `SubjectPublicKeyInfo` objects corresponding to each component public key. {{tab-sig-algs}} or {{tab-hash-sig-algs}} in {{sec-alg-ids}} provides the necessary mapping between composite and their component algorithms for doing this reconstruction. This also motivates the design choice of `BIT STRING` instead of `OCTET STRING`; using `BIT STRING` allows for easier transcription between CompositeSignaturePublicKey and SubjectPublicKeyInfo. When the CompositeSignaturePublicKey must be provided in octet string or bit string format, the data structure is encoded as specified in {{sec-encoding-rules}}. @@ -729,11 +840,11 @@ The full set of key types defined by this specification can be found in the ASN. When a Composite ML-DSA private key is to be exported from a cryptographic module, it uses an analogous definition to the public keys: ~~~ ASN.1 -CompositeSignaturePrivateKey ::= SEQUENCE SIZE (2) OF OCTET STRING +CompositeSignaturePrivateKey ::= OCTET STRING ~~~ {: artwork-name="CompositeSignaturePrivateKey-asn.1-structures"} -Each element of the `CompositeSignaturePrivateKey` Sequence is an `OCTET STRING` according to the encoding of the underlying algorithm specification and will decode into the respective private key structures in an analogous way to the public key structures defined in {{sec-composite-pub-keys}}. This document does not provide helper classes for private keys. The PrivateKey for each component algorithm MUST be in the same order as defined in {{sec-composite-pub-keys}}. +Each element of the `CompositeSignaturePrivateKey` is an `OCTET STRING` according to the encoding of the underlying algorithm specification and will decode into the respective private key structures in an analogous way to the public key structures defined in {{sec-composite-pub-keys}}. This document does not provide helper classes for private keys. The PrivateKey for each component algorithm MUST be in the same order as defined in {{sec-composite-pub-keys}}. Use cases that require an interoperable encoding for composite private keys will often need to place a `CompositeSignaturePrivateKey` inside a `OneAsymmetricKey` structure defined in [RFC5958], such as when private keys are carried in PKCS #12 [RFC7292], CMP [RFC4210] or CRMF [RFC4211]. The definition of `OneAsymmetricKey` is copied here for convenience: @@ -833,11 +944,11 @@ sa-CompositeSignature{OBJECT IDENTIFIER:id, The output of a Composite ML-DSA algorithm is the DER encoding of the following structure: -The `CompositeSignatureValue` is the DER encoing of a SEQUENCE of the signature values from the +The `CompositeSignatureValue` is the DER encoing of a concatendation of the signature values from the underlying component algorithms. It is represented in ASN.1 as follows: ~~~ asn.1 -CompositeSignatureValue ::= SEQUENCE SIZE (2) OF BIT STRING +CompositeSignatureValue ::= BIT STRING ~~~ {: artwork-name="composite-sig-asn.1"} From 2d76d211575f9afa25f0c2e6b293b7457a4a8434 Mon Sep 17 00:00:00 2001 From: John Gray <55205977+johngray-dev@users.noreply.github.com> Date: Fri, 22 Nov 2024 17:09:20 -0500 Subject: [PATCH 02/24] Update draft-ietf-lamps-pq-composite-sigs.md Removing Der encoding in discussion with Mike --- draft-ietf-lamps-pq-composite-sigs.md | 12 ++---------- 1 file changed, 2 insertions(+), 10 deletions(-) diff --git a/draft-ietf-lamps-pq-composite-sigs.md b/draft-ietf-lamps-pq-composite-sigs.md index a0fc1ee..8b0d006 100644 --- a/draft-ietf-lamps-pq-composite-sigs.md +++ b/draft-ietf-lamps-pq-composite-sigs.md @@ -800,9 +800,6 @@ EdCompositeSignaturePublicKey ::= BIT STRING RsaCompositeSignaturePublicKey ::= BIT STRING (ENCODED BY id-raw-key) || BIT STRING (ENCODED BY id-raw-key) ~~~ - -`id-raw-key` is defined by this document. It signifies that the public key has no ASN.1 wrapping and the raw bits are placed here according to the encoding of the underlying algorithm specification. In some situations and protocols, the key might be wrapped in ASN.1 or may have some other additional decoration or encoding. If so, such wrapping MUST be removed prior to encoding the key itself as a BIT STRING. - For use with this document, ML-DSA keys MUST be the raw BIT STRING representation as specified in {{I-D.ietf-lamps-dilithium-certificates}} and Edwards Curve keys MUST be the raw BIT STRING representation as specified in [RFC8410]. Some applications may need to reconstruct the `SubjectPublicKeyInfo` objects corresponding to each component public key. {{tab-sig-algs}} or {{tab-hash-sig-algs}} in {{sec-alg-ids}} provides the necessary mapping between composite and their component algorithms for doing this reconstruction. This also motivates the design choice of `BIT STRING` instead of `OCTET STRING`; using `BIT STRING` allows for easier transcription between CompositeSignaturePublicKey and SubjectPublicKeyInfo. @@ -844,7 +841,7 @@ CompositeSignaturePrivateKey ::= OCTET STRING ~~~ {: artwork-name="CompositeSignaturePrivateKey-asn.1-structures"} -Each element of the `CompositeSignaturePrivateKey` is an `OCTET STRING` according to the encoding of the underlying algorithm specification and will decode into the respective private key structures in an analogous way to the public key structures defined in {{sec-composite-pub-keys}}. This document does not provide helper classes for private keys. The PrivateKey for each component algorithm MUST be in the same order as defined in {{sec-composite-pub-keys}}. +Each element of the `CompositeSignaturePrivateKey` is an `OCTET STRING` according to the encoding of the underlying algorithm specification and will decode into the respective private key structures in an analogous way to the public key structures defined in {{sec-composite-pub-keys}}. The ASN.1 module in this document does not provide helper classes for private keys. The PrivateKey for each component algorithm MUST be in the same order as defined in {{sec-composite-pub-keys}}. Use cases that require an interoperable encoding for composite private keys will often need to place a `CompositeSignaturePrivateKey` inside a `OneAsymmetricKey` structure defined in [RFC5958], such as when private keys are carried in PKCS #12 [RFC7292], CMP [RFC4210] or CRMF [RFC4211]. The definition of `OneAsymmetricKey` is copied here for convenience: @@ -944,7 +941,7 @@ sa-CompositeSignature{OBJECT IDENTIFIER:id, The output of a Composite ML-DSA algorithm is the DER encoding of the following structure: -The `CompositeSignatureValue` is the DER encoing of a concatendation of the signature values from the +The `CompositeSignatureValue` is the DER encoding of a concatenation of the signature values from the underlying component algorithms. It is represented in ASN.1 as follows: ~~~ asn.1 @@ -1249,11 +1246,6 @@ EDNOTE to IANA: OIDs will need to be replaced in both the ASN.1 module and in {{ ### Object Identifier Registrations - SMI Security for PKIX Algorithms -- id-raw-key - - Decimal: IANA Assigned - - Description: Designates a public key BIT STRING with no ASN.1 structure. - - References: This Document - - id-MLDSA44-RSA2048-PSS-SHA256 - Decimal: IANA Assigned - Description: id-MLDSA44-RSA2048-PSS-SHA256 From a62c58558354aad53c8685f93dffc6078942203f Mon Sep 17 00:00:00 2001 From: John Gray <55205977+johngray-dev@users.noreply.github.com> Date: Fri, 22 Nov 2024 17:10:01 -0500 Subject: [PATCH 03/24] Update draft-ietf-lamps-pq-composite-sigs.md Agree. Co-authored-by: Mike Ounsworth --- draft-ietf-lamps-pq-composite-sigs.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/draft-ietf-lamps-pq-composite-sigs.md b/draft-ietf-lamps-pq-composite-sigs.md index 8b0d006..873a3cb 100644 --- a/draft-ietf-lamps-pq-composite-sigs.md +++ b/draft-ietf-lamps-pq-composite-sigs.md @@ -739,7 +739,10 @@ Deserialization Process: if bytes is not the correct length: output "Deserialization error" - 2. Parse each constituent encoded key + 2. Parse each constituent encoded key. + The first 3 bytes encodes the length of mldsaEncodedKey, which MAY + be used to separate the mldsaEncodedKey and tradEncodedKey, and then + is to be discarded. (mldsaEncodedKey, tradEncodedKey) = bytes From f009fd78428f893e13006a3a0d389edb5b1b0958 Mon Sep 17 00:00:00 2001 From: John Gray <55205977+johngray-dev@users.noreply.github.com> Date: Fri, 22 Nov 2024 17:10:42 -0500 Subject: [PATCH 04/24] Update draft-ietf-lamps-pq-composite-sigs.md Agree. Co-authored-by: Mike Ounsworth --- draft-ietf-lamps-pq-composite-sigs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-lamps-pq-composite-sigs.md b/draft-ietf-lamps-pq-composite-sigs.md index 873a3cb..baa7ef6 100644 --- a/draft-ietf-lamps-pq-composite-sigs.md +++ b/draft-ietf-lamps-pq-composite-sigs.md @@ -784,7 +784,7 @@ Since RSA and ECDSA component public keys are themselves in a DER encoding, the ~~~ ASN.1 RsaCompositeSignaturePublicKey ::= BIT STRING - The BIT STRING itself is generated by the concatenation of an ML-DSA key and an RSAPublicKey + The BIT STRING itself is generated by the concatenation of a raw ML-DSA key according to {{I-D.ietf-lamps-dilithium-certificates}}, and an RSAPublicKey (which is a DER encoded RSAPublicKey). RsaCompositeSignaturePublicKey ::= BIT STRING (ENCODED BY id-raw-key) || BIT STRING (CONTAINING RSAPublicKey) From efea4bb70147db84d8b440c219869d914dc95246 Mon Sep 17 00:00:00 2001 From: John Gray <55205977+johngray-dev@users.noreply.github.com> Date: Fri, 22 Nov 2024 17:11:00 -0500 Subject: [PATCH 05/24] Update draft-ietf-lamps-pq-composite-sigs.md Agree Co-authored-by: Mike Ounsworth --- draft-ietf-lamps-pq-composite-sigs.md | 1 - 1 file changed, 1 deletion(-) diff --git a/draft-ietf-lamps-pq-composite-sigs.md b/draft-ietf-lamps-pq-composite-sigs.md index baa7ef6..ad7a68c 100644 --- a/draft-ietf-lamps-pq-composite-sigs.md +++ b/draft-ietf-lamps-pq-composite-sigs.md @@ -786,7 +786,6 @@ RsaCompositeSignaturePublicKey ::= BIT STRING The BIT STRING itself is generated by the concatenation of a raw ML-DSA key according to {{I-D.ietf-lamps-dilithium-certificates}}, and an RSAPublicKey (which is a DER encoded RSAPublicKey). - RsaCompositeSignaturePublicKey ::= BIT STRING (ENCODED BY id-raw-key) || BIT STRING (CONTAINING RSAPublicKey) EcCompositeSignaturePublicKey ::= BIT STRING From a5d200baa77ddcee76e77612c0538f5902a7d563 Mon Sep 17 00:00:00 2001 From: John Gray <55205977+johngray-dev@users.noreply.github.com> Date: Fri, 22 Nov 2024 17:11:23 -0500 Subject: [PATCH 06/24] Update draft-ietf-lamps-pq-composite-sigs.md Agree. Co-authored-by: Mike Ounsworth --- draft-ietf-lamps-pq-composite-sigs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-lamps-pq-composite-sigs.md b/draft-ietf-lamps-pq-composite-sigs.md index ad7a68c..b186386 100644 --- a/draft-ietf-lamps-pq-composite-sigs.md +++ b/draft-ietf-lamps-pq-composite-sigs.md @@ -790,7 +790,7 @@ RsaCompositeSignaturePublicKey ::= BIT STRING EcCompositeSignaturePublicKey ::= BIT STRING - The BIT STRING itself is generated by the concatenation of an ML-DSA key and an ECDSAPublicKey + The BIT STRING itself is generated by the concatenation of a raw ML-DSA key according to {{I-D.ietf-lamps-dilithium-certificates}} and an ECDSAPublicKey (which is a DER encoded ECPoint). RsaCompositeSignaturePublicKey ::= BIT STRING (ENCODED BY id-raw-key) || BIT STRING (CONTAINING ECPoint) From b7b6edc26aea12e6314c747b2f53954d7a48ef6a Mon Sep 17 00:00:00 2001 From: John Gray <55205977+johngray-dev@users.noreply.github.com> Date: Fri, 22 Nov 2024 17:11:42 -0500 Subject: [PATCH 07/24] Update draft-ietf-lamps-pq-composite-sigs.md Agreed. Co-authored-by: Mike Ounsworth --- draft-ietf-lamps-pq-composite-sigs.md | 1 - 1 file changed, 1 deletion(-) diff --git a/draft-ietf-lamps-pq-composite-sigs.md b/draft-ietf-lamps-pq-composite-sigs.md index b186386..e61f263 100644 --- a/draft-ietf-lamps-pq-composite-sigs.md +++ b/draft-ietf-lamps-pq-composite-sigs.md @@ -792,7 +792,6 @@ EcCompositeSignaturePublicKey ::= BIT STRING The BIT STRING itself is generated by the concatenation of a raw ML-DSA key according to {{I-D.ietf-lamps-dilithium-certificates}} and an ECDSAPublicKey (which is a DER encoded ECPoint). - RsaCompositeSignaturePublicKey ::= BIT STRING (ENCODED BY id-raw-key) || BIT STRING (CONTAINING ECPoint) EdCompositeSignaturePublicKey ::= BIT STRING From 721f1c1961cccf2c8b56fce8f16a7d33825b99b3 Mon Sep 17 00:00:00 2001 From: John Gray <55205977+johngray-dev@users.noreply.github.com> Date: Fri, 22 Nov 2024 17:12:43 -0500 Subject: [PATCH 08/24] Update draft-ietf-lamps-pq-composite-sigs.md Agreed Co-authored-by: Mike Ounsworth --- draft-ietf-lamps-pq-composite-sigs.md | 1 - 1 file changed, 1 deletion(-) diff --git a/draft-ietf-lamps-pq-composite-sigs.md b/draft-ietf-lamps-pq-composite-sigs.md index e61f263..072ddf7 100644 --- a/draft-ietf-lamps-pq-composite-sigs.md +++ b/draft-ietf-lamps-pq-composite-sigs.md @@ -798,7 +798,6 @@ EdCompositeSignaturePublicKey ::= BIT STRING The BIT STRING itself is generated by the concatenation of an ML-DSA key and an Edwards public key - RsaCompositeSignaturePublicKey ::= BIT STRING (ENCODED BY id-raw-key) || BIT STRING (ENCODED BY id-raw-key) ~~~ For use with this document, ML-DSA keys MUST be the raw BIT STRING representation as specified in {{I-D.ietf-lamps-dilithium-certificates}} and Edwards Curve keys MUST be the raw BIT STRING representation as specified in [RFC8410]. From 0a0f3ea4207a96a4a64bd62deb50f48bdaa19830 Mon Sep 17 00:00:00 2001 From: John Gray <55205977+johngray-dev@users.noreply.github.com> Date: Fri, 22 Nov 2024 17:12:57 -0500 Subject: [PATCH 09/24] Update draft-ietf-lamps-pq-composite-sigs.md Agreed. Co-authored-by: Mike Ounsworth --- draft-ietf-lamps-pq-composite-sigs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-lamps-pq-composite-sigs.md b/draft-ietf-lamps-pq-composite-sigs.md index 072ddf7..a32903f 100644 --- a/draft-ietf-lamps-pq-composite-sigs.md +++ b/draft-ietf-lamps-pq-composite-sigs.md @@ -796,7 +796,7 @@ EcCompositeSignaturePublicKey ::= BIT STRING EdCompositeSignaturePublicKey ::= BIT STRING - The BIT STRING itself is generated by the concatenation of an ML-DSA key and an Edwards public key + The BIT STRING itself is generated by the concatenation of a raw ML-DSA key according to {{I-D.ietf-lamps-dilithium-certificates}} and a raw Edwards public key according to [RFC8410]. ~~~ From c1d0281c5f0a790bdf841b4b038d79adc27ad2a2 Mon Sep 17 00:00:00 2001 From: John Gray <55205977+johngray-dev@users.noreply.github.com> Date: Fri, 22 Nov 2024 17:21:24 -0500 Subject: [PATCH 10/24] Update draft-ietf-lamps-pq-composite-sigs.md Agreed. Co-authored-by: Mike Ounsworth --- draft-ietf-lamps-pq-composite-sigs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-lamps-pq-composite-sigs.md b/draft-ietf-lamps-pq-composite-sigs.md index a32903f..ac7f3d8 100644 --- a/draft-ietf-lamps-pq-composite-sigs.md +++ b/draft-ietf-lamps-pq-composite-sigs.md @@ -802,7 +802,7 @@ EdCompositeSignaturePublicKey ::= BIT STRING For use with this document, ML-DSA keys MUST be the raw BIT STRING representation as specified in {{I-D.ietf-lamps-dilithium-certificates}} and Edwards Curve keys MUST be the raw BIT STRING representation as specified in [RFC8410]. -Some applications may need to reconstruct the `SubjectPublicKeyInfo` objects corresponding to each component public key. {{tab-sig-algs}} or {{tab-hash-sig-algs}} in {{sec-alg-ids}} provides the necessary mapping between composite and their component algorithms for doing this reconstruction. This also motivates the design choice of `BIT STRING` instead of `OCTET STRING`; using `BIT STRING` allows for easier transcription between CompositeSignaturePublicKey and SubjectPublicKeyInfo. +Some applications may need to reconstruct the `SubjectPublicKeyInfo` objects corresponding to each component public key. {{tab-sig-algs}} or {{tab-hash-sig-algs}} in {{sec-alg-ids}} provides the necessary mapping between composite and their component algorithms for doing this reconstruction. When the CompositeSignaturePublicKey must be provided in octet string or bit string format, the data structure is encoded as specified in {{sec-encoding-rules}}. From 8e96eb547c144fa0cbcbd6258648370f5cc16389 Mon Sep 17 00:00:00 2001 From: John Gray <55205977+johngray-dev@users.noreply.github.com> Date: Fri, 22 Nov 2024 17:22:32 -0500 Subject: [PATCH 11/24] Update draft-ietf-lamps-pq-composite-sigs.md Agreed Co-authored-by: Mike Ounsworth --- draft-ietf-lamps-pq-composite-sigs.md | 1 - 1 file changed, 1 deletion(-) diff --git a/draft-ietf-lamps-pq-composite-sigs.md b/draft-ietf-lamps-pq-composite-sigs.md index ac7f3d8..2c01d76 100644 --- a/draft-ietf-lamps-pq-composite-sigs.md +++ b/draft-ietf-lamps-pq-composite-sigs.md @@ -800,7 +800,6 @@ EdCompositeSignaturePublicKey ::= BIT STRING ~~~ -For use with this document, ML-DSA keys MUST be the raw BIT STRING representation as specified in {{I-D.ietf-lamps-dilithium-certificates}} and Edwards Curve keys MUST be the raw BIT STRING representation as specified in [RFC8410]. Some applications may need to reconstruct the `SubjectPublicKeyInfo` objects corresponding to each component public key. {{tab-sig-algs}} or {{tab-hash-sig-algs}} in {{sec-alg-ids}} provides the necessary mapping between composite and their component algorithms for doing this reconstruction. From 11dddada02aad3e187b1e498ae25174a2f14d3f1 Mon Sep 17 00:00:00 2001 From: Mike Ounsworth Date: Fri, 22 Nov 2024 16:55:25 -0600 Subject: [PATCH 12/24] fix-lint --- draft-ietf-lamps-pq-composite-sigs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-lamps-pq-composite-sigs.md b/draft-ietf-lamps-pq-composite-sigs.md index 2c01d76..e939e0e 100644 --- a/draft-ietf-lamps-pq-composite-sigs.md +++ b/draft-ietf-lamps-pq-composite-sigs.md @@ -741,7 +741,7 @@ Deserialization Process: 2. Parse each constituent encoded key. The first 3 bytes encodes the length of mldsaEncodedKey, which MAY - be used to separate the mldsaEncodedKey and tradEncodedKey, and then + be used to separate the mldsaEncodedKey and tradEncodedKey, and then is to be discarded. (mldsaEncodedKey, tradEncodedKey) = bytes From a6d5f9835683051eaff9849dd1f5d421fb799ce9 Mon Sep 17 00:00:00 2001 From: Mike Ounsworth Date: Fri, 22 Nov 2024 16:55:57 -0600 Subject: [PATCH 13/24] fix-lint --- draft-ietf-lamps-pq-composite-sigs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-lamps-pq-composite-sigs.md b/draft-ietf-lamps-pq-composite-sigs.md index e939e0e..06bce43 100644 --- a/draft-ietf-lamps-pq-composite-sigs.md +++ b/draft-ietf-lamps-pq-composite-sigs.md @@ -740,7 +740,7 @@ Deserialization Process: output "Deserialization error" 2. Parse each constituent encoded key. - The first 3 bytes encodes the length of mldsaEncodedKey, which MAY + The first 3 bytes encodes the length of mldsaEncodedKey, which MAY be used to separate the mldsaEncodedKey and tradEncodedKey, and then is to be discarded. From f928720f5a45341b517b3c5a57414b1e4da43793 Mon Sep 17 00:00:00 2001 From: Mike Ounsworth Date: Fri, 22 Nov 2024 16:57:18 -0600 Subject: [PATCH 14/24] make fix-lint --- draft-ietf-lamps-pq-composite-sigs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-lamps-pq-composite-sigs.md b/draft-ietf-lamps-pq-composite-sigs.md index 06bce43..bf49cdd 100644 --- a/draft-ietf-lamps-pq-composite-sigs.md +++ b/draft-ietf-lamps-pq-composite-sigs.md @@ -268,7 +268,7 @@ We define the following algorithms which we use to serialize and deserialize the * `DeserializeKey(bytes) -> pk`: Parse a fixed-length byte string to recover a public or private key. This function can fail if the input byte string is malformed. We define the following algorithms which are used to serialize and deseralize the compsoite signature value - + * `SerializeSignature(key) -> bytes`: Produce a fixed-length byte string encoding the public or private key. * `DeserializeKey(bytes) -> pk`: Parse a fixed-length byte string to recover a public or private key. This function can fail if the input byte string is malformed. From 26ea6aca82d31ba0dd00d9efc7272227b5bf6a2a Mon Sep 17 00:00:00 2001 From: John Gray <55205977+johngray-dev@users.noreply.github.com> Date: Mon, 25 Nov 2024 17:38:50 -0500 Subject: [PATCH 15/24] Update draft-ietf-lamps-pq-composite-sigs.md Remove tags around serialization and deserialziation --- draft-ietf-lamps-pq-composite-sigs.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/draft-ietf-lamps-pq-composite-sigs.md b/draft-ietf-lamps-pq-composite-sigs.md index bf49cdd..9e262ea 100644 --- a/draft-ietf-lamps-pq-composite-sigs.md +++ b/draft-ietf-lamps-pq-composite-sigs.md @@ -670,6 +670,7 @@ Note that in step 4 above, the function fails early if the first component fails ## SerializeKey and DeserializeKey The serialization routine for keys simply concatenates the fixed-length public or private keys of the component signatures, as defined below: + ~~~ Composite-ML-DSA.SerializeKey(key) -> bytes @@ -709,7 +710,6 @@ Serialization Process: bytes = encodedLength || mldsaEncodedPK || tradEncodedPK output bytes ~~~ -{: #alg-composite-serialize title="Composite SerializeKey(pk)"} Deserialization reverses this process, raising an error in the event that the input is malformed. @@ -762,8 +762,6 @@ Deserialization Process: output (mldsaPK, tradPK) ~~~ -{: #alg-composite-deserialize title="Composite DeserializeKey(bytes)"} - # Composite Key Structures {#sec-composite-structs} From 55339558cec78c8beb0fa5ef865535857ea474ab Mon Sep 17 00:00:00 2001 From: John Gray <55205977+johngray-dev@users.noreply.github.com> Date: Mon, 25 Nov 2024 17:43:59 -0500 Subject: [PATCH 16/24] Update draft-ietf-lamps-pq-composite-sigs.md Add algorithm name back --- draft-ietf-lamps-pq-composite-sigs.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/draft-ietf-lamps-pq-composite-sigs.md b/draft-ietf-lamps-pq-composite-sigs.md index 9e262ea..9ae1d1f 100644 --- a/draft-ietf-lamps-pq-composite-sigs.md +++ b/draft-ietf-lamps-pq-composite-sigs.md @@ -710,6 +710,8 @@ Serialization Process: bytes = encodedLength || mldsaEncodedPK || tradEncodedPK output bytes ~~~ +{: #alg-composite-serialize title="Composite SerializeKey(pk)"} + Deserialization reverses this process, raising an error in the event that the input is malformed. From e5ae1ecd064dc4e3f89b5c9adb92d5c7ac499af5 Mon Sep 17 00:00:00 2001 From: John Gray <55205977+johngray-dev@users.noreply.github.com> Date: Mon, 25 Nov 2024 17:48:43 -0500 Subject: [PATCH 17/24] Update draft-ietf-lamps-pq-composite-sigs.md add title to Deserialization... I think there needed to be a new line between the tilde characters ~~~ --- draft-ietf-lamps-pq-composite-sigs.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-lamps-pq-composite-sigs.md b/draft-ietf-lamps-pq-composite-sigs.md index 9ae1d1f..2350c71 100644 --- a/draft-ietf-lamps-pq-composite-sigs.md +++ b/draft-ietf-lamps-pq-composite-sigs.md @@ -760,10 +760,11 @@ Deserialization Process: if NOT mldsaKey or NOT tradKey: output "Deserialization error" - 5. Output the composite ML-DSA public key + 5. Output the composite ML-DSA key output (mldsaPK, tradPK) ~~~ +{: #alg-composite-deserialize title="Composite DeserializeKey(bytes)"} # Composite Key Structures {#sec-composite-structs} From 30ac3dcd7210f5ed508e8cbd53bcca2c0d951b83 Mon Sep 17 00:00:00 2001 From: John Gray <55205977+johngray-dev@users.noreply.github.com> Date: Tue, 26 Nov 2024 12:01:58 -0500 Subject: [PATCH 18/24] Update Composite-MLDSA-2024.asn Updated ASN.1 module to reflect changes after removing the ASN.1 wrapping --- Composite-MLDSA-2024.asn | 33 +++++++-------------------------- 1 file changed, 7 insertions(+), 26 deletions(-) diff --git a/Composite-MLDSA-2024.asn b/Composite-MLDSA-2024.asn index 9a2256c..ddcc63c 100644 --- a/Composite-MLDSA-2024.asn +++ b/Composite-MLDSA-2024.asn @@ -64,7 +64,7 @@ id-raw-key OBJECT IDENTIFIER ::= { -- Composite Signature basic structures -- -CompositeSignaturePublicKey ::= SEQUENCE SIZE (2) OF BIT STRING +CompositeSignaturePublicKey ::= BIT STRING CompositeSignaturePublicKeyOs ::= OCTET STRING (CONTAINING CompositeSignaturePublicKey ENCODED BY der) @@ -72,36 +72,17 @@ CompositeSignaturePublicKeyOs ::= OCTET STRING (CONTAINING CompositeSignaturePublicKeyBs ::= BIT STRING (CONTAINING CompositeSignaturePublicKey ENCODED BY der) -CompositeSignaturePrivateKey ::= SEQUENCE SIZE (2) OF OCTET STRING +CompositeSignaturePrivateKey ::= OCTET STRING -CompositeSignatureValue ::= SEQUENCE SIZE (2) OF BIT STRING +-- Composite Signature Value is just an OCTET STRING -RsaCompositeSignaturePublicKey ::= SEQUENCE { - firstPublicKey BIT STRING (ENCODED BY id-raw-key), - secondPublicKey BIT STRING (CONTAINING RSAPublicKey) - } +CompositeSignatureValue ::= BIT STRING -EcCompositeSignaturePublicKey ::= SEQUENCE { - firstPublicKey BIT STRING (ENCODED BY id-raw-key), - secondPublicKey BIT STRING (CONTAINING ECPoint) - } - -EdCompositeSignaturePublicKey ::= SEQUENCE { - firstPublicKey BIT STRING (ENCODED BY id-raw-key), - secondPublicKey BIT STRING (ENCODED BY id-raw-key) - } - --- Composite Signature Value is just a sequence of OCTET STRINGS +RsaCompositeSignaturePublicKey ::= BIT STRING --- CompositeSignaturePair{FirstSignatureValue, SecondSignatureValue} ::= --- SEQUENCE { --- signaturevalue1 FirstSignatureValue, --- signaturevalue2 SecondSignatureValue } +EcCompositeSignaturePublicKey ::= BIT STRING --- An Explicit Compsite Signature is a set of Signatures which --- are composed of OCTET STRINGS --- ExplicitCompositeSignatureValue ::= CompositeSignaturePair { --- OCTET STRING,OCTET STRING} +EdCompositeSignaturePublicKey ::= BIT STRING -- From 6654275be4cad6e7b420dff380cc811d787a614e Mon Sep 17 00:00:00 2001 From: John Gray <55205977+johngray-dev@users.noreply.github.com> Date: Wed, 27 Nov 2024 13:10:55 -0500 Subject: [PATCH 19/24] Update draft-ietf-lamps-pq-composite-sigs.md - Updated Composite Signatures based on group discussion. Added ML-DSA Table for public, private and signature sizes --- draft-ietf-lamps-pq-composite-sigs.md | 195 +++++++++++++++++++------- 1 file changed, 141 insertions(+), 54 deletions(-) diff --git a/draft-ietf-lamps-pq-composite-sigs.md b/draft-ietf-lamps-pq-composite-sigs.md index 2350c71..c627e55 100644 --- a/draft-ietf-lamps-pq-composite-sigs.md +++ b/draft-ietf-lamps-pq-composite-sigs.md @@ -164,24 +164,15 @@ This document defines combinations of ML-DSA [FIPS.204] in hybrid with tradition --- middle -# Changes in -03 +# Changes in -04 Interop-affecting changes: -* Compacted CompositeSignaturePrivateKey to SEQUENCE SIZE (2) OF OCTET STRING instead of OneAsymmetricKey to remove redundancy -* Added support for the ML-DSA context String, and use the Composite Domain as the context for the underlying ML-DSA component algorithm. -* Added Pre-Hash and Pure modes and changed the Message format to align with FIPS-204. This breaks backwards compatibility with all previous versions. -* Updated the OID table for new Pre-Hash OIDs and added them to the IANA section. -* Updated Use in CMS section to reflect content is hashed and pure Composite ML-DSA should be used. +* Remove the ASN.1 SEQUENCE Wrapping around the Public Keys, Private Keys and Composite Signature Value +* TODO Remove the HashComposite-ML-DSA algorithms in favour of the external Mu hashing Editorial changes: -* Added the ASN.1 encodings for the component public keys and signature algorithm identifiers -* ASN.1 Module changes: - * Renamed the module from Composite-Signatures-2023 -> Composite-MLDSA-2024 - * Simplified the ASN.1 module to make it more compiler-friendly (thanks Carl!) -- should not affect wire encodings. -* Updated Security Considerations about Non-separability, EUF-CMA and key reuse. - # Introduction {#sec-intro} @@ -267,11 +258,11 @@ We define the following algorithms which we use to serialize and deserialize the * `DeserializeKey(bytes) -> pk`: Parse a fixed-length byte string to recover a public or private key. This function can fail if the input byte string is malformed. -We define the following algorithms which are used to serialize and deseralize the compsoite signature value +We define the following algorithms which are used to serialize and deseralize the composite signature value - * `SerializeSignature(key) -> bytes`: Produce a fixed-length byte string encoding the public or private key. + * `SerializeSignatureValue(CompositeSignatureValue) -> bytes`: Produce a fixed-length byte string encoding the CompositeSignatureValue. - * `DeserializeKey(bytes) -> pk`: Parse a fixed-length byte string to recover a public or private key. This function can fail if the input byte string is malformed. + * `DeserializeSignatureValue(bytes) -> pk`: Parse a fixed-length byte string to recover a CompositeSignatureValue. This function can fail if the input byte string is malformed. A composite signature allows the security properties of the two underlying algorithms to be combined via standard signature operations `Sign()` and `Verify()`. @@ -408,7 +399,7 @@ Signature Generation Process: 6. Encode each component signature into a CompositeSignatureValue. - signature := CompositeSignatureValue(mldsaSig, tradSig) + signature = CompositeSignatureValue(mldsaSig, tradSig) 7. Output signature @@ -701,13 +692,9 @@ Serialization Process: mldsaEncodedKey = MLDSA.SerializeKey(mldsaKey) tradEncodedKey = Trad.SerializeKey(tradKey) - 3. Calculate the length encoding of the mldsaEncodedPK (or use the value from table ) - - encodedLength = IntegerToBytes(mldsaEncodePK.length, 3) - - 4. Combine and output the encoded public key + 3. Combine and output the encoded public key - bytes = encodedLength || mldsaEncodedPK || tradEncodedPK + bytes = mldsaEncodedPK || tradEncodedPK output bytes ~~~ {: #alg-composite-serialize title="Composite SerializeKey(pk)"} @@ -742,9 +729,8 @@ Deserialization Process: output "Deserialization error" 2. Parse each constituent encoded key. - The first 3 bytes encodes the length of mldsaEncodedKey, which MAY - be used to separate the mldsaEncodedKey and tradEncodedKey, and then - is to be discarded. + The length of the mldsaEncodedKey is known based on the size of + the ML-DSA component key length specified by the Object ID (mldsaEncodedKey, tradEncodedKey) = bytes @@ -766,47 +752,148 @@ Deserialization Process: ~~~ {: #alg-composite-deserialize title="Composite DeserializeKey(bytes)"} -# Composite Key Structures {#sec-composite-structs} +## SerializeSignatureValue and DeSerializeSignatureValue -In order to form composite public keys and signature values, we define ASN.1-based composite encodings such that these structures can be used as a drop-in replacement for existing public key and signature fields such as those found in PKCS#10 [RFC2986], CMP [RFC4210], X.509 [RFC5280], CMS [RFC5652]. +The serialization routine for the CompositeSignatureValue simply concatenates the fixed-length +ML-DSA signature value with the signature value from the traditional algorithm, as defined below: +~~~ +Composite-ML-DSA.SerializeSignatureValue(CompositeSignatureValue) -> bytes -## CompositeSignaturePublicKey {#sec-composite-pub-keys} +Explicit Input: -The wire encoding of a Composite ML-DSA public key is: + CompositeSignatureValue The Composite Signature Value obtained from Composite-ML-DSA.Sign() -~~~ ASN.1 -CompositeSignaturePublicKey ::= BIT STRING +Implicit inputs: + + ML-DSA A placeholder for the specific ML-DSA algorithm and + parameter set to use, for example, could be "ML-DSA-65". + + Trad A placeholder for the specific traditional algorithm and + parameter set to use, for example "RSA" or "ECDSA". + +Output: + + bytes The encoded CompositeSignatureValue + +Serialization Process: + + 1. Separate the signatures + + (mldsaSig, tradSig) = CompositeSignatureValue + + 2. Serialize each of the constituent signatures + + mldsaEncodedSignature = ML-DSA.SerializeSignature(mldsaSig) + tradEncodedSignature = Trad.SerializeSignature(tradSig) + + 3. Combine and output the encoded public key + + bytes = mldsaEncodedSignature || tradEncodedSignature + output bytes ~~~ -{: artwork-name="CompositeSignaturePublicKey-asn.1-structures"} +{: #alg-composite-serialize title="Composite SerializeSignatureValue(CompositeSignatureValue)"} -Since RSA and ECDSA component public keys are themselves in a DER encoding, the following show the internal structure of the various public key types used in this specification: -~~~ ASN.1 -RsaCompositeSignaturePublicKey ::= BIT STRING +Deserialization reverses this process, raising an error in the event that the input is malformed. + +~~~ +Composite-ML-DSA.DeserializeSignatureValue(bytes) -> CompositeSignatureValue + +Explicit Input: + + bytes An encoded CompositeSignatureValue + +Implicit inputs: - The BIT STRING itself is generated by the concatenation of a raw ML-DSA key according to {{I-D.ietf-lamps-dilithium-certificates}}, and an RSAPublicKey (which is a DER encoded RSAPublicKey). + ML-DSA A placeholder for the specific ML-DSA algorithm and + parameter set to use, for example, could be "ML-DSA-65". + + Trad A placeholder for the specific traditional algorithm and + parameter set to use, for example "RSA" or "ECDSA". + +Output: + + CompositeSignatureValue The CompositeSignatureValue + +Deserialization Process: + + 1. Validate the length of the the input byte string + + if bytes is not the correct length: + output "Deserialization error" + + 2. Parse each constituent encoded signature. + The length of the mldsaEncodedSignature is known based on the size of + the ML-DSA component signature length specified by the Object ID + + (mldsaEncodedSignature, tradEncodedSignature) = bytes + + 3. Deserialize the constituent public or private keys + + mldsaSig = ML-DSA.DeserializeSignature(mldsaEncodedSignature) + tradSig = Trad.DeserializeSignature(tradEncodedSignature) + 4. If either ML-DSA.DeserializeSignature() or + Trad.DeserializeSignature() return an error, + then this process must return an error. + + if NOT mldsaSig or NOT tradSig: + output "Deserialization error" + + 5. Output the CompositeSignatureValue + + output (mldsaPK, tradPK) +~~~ +{: #alg-composite-deserialize title="Composite DeserializeSignatureValue(bytes)"} + +## ML-DSA public key, private key and Signature sizes for serialization and deserialization + +As noted above in the public key, private key and CompositeSignatureValue serialization and deserializations +methods, ML-DSA uses fixed-length values for all of these components. This means the length encoding of the +first component is known and NOT needed to be encoded into the serialization and deserialization process which +simplifies the encoding. If future composite combinations make use of algorithms where the first component uses +variable length keys or signatures, then that specification will need to ensure the length is encoded in a +fixed-length prefix so the components can be correctly deserialized. +The following table shows the fixed length values for the public, private and signature +sizes for ML-DSA which can be used to deserialzie the components. -EcCompositeSignaturePublicKey ::= BIT STRING +| Algorithm | Public Key Size| Private Key Size | Signature Size | +| ----------- | ----------- | ----------- | ----------- | +| ML-DSA-44 | 1312 | 2560 | 2420 | +| ML-DSA-65 | 1952 | 4032 | 3309 | +| ML-DSA-87 | 2592 | 4896 | 4627 | +{: #tab-mldsa-sizes title="ML-DSA Key and Signature Sizes"} - The BIT STRING itself is generated by the concatenation of a raw ML-DSA key according to {{I-D.ietf-lamps-dilithium-certificates}} and an ECDSAPublicKey (which is a DER encoded ECPoint). +# Composite Key Structures {#sec-composite-structs} +In order to form composite public keys and signature values, we define ASN.1-based composite encodings such that these structures can be used as a drop-in replacement for existing public key and signature fields such as those found in PKCS#10 [RFC2986], CMP [RFC4210], X.509 [RFC5280], CMS [RFC5652]. -EdCompositeSignaturePublicKey ::= BIT STRING - The BIT STRING itself is generated by the concatenation of a raw ML-DSA key according to {{I-D.ietf-lamps-dilithium-certificates}} and a raw Edwards public key according to [RFC8410]. +## CompositeMLDSAPublicKey {#sec-composite-pub-keys} + +The wire encoding of a Composite ML-DSA public key is: +~~~ ASN.1 +CompositeMLDSAPublicKey ::= BIT STRING ~~~ +{: artwork-name="CompositeMLDSAPublicKey-asn.1-structures"} + +Since RSA and ECDSA component public keys are themselves in a DER encoding, the following show the internal structure of the various public key types used in this specification: + +When a CompositeMLDSAPublicKey is used with an RSA public key, the BIT STRING is generated by the concatenation of a raw ML-DSA key according to {{I-D.ietf-lamps-dilithium-certificates}}, and an RSAPublicKey (which is a DER encoded RSAPublicKey). + +When a CompositeMLDSAPublicKey is used with an EC public key, the BIT STRING is generated by the concatenation of a raw ML-DSA key according to {{I-D.ietf-lamps-dilithium-certificates}} and an ECDSAPublicKey (which is a DER encoded ECPoint). +When a CompositeMLDSAPublicKey is used with an Edwards public key, the BIT STRING is generated by the concatenation of a raw ML-DSA key according to {{I-D.ietf-lamps-dilithium-certificates}} and a raw Edwards public key according to [RFC8410]. Some applications may need to reconstruct the `SubjectPublicKeyInfo` objects corresponding to each component public key. {{tab-sig-algs}} or {{tab-hash-sig-algs}} in {{sec-alg-ids}} provides the necessary mapping between composite and their component algorithms for doing this reconstruction. -When the CompositeSignaturePublicKey must be provided in octet string or bit string format, the data structure is encoded as specified in {{sec-encoding-rules}}. +When the CompositeMLDSAPublicKey must be provided in octet string or bit string format, the data structure is encoded as specified in {{sec-encoding-rules}}. -Component keys of a CompositeSignaturePublicKey MUST NOT be used in any other type of key or as a standalone key. For more details on the security considerations around key reuse, see section {{sec-cons-key-reuse}}. +Component keys of a CompositeMLDSAPublicKey MUST NOT be used in any other type of key or as a standalone key. For more details on the security considerations around key reuse, see section {{sec-cons-key-reuse}}. The following ASN.1 Information Object Class is defined to allow for compact definitions of each composite algorithm, leading to a smaller overall ASN.1 module. @@ -826,25 +913,25 @@ As an example, the public key type `id-MLDSA44-ECDSA-P256` is defined as: id-MLDSA44-ECDSA-P256 PUBLIC-KEY ::= pk-CompositeSignature{ id-MLDSA44-ECDSA-P256, - EcCompositeSignaturePublicKey } + CompositeMLDSAPublicKey } ~~~ The full set of key types defined by this specification can be found in the ASN.1 Module in {{sec-asn1-module}}. -## CompositeSignaturePrivateKey {#sec-priv-key} +## CompositeMLDSAPrivateKey {#sec-priv-key} When a Composite ML-DSA private key is to be exported from a cryptographic module, it uses an analogous definition to the public keys: ~~~ ASN.1 -CompositeSignaturePrivateKey ::= OCTET STRING +CompositeMLDSAPrivateKey ::= OCTET STRING ~~~ -{: artwork-name="CompositeSignaturePrivateKey-asn.1-structures"} +{: artwork-name="CompositeMLDSAPrivateKey-asn.1-structures"} -Each element of the `CompositeSignaturePrivateKey` is an `OCTET STRING` according to the encoding of the underlying algorithm specification and will decode into the respective private key structures in an analogous way to the public key structures defined in {{sec-composite-pub-keys}}. The ASN.1 module in this document does not provide helper classes for private keys. The PrivateKey for each component algorithm MUST be in the same order as defined in {{sec-composite-pub-keys}}. +Each element of the `CompositeMLDSAPrivateKey` is an `OCTET STRING` according to the encoding of the underlying algorithm specification and will decode into the respective private key structures in an analogous way to the public key structures defined in {{sec-composite-pub-keys}}. The ASN.1 module in this document does not provide helper classes for private keys. The PrivateKey for each component algorithm MUST be in the same order as defined in {{sec-composite-pub-keys}}. -Use cases that require an interoperable encoding for composite private keys will often need to place a `CompositeSignaturePrivateKey` inside a `OneAsymmetricKey` structure defined in [RFC5958], such as when private keys are carried in PKCS #12 [RFC7292], CMP [RFC4210] or CRMF [RFC4211]. The definition of `OneAsymmetricKey` is copied here for convenience: +Use cases that require an interoperable encoding for composite private keys will often need to place a `CompositeMLDSAPrivateKey` inside a `OneAsymmetricKey` structure defined in [RFC5958], such as when private keys are carried in PKCS #12 [RFC7292], CMP [RFC4210] or CRMF [RFC4211]. The definition of `OneAsymmetricKey` is copied here for convenience: ~~~ ASN.1 OneAsymmetricKey ::= SEQUENCE { @@ -865,11 +952,11 @@ Use cases that require an interoperable encoding for composite private keys will {: artwork-name="RFC5958-OneAsymmetricKey-asn.1-structure"} -When a `CompositeSignaturePrivateKey` is conveyed inside a OneAsymmetricKey structure (version 1 of which is also known as PrivateKeyInfo) [RFC5958], the privateKeyAlgorithm field SHALL be set to the corresponding composite algorithm identifier defined according to {{sec-alg-ids}} and its parameters field MUST be absent. The privateKey field SHALL contain the `CompositeSignaturePrivateKey`, and the `publicKey` field remains OPTIONAL. If the `publicKey` field is present, it MUST be a `CompositeSignaturePublicKey`. +When a `CompositeMLDSAPrivateKey` is conveyed inside a OneAsymmetricKey structure (version 1 of which is also known as PrivateKeyInfo) [RFC5958], the privateKeyAlgorithm field SHALL be set to the corresponding composite algorithm identifier defined according to {{sec-alg-ids}} and its parameters field MUST be absent. The privateKey field SHALL contain the `CompositeMLDSAPrivateKey`, and the `publicKey` field remains OPTIONAL. If the `publicKey` field is present, it MUST be a `CompositeMLDSAPublicKey`. Some applications may need to reconstruct the `OneAsymmetricKey` objects corresponding to each component private key. {{sec-alg-ids}} provides the necessary mapping between composite and their component algorithms for doing this reconstruction. -Component keys of a CompositeSignaturePrivateKey MUST NOT be used in any other type of key or as a standalone key. For more details on the security considerations around key reuse, see section {{sec-cons-key-reuse}}. +Component keys of a CompositeMLDSAPrivateKey MUST NOT be used in any other type of key or as a standalone key. For more details on the security considerations around key reuse, see section {{sec-cons-key-reuse}}. ## Encoding Rules {#sec-encoding-rules} @@ -880,15 +967,15 @@ Many protocol specifications will require that the composite public key and comp When an octet string is required, the DER encoding of the composite data structure SHALL be used directly. ~~~ ASN.1 -CompositeSignaturePublicKeyOs ::= OCTET STRING - (CONTAINING CompositeSignaturePublicKey ENCODED BY der) +CompositeMLDSAPublicKeyOs ::= OCTET STRING + (CONTAINING CompositeMLDSAPublicKey ENCODED BY der) ~~~ When a bit string is required, the octets of the DER encoded composite data structure SHALL be used as the bits of the bit string, with the most significant bit of the first octet becoming the first bit, and so on, ending with the least significant bit of the last octet becoming the last bit of the bit string. ~~~ ASN.1 -CompositeSignaturePublicKeyBs ::= BIT STRING - (CONTAINING CompositeSignaturePublicKey ENCODED BY der) +CompositeMLDSAPublicKeyBs ::= BIT STRING + (CONTAINING CompositeMLDSAPublicKey ENCODED BY der) ~~~ In the interests of simplicity and avoiding compatibility issues, implementations that parse these structures MAY accept both BER and DER. From 039a5957268e1309ec51546daa977b858eee4d7e Mon Sep 17 00:00:00 2001 From: John Gray <55205977+johngray-dev@users.noreply.github.com> Date: Wed, 27 Nov 2024 14:27:55 -0500 Subject: [PATCH 20/24] Update draft-ietf-lamps-pq-composite-sigs.md Fix title for signature serialization --- 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 c627e55..9198479 100644 --- a/draft-ietf-lamps-pq-composite-sigs.md +++ b/draft-ietf-lamps-pq-composite-sigs.md @@ -792,7 +792,7 @@ Serialization Process: bytes = mldsaEncodedSignature || tradEncodedSignature output bytes ~~~ -{: #alg-composite-serialize title="Composite SerializeSignatureValue(CompositeSignatureValue)"} +{: #alg-composite-serialize-sig title="Composite SerializeSignatureValue(CompositeSignatureValue)"} Deserialization reverses this process, raising an error in the event that the input is malformed. @@ -845,7 +845,7 @@ Deserialization Process: output (mldsaPK, tradPK) ~~~ -{: #alg-composite-deserialize title="Composite DeserializeSignatureValue(bytes)"} +{: #alg-composite-deserialize-sig title="Composite DeserializeSignatureValue(bytes)"} ## ML-DSA public key, private key and Signature sizes for serialization and deserialization From a335aef16be08d74f927e68af6c49e70acc7ac0a Mon Sep 17 00:00:00 2001 From: John Gray <55205977+johngray-dev@users.noreply.github.com> Date: Wed, 27 Nov 2024 15:08:50 -0500 Subject: [PATCH 21/24] Updated private key size for ML-DSA to 32 bytes --- draft-ietf-lamps-pq-composite-sigs.md | 20 +++++--------------- 1 file changed, 5 insertions(+), 15 deletions(-) diff --git a/draft-ietf-lamps-pq-composite-sigs.md b/draft-ietf-lamps-pq-composite-sigs.md index 9198479..de2978a 100644 --- a/draft-ietf-lamps-pq-composite-sigs.md +++ b/draft-ietf-lamps-pq-composite-sigs.md @@ -856,14 +856,14 @@ simplifies the encoding. If future composite combinations make use of algorithm variable length keys or signatures, then that specification will need to ensure the length is encoded in a fixed-length prefix so the components can be correctly deserialized. -The following table shows the fixed length values for the public, private and signature +The following table shows the fixed length values in bytes for the public, private and signature sizes for ML-DSA which can be used to deserialzie the components. -| Algorithm | Public Key Size| Private Key Size | Signature Size | +| Algorithm | Public Key | Private Key | Signature | | ----------- | ----------- | ----------- | ----------- | -| ML-DSA-44 | 1312 | 2560 | 2420 | -| ML-DSA-65 | 1952 | 4032 | 3309 | -| ML-DSA-87 | 2592 | 4896 | 4627 | +| ML-DSA-44 | 1312 | 32 | 2420 | +| ML-DSA-65 | 1952 | 32 | 3309 | +| ML-DSA-87 | 2592 | 32 | 4627 | {: #tab-mldsa-sizes title="ML-DSA Key and Signature Sizes"} @@ -966,18 +966,8 @@ Many protocol specifications will require that the composite public key and comp When an octet string is required, the DER encoding of the composite data structure SHALL be used directly. -~~~ ASN.1 -CompositeMLDSAPublicKeyOs ::= OCTET STRING - (CONTAINING CompositeMLDSAPublicKey ENCODED BY der) -~~~ - When a bit string is required, the octets of the DER encoded composite data structure SHALL be used as the bits of the bit string, with the most significant bit of the first octet becoming the first bit, and so on, ending with the least significant bit of the last octet becoming the last bit of the bit string. -~~~ ASN.1 -CompositeMLDSAPublicKeyBs ::= BIT STRING - (CONTAINING CompositeMLDSAPublicKey ENCODED BY der) -~~~ - In the interests of simplicity and avoiding compatibility issues, implementations that parse these structures MAY accept both BER and DER. ## Key Usage Bits From f2cee9a2c642bf28e2576c9b97b01d2fcbdc5016 Mon Sep 17 00:00:00 2001 From: John Gray <55205977+johngray-dev@users.noreply.github.com> Date: Wed, 27 Nov 2024 15:19:13 -0500 Subject: [PATCH 22/24] Remove DER encodings and fix a couple errors --- Composite-MLDSA-2024.asn | 129 +++++++++++++++++---------------------- 1 file changed, 56 insertions(+), 73 deletions(-) diff --git a/Composite-MLDSA-2024.asn b/Composite-MLDSA-2024.asn index ddcc63c..8f1159f 100644 --- a/Composite-MLDSA-2024.asn +++ b/Composite-MLDSA-2024.asn @@ -14,30 +14,6 @@ IMPORTS { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-algorithmInformation-02(58) } - - SubjectPublicKeyInfo - FROM PKIX1Explicit-2009 - { iso(1) identified-organization(3) dod(6) internet(1) - security(5) mechanisms(5) pkix(7) id-mod(0) - id-mod-pkix1-explicit-02(51) } - - OneAsymmetricKey - FROM AsymmetricKeyPackageModuleV1 - { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) - pkcs-9(9) smime(16) modules(0) - id-mod-asymmetricKeyPkgV1(50) } - - RSAPublicKey, ECPoint - FROM PKIXAlgs-2009 - { iso(1) identified-organization(3) dod(6) - internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) - id-mod-pkix1-algorithms2008-02(56) } - - sa-rsaSSA-PSS - FROM PKIX1-PSS-OAEP-Algorithms-2009 - {iso(1) identified-organization(3) dod(6) internet(1) security(5) - mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-rsa-pkalgs-02(54)} - ; -- @@ -48,41 +24,48 @@ IMPORTS der OBJECT IDENTIFIER ::= {joint-iso-itu-t asn1(1) ber-derived(2) distinguished-encoding(1)} - --- Just for testing, to be assigned by IANA -id-raw-key OBJECT IDENTIFIER ::= { - joint-iso-itu-t(2) country(16) us(840) organization(1) - entrust(114027) algorithm(80) composite(8) raw(999) 1 } - - -- -- Signature Algorithm -- - -- -- Composite Signature basic structures -- -CompositeSignaturePublicKey ::= BIT STRING +-- +-- When a CompositeMLDSAPublicKey is used with an RSA public key, the BIT STRING is generated +-- by the concatenation of a raw ML-DSA key according to {{I-D.ietf-lamps-dilithium-certificates}}, +-- and an RSAPublicKey (which is a DER encoded RSAPublicKey). + +-- When a CompositeMLDSAPublicKey is used with an EC public key, the BIT STRING is generated +-- by the concatenation of a raw ML-DSA key according to {{I-D.ietf-lamps-dilithium-certificates}} +-- and an ECDSAPublicKey according to [RFC5480]. -CompositeSignaturePublicKeyOs ::= OCTET STRING (CONTAINING - CompositeSignaturePublicKey ENCODED BY der) +-- When a CompositeMLDSAPublicKey is used with an Edwards public key, the BIT STRING is generated +-- by the concatenation of a raw ML-DSA key according to {{I-D.ietf-lamps-dilithium-certificates}} +-- and a raw Edwards public key according to [RFC8410]. -CompositeSignaturePublicKeyBs ::= BIT STRING (CONTAINING - CompositeSignaturePublicKey ENCODED BY der) +CompositeMLDSAPublicKey ::= BIT STRING -CompositeSignaturePrivateKey ::= OCTET STRING +-- +-- When a CompositeMLDSAPrivateKey is used with an RSA public key, the OCTET STRING is generated +-- by the concatenation of an ML-DSA private key according to {{I-D.ietf-lamps-dilithium-certificates}}, +-- and an RSAPrivateKey (which is a DER encoded RSAPrivateKey). --- Composite Signature Value is just an OCTET STRING +-- When a CompositeMLDSAPrivateKey is used with an EC public key, the OCTET STRING is generated +-- by the concatenation of an ML-DSA private key according to {{I-D.ietf-lamps-dilithium-certificates}}, +-- and an ECDSAPrivateKey according to [RFC5915]. -CompositeSignatureValue ::= BIT STRING +-- When a CompositeMLDSAPrivateKey is used with an Edwards public key, the OCTET STRING is generated +-- by the concatenation of an ML-DSA private key according to {{I-D.ietf-lamps-dilithium-certificates}}, +-- and a raw Edwards private key according to [RFC8410]. -RsaCompositeSignaturePublicKey ::= BIT STRING +CompositeMLDSAPrivateKey ::= OCTET STRING -EcCompositeSignaturePublicKey ::= BIT STRING +-- Composite Signature Value is just an BIT STRING and is a concatenation of the component signature +-- algorithms. -EdCompositeSignaturePublicKey ::= BIT STRING +CompositeSignatureValue ::= BIT STRING -- @@ -115,7 +98,7 @@ id-MLDSA44-RSA2048-PSS OBJECT IDENTIFIER ::= { pk-MLDSA44-RSA2048-PSS PUBLIC-KEY ::= pk-CompositeSignature{ id-MLDSA44-RSA2048-PSS, - RsaCompositeSignaturePublicKey} + CompositeMLDSAPublicKey} sa-MLDSA44-RSA2048-PSS SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ @@ -129,7 +112,7 @@ id-MLDSA44-RSA2048-PKCS15 OBJECT IDENTIFIER ::= { pk-MLDSA44-RSA2048-PKCS15 PUBLIC-KEY ::= pk-CompositeSignature{ id-MLDSA44-RSA2048-PKCS15, - RsaCompositeSignaturePublicKey} + CompositeMLDSAPublicKey} sa-MLDSA44-RSA2048-PKCS15 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ @@ -144,7 +127,7 @@ id-MLDSA44-Ed25519 OBJECT IDENTIFIER ::= { pk-MLDSA44-Ed25519 PUBLIC-KEY ::= pk-CompositeSignature{ id-MLDSA44-Ed25519, - EdCompositeSignaturePublicKey} + CompositeMLDSAPublicKey} sa-MLDSA44-Ed25519 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ @@ -159,7 +142,7 @@ id-MLDSA44-ECDSA-P256 OBJECT IDENTIFIER ::= { pk-MLDSA44-ECDSA-P256 PUBLIC-KEY ::= pk-CompositeSignature{ id-MLDSA44-ECDSA-P256, - EcCompositeSignaturePublicKey} + CompositeMLDSAPublicKey} sa-MLDSA44-ECDSA-P256 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ @@ -174,7 +157,7 @@ id-MLDSA65-RSA3072-PSS OBJECT IDENTIFIER ::= { pk-MLDSA65-RSA3072-PSS PUBLIC-KEY ::= pk-CompositeSignature{ id-MLDSA65-RSA3072-PSS, - RsaCompositeSignaturePublicKey} + CompositeMLDSAPublicKey} sa-MLDSA65-RSA3072-PSS SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ @@ -189,7 +172,7 @@ id-MLDSA65-RSA3072-PKCS15 OBJECT IDENTIFIER ::= { pk-MLDSA65-RSA3072-PKCS15 PUBLIC-KEY ::= pk-CompositeSignature{ id-MLDSA65-RSA3072-PKCS15, - RsaCompositeSignaturePublicKey} + CompositeMLDSAPublicKey} sa-MLDSA65-RSA3072-PKCS15 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ @@ -203,7 +186,7 @@ id-MLDSA65-RSA4096-PSS OBJECT IDENTIFIER ::= { pk-MLDSA65-RSA4096-PSS PUBLIC-KEY ::= pk-CompositeSignature{ id-MLDSA65-RSA4096-PSS, - RsaCompositeSignaturePublicKey} + CompositeMLDSAPublicKey} sa-MLDSA65-RSA4096-PSS SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ @@ -218,12 +201,12 @@ id-MLDSA65-RSA4096-PKCS15 OBJECT IDENTIFIER ::= { pk-MLDSA65-RSA4096-PKCS15 PUBLIC-KEY ::= pk-CompositeSignature{ id-MLDSA65-RSA4096-PKCS15, - RsaCompositeSignaturePublicKey} + CompositeMLDSAPublicKey} sa-MLDSA65-RSA4096-PKCS15 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ - id-MLDSA65-RSA4096-SHA512, - pk-MLDSA65-RSA4096-SHA512 } + id-MLDSA65-RSA4096-PKCS15, + pk-MLDSA65-RSA4096-PKCS15 } -- TODO: OID to be replaced by IANA id-MLDSA65-ECDSA-P384 OBJECT IDENTIFIER ::= { @@ -232,7 +215,7 @@ id-MLDSA65-ECDSA-P384 OBJECT IDENTIFIER ::= { pk-MLDSA65-ECDSA-P384 PUBLIC-KEY ::= pk-CompositeSignature{ id-MLDSA65-ECDSA-P384, - EcCompositeSignaturePublicKey} + CompositeMLDSAPublicKey} sa-MLDSA65-ECDSA-P256 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ @@ -247,7 +230,7 @@ id-MLDSA65-ECDSA-brainpoolP256r1 OBJECT IDENTIFIER ::= { pk-MLDSA65-ECDSA-brainpoolP256r1 PUBLIC-KEY ::= pk-CompositeSignature{ id-MLDSA65-ECDSA-brainpoolP256r1, - EcCompositeSignaturePublicKey} + CompositeMLDSAPublicKey} sa-MLDSA65-ECDSA-brainpoolP256r1 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ @@ -262,7 +245,7 @@ id-MLDSA65-Ed25519 OBJECT IDENTIFIER ::= { pk-MLDSA65-Ed25519 PUBLIC-KEY ::= pk-CompositeSignature{ id-MLDSA65-Ed25519, - EdCompositeSignaturePublicKey} + CompositeMLDSAPublicKey} sa-MLDSA65-Ed25519 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ @@ -277,7 +260,7 @@ id-MLDSA87-ECDSA-P384 OBJECT IDENTIFIER ::= { pk-MLDSA87-ECDSA-P384 PUBLIC-KEY ::= pk-CompositeSignature{ id-MLDSA87-ECDSA-P384, - EcCompositeSignaturePublicKey} + CompositeMLDSAPublicKey} sa-MLDSA87-ECDSA-P384 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ @@ -292,7 +275,7 @@ id-MLDSA87-ECDSA-brainpoolP384r1 OBJECT IDENTIFIER ::= { pk-MLDSA87-ECDSA-brainpoolP384r1 PUBLIC-KEY ::= pk-CompositeSignature{ id-MLDSA87-ECDSA-brainpoolP384r1, - EcCompositeSignaturePublicKey} + CompositeMLDSAPublicKey} sa-MLDSA87-ECDSA-brainpoolP384r1 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ @@ -307,7 +290,7 @@ id-MLDSA87-Ed448 OBJECT IDENTIFIER ::= { pk-MLDSA87-Ed448 PUBLIC-KEY ::= pk-CompositeSignature{ id-MLDSA87-Ed448, - EdCompositeSignaturePublicKey} + CompositeMLDSAPublicKey} sa-MLDSA87-Ed448 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ @@ -324,7 +307,7 @@ id-HashMLDSA44-RSA2048-PSS-SHA256 OBJECT IDENTIFIER ::= { pk-HashMLDSA44-RSA2048-PSS-SHA256 PUBLIC-KEY ::= pk-CompositeSignature{ id-HashMLDSA44-RSA2048-PSS-SHA256, - RsaCompositeSignaturePublicKey} + CompositeMLDSAPublicKey} sa-HashMLDSA44-RSA2048-PSS-SHA256 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ @@ -338,7 +321,7 @@ id-HashMLDSA44-RSA2048-PKCS15-SHA256 OBJECT IDENTIFIER ::= { pk-HashMLDSA44-RSA2048-PKCS15-SHA256 PUBLIC-KEY ::= pk-CompositeSignature{ id-HashMLDSA44-RSA2048-PKCS15-SHA256, - RsaCompositeSignaturePublicKey} + CompositeMLDSAPublicKey} sa-HashMLDSA44-RSA2048-PKCS15-SHA256 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ @@ -353,7 +336,7 @@ id-HashMLDSA44-Ed25519-SHA512 OBJECT IDENTIFIER ::= { pk-HashMLDSA44-Ed25519-SHA512 PUBLIC-KEY ::= pk-CompositeSignature{ id-HashMLDSA44-Ed25519-SHA512, - EdCompositeSignaturePublicKey} + CompositeMLDSAPublicKey} sa-HashMLDSA44-Ed25519-SHA512 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ @@ -368,7 +351,7 @@ id-HashMLDSA44-ECDSA-P256-SHA256 OBJECT IDENTIFIER ::= { pk-HashMLDSA44-ECDSA-P256-SHA256 PUBLIC-KEY ::= pk-CompositeSignature{ id-HashMLDSA44-ECDSA-P256-SHA256, - EcCompositeSignaturePublicKey} + CompositeMLDSAPublicKey} sa-HashMLDSA44-ECDSA-P256-SHA256 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ @@ -383,7 +366,7 @@ id-HashMLDSA65-RSA3072-PSS-SHA512 OBJECT IDENTIFIER ::= { pk-HashMLDSA65-RSA3072-PSS-SHA512 PUBLIC-KEY ::= pk-CompositeSignature{ id-HashMLDSA65-RSA3072-PSS-SHA512, - RsaCompositeSignaturePublicKey} + CompositeMLDSAPublicKey} sa-HashMLDSA65-RSA3072-PSS-SHA512 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ @@ -398,7 +381,7 @@ id-HashMLDSA65-RSA3072-PKCS15-SHA512 OBJECT IDENTIFIER ::= { pk-HashMLDSA65-RSA3072-PKCS15-SHA512 PUBLIC-KEY ::= pk-CompositeSignature{ id-HashMLDSA65-RSA3072-PKCS15-SHA512, - RsaCompositeSignaturePublicKey} + CompositeMLDSAPublicKey} sa-HashMLDSA65-RSA3072-PKCS15-SHA512 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ @@ -412,7 +395,7 @@ id-HashMLDSA65-RSA4096-PSS-SHA512 OBJECT IDENTIFIER ::= { pk-HashMLDSA65-RSA4096-PSS-SHA512 PUBLIC-KEY ::= pk-CompositeSignature{ id-HashMLDSA65-RSA4096-PSS-SHA512, - RsaCompositeSignaturePublicKey} + CompositeMLDSAPublicKey} sa-HashMLDSA65-RSA4096-PSS-SHA512 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ @@ -427,7 +410,7 @@ id-HashMLDSA65-RSA4096-PKCS15-SHA512 OBJECT IDENTIFIER ::= { pk-HashMLDSA65-RSA4096-PKCS15-SHA512 PUBLIC-KEY ::= pk-CompositeSignature{ id-HashMLDSA65-RSA4096-PKCS15-SHA512, - RsaCompositeSignaturePublicKey} + CompositeMLDSAPublicKey} sa-HashMLDSA65-RSA4096-PKCS15-SHA512 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ @@ -441,7 +424,7 @@ id-HashMLDSA65-ECDSA-P384-SHA512 OBJECT IDENTIFIER ::= { pk-HashMLDSA65-ECDSA-P384-SHA512 PUBLIC-KEY ::= pk-CompositeSignature{ id-HashMLDSA65-ECDSA-P384-SHA512, - EcCompositeSignaturePublicKey} + CompositeMLDSAPublicKey} sa-HashMLDSA65-ECDSA-P256-SHA512 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ @@ -456,7 +439,7 @@ id-HashMLDSA65-ECDSA-brainpoolP256r1-SHA512 OBJECT IDENTIFIER ::= { pk-HashMLDSA65-ECDSA-brainpoolP256r1-SHA512 PUBLIC-KEY ::= pk-CompositeSignature{ id-HashMLDSA65-ECDSA-brainpoolP256r1-SHA512, - EcCompositeSignaturePublicKey} + CompositeMLDSAPublicKey} sa-HashMLDSA65-ECDSA-brainpoolP256r1-SHA512 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ @@ -471,7 +454,7 @@ id-HashMLDSA65-Ed25519-SHA512 OBJECT IDENTIFIER ::= { pk-HashMLDSA65-Ed25519-SHA512 PUBLIC-KEY ::= pk-CompositeSignature{ id-HashMLDSA65-Ed25519-SHA512, - EdCompositeSignaturePublicKey} + CompositeMLDSAPublicKey} sa-HashMLDSA65-Ed25519-SHA512 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ @@ -486,7 +469,7 @@ id-HashMLDSA87-ECDSA-P384-SHA512 OBJECT IDENTIFIER ::= { pk-HashMLDSA87-ECDSA-P384-SHA512 PUBLIC-KEY ::= pk-CompositeSignature{ id-HashMLDSA87-ECDSA-P384-SHA512, - EcCompositeSignaturePublicKey} + CompositeMLDSAPublicKey} sa-HashMLDSA87-ECDSA-P384-SHA512 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ @@ -501,7 +484,7 @@ id-HashMLDSA87-ECDSA-brainpoolP384r1-SHA512 OBJECT IDENTIFIER ::= { pk-HashMLDSA87-ECDSA-brainpoolP384r1-SHA512 PUBLIC-KEY ::= pk-CompositeSignature{ id-HashMLDSA87-ECDSA-brainpoolP384r1-SHA512, - EcCompositeSignaturePublicKey} + CompositeMLDSAPublicKey} sa-HashMLDSA87-ECDSA-brainpoolP384r1-SHA512 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ @@ -516,7 +499,7 @@ id-HashMLDSA87-Ed448-SHA512 OBJECT IDENTIFIER ::= { pk-HashMLDSA87-Ed448-SHA512 PUBLIC-KEY ::= pk-CompositeSignature{ id-HashMLDSA87-Ed448-SHA512, - EdCompositeSignaturePublicKey} + CompositeMLDSAPublicKey} sa-HashMLDSA87-Ed448-SHA512 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ From 06b990eec550584fd1aaafc0bf7eef57da8040df Mon Sep 17 00:00:00 2001 From: John Gray <55205977+johngray-dev@users.noreply.github.com> Date: Wed, 27 Nov 2024 15:23:32 -0500 Subject: [PATCH 23/24] Fix a couple typos --- draft-ietf-lamps-pq-composite-sigs.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/draft-ietf-lamps-pq-composite-sigs.md b/draft-ietf-lamps-pq-composite-sigs.md index de2978a..259ecee 100644 --- a/draft-ietf-lamps-pq-composite-sigs.md +++ b/draft-ietf-lamps-pq-composite-sigs.md @@ -849,11 +849,13 @@ Deserialization Process: ## ML-DSA public key, private key and Signature sizes for serialization and deserialization -As noted above in the public key, private key and CompositeSignatureValue serialization and deserializations -methods, ML-DSA uses fixed-length values for all of these components. This means the length encoding of the -first component is known and NOT needed to be encoded into the serialization and deserialization process which -simplifies the encoding. If future composite combinations make use of algorithms where the first component uses -variable length keys or signatures, then that specification will need to ensure the length is encoded in a +As noted above in the public key, private key and CompositeSignatureValue +serialization and deserialization methods, ML-DSA uses fixed-length values for +all of these components. This means the length encoding of the first component is +known and does NOT need to be encoded into the serialization and deserialization process +which simplifies the encoding. If future composite combinations make use of +algorithms where the first component uses variable length keys or signatures, then +that specification will need to ensure the length is encoded in a fixed-length prefix so the components can be correctly deserialized. The following table shows the fixed length values in bytes for the public, private and signature From 6b1326bcd6a10b153de57d40929c6c375c7c69e6 Mon Sep 17 00:00:00 2001 From: John Gray <55205977+johngray-dev@users.noreply.github.com> Date: Wed, 27 Nov 2024 15:29:14 -0500 Subject: [PATCH 24/24] Fixed up a few more typos in signature serialization process --- draft-ietf-lamps-pq-composite-sigs.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-lamps-pq-composite-sigs.md b/draft-ietf-lamps-pq-composite-sigs.md index 259ecee..b29e276 100644 --- a/draft-ietf-lamps-pq-composite-sigs.md +++ b/draft-ietf-lamps-pq-composite-sigs.md @@ -787,7 +787,7 @@ Serialization Process: mldsaEncodedSignature = ML-DSA.SerializeSignature(mldsaSig) tradEncodedSignature = Trad.SerializeSignature(tradSig) - 3. Combine and output the encoded public key + 3. Combine and output the encoded composite signature bytes = mldsaEncodedSignature || tradEncodedSignature output bytes @@ -829,7 +829,7 @@ Deserialization Process: (mldsaEncodedSignature, tradEncodedSignature) = bytes - 3. Deserialize the constituent public or private keys + 3. Deserialize the constituent signature values mldsaSig = ML-DSA.DeserializeSignature(mldsaEncodedSignature) tradSig = Trad.DeserializeSignature(tradEncodedSignature) @@ -847,7 +847,7 @@ Deserialization Process: ~~~ {: #alg-composite-deserialize-sig title="Composite DeserializeSignatureValue(bytes)"} -## ML-DSA public key, private key and Signature sizes for serialization and deserialization +## ML-DSA public key, private key and signature sizes for serialization and deserialization As noted above in the public key, private key and CompositeSignatureValue serialization and deserialization methods, ML-DSA uses fixed-length values for @@ -861,7 +861,7 @@ fixed-length prefix so the components can be correctly deserialized. The following table shows the fixed length values in bytes for the public, private and signature sizes for ML-DSA which can be used to deserialzie the components. -| Algorithm | Public Key | Private Key | Signature | +| Algorithm | Public key | Private key | Signature | | ----------- | ----------- | ----------- | ----------- | | ML-DSA-44 | 1312 | 32 | 2420 | | ML-DSA-65 | 1952 | 32 | 3309 |