From 639a4db141fee1c637f8f96323116a70235eb094 Mon Sep 17 00:00:00 2001 From: Sean Turner Date: Tue, 9 Jul 2024 07:50:54 -0400 Subject: [PATCH 1/7] Address John's comment, editorial, alignment with ML-KEM I-D Partially deals with #12; didn't incorporate the refs to PKCS#10, CMP, CMC, etc. Some alignment with ML-KEM I-D. Editorial suggestions; added a lot of newlines because in codeview it was much easier to read without always have to scroll right. --- draft-ietf-lamps-dilithium-certificates.xml | 281 +++++++++++++++----- 1 file changed, 218 insertions(+), 63 deletions(-) diff --git a/draft-ietf-lamps-dilithium-certificates.xml b/draft-ietf-lamps-dilithium-certificates.xml index ac7eb5f..703e7b7 100644 --- a/draft-ietf-lamps-dilithium-certificates.xml +++ b/draft-ietf-lamps-dilithium-certificates.xml @@ -31,7 +31,7 @@ - Internet X.509 Public Key Infrastructure: Algorithm Identifiers for ML-DSA + Internet X.509 Public Key Infrastructure: Algorithm Identifiers for ML-DSA @@ -96,29 +96,59 @@ output. If you submit your draft to the RFC Editor, the keywords will be used for the search engine. --> - Digital signatures are used within X.509 certificates, Certificate Revocation Lists (CRLs), and to sign messages. This document describes the conventions for using the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates and certificate revocation lists. The conventions for the associated signatures, subject public keys, and private key are also described. + Digital signatures are used within X.509 certificates, Certificate Revocation Lists (CRLs), + and to sign messages. This document describes the conventions for using the + Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates + and certificate revocation lists. The conventions for the associated signatures, subject + public keys, and private key are also described. - [EDNOTE: This draft is not expected to be finalized before the NIST PQC Project has standardized FIPS 204 Module-Lattice-Based Digital Signature Standard. The current FIPS draft was published August 24, 2023 for public review. Final versions are expected by April 2024. This specification will use object identifiers for the new algorithms that are assigned by NIST, and will use placeholders until these are released.] + [EDNOTE: This draft is not expected to be finalized before the NIST PQC Project has standardized + FIPS 204 Module-Lattice-Based Digital Signature Standard. The current FIPS draft was + published August 24, 2023 for public review. Final versions are expected by April 2024. This + specification will use object identifiers for the new algorithms that are assigned by NIST, + and will use placeholders until these are released.]
Introduction - The Module-Lattice-Based Digital Signature Algorithm (ML-DSA) is a quantum-resistant digital signature scheme standardized by the US National Institute of Standards and Technology (NIST) PQC project . This document specifies the use of the ML-DSA in Public Key Infrastructure X.509 (PKIX) certificates and Certificate Revocation Lists (CRLs) at three security levels: ML-DSA-44, ML-DSA-65, and ML-DSA-87, using object identifiers assigned by NIST. - This specification includes conventions for the signatureAlgorithm, signatureValue, signature, and subjectPublicKeyInfo fields within Internet X.509 certificates and CRLs , like did for classic cryptography and did for elliptic curve cryptography. It describes the encoding of digital signatures and public keys generated with quantum-resistant signature algorithm ML-DSA. + The Module-Lattice-Based Digital Signature Algorithm (ML-DSA) is a quantum-resistant + digital signature scheme standardized by the US National Institute of Standards + and Technology (NIST) PQC project + in . This document specifies + the use of the ML-DSA in Public Key Infrastructure X.509 (PKIX) certificates and + Certificate Revocation Lists (CRLs) at three security levels: ML-DSA-44, ML-DSA-65, + and ML-DSA-87. + This specification includes conventions for the signatureAlgorithm, signatureValue, + signature, and subjectPublicKeyInfo fields within Internet X.509 certificates and + CRLs for ML-DSA, like + did for classic cryptography and + did for elliptic curve cryptography. + The private key format is also specified. +
+ ASN.1 Moudule and ML-DSA Identifiers + An ASN.1 module is included for reference purposes. Note that as per , + certificates use the Distinguished Encoding Rules; see . Also note that NIST + defined the object identifiers for the ML-DSA algorithms in an ASN.1 module; see + (TODO insert reference). +
Requirements Language 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 - when, and only when, they appear in all capitals, as shown here. + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14 + when, and only when, they appear in all capitals, as shown here.
+
Identifiers - This specification uses placeholders for object identifiers until the identifiers for the new algorithms are assigned by NIST. - The AlgorithmIdentifier type, which is included herein for convenience, is defined as follows: + + The AlgorithmIdentifier type, which is included herein for convenience, is defined as follows: AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, @@ -126,7 +156,8 @@ } The fields in AlgorithmIdentifier have the following meanings:
    @@ -149,33 +180,56 @@ country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) sigAlgs(3) TBD } - The contents of the parameters component for each algorithm are absent. + The contents of the parameters component for each algorithm MUST be absent.
+
ML-DSA Signatures in PKIX - ML-DSA is a digital signature scheme built upon the Fiat-Shamir-with-aborts framework . The security is based upon the hardness of lattice problems over module lattices . ML-DSA provides three parameter sets for the security categories 2, 3 and 5. - Signatures are used in a number of different ASN.1 structures. As shown in the ASN.1 representation from below, in an X.509 certificate, a signature is encoded with an algorithm identifier in the signatureAlgorithm attribute and a signatureValue attribute that contains the actual signature. + ML-DSA is a digital signature scheme built upon the Fiat-Shamir-with-aborts framework + . The security is based upon + the hardness of lattice problems over module lattices . + ML-DSA provides three parameter sets for the security categories 2, 3 and 5. + Signatures are used in a number of different ASN.1 structures. As shown in the ASN.1 + representation from + below, in an X.509 certificate, a signature is encoded with an algorithm identifier + in the signatureAlgorithm attribute and a signatureValue attribute that contains the actual signature. Certificate ::= SEQUENCE { tbsCertificate TBSCertificate, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING } - Signatures are also used in the CRL list ASN.1 representation from below. In a X.509 CRL, a signature is encoded with an algorithm identifier in the signatureAlgorithm attribute and a signatureValue attribute that contains the actual signature. + Signatures are also used in the CRL list ASN.1 representation from + below. + In a X.509 CRL, a signature is encoded with an algorithm identifier in the signatureAlgorithm + attribute and a signatureValue attribute that contains the actual signature. CertificateList ::= SEQUENCE { - tbsCertificate TBSCertList, + tbsCertList TBSCertList, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING } - The identifiers defined in can be used as the AlgorithmIdentifier in the signatureAlgorithm field in the sequence Certificate/CertificateList and the signature field in the sequence TBSCertificate/TBSCertList in certificates CRLs, respectively, . The parameters of these signature algorithms are absent, as explained in . - The signatureValue field contains the corresponding ML-DSA signature computed upon the ASN.1 DER encoded tbsCertificate . - Conforming Certification Authority (CA) implementations MUST specify the algorithms explicitly by using the OIDs specified in when encoding ML-DSA signatures in certificates and CRLs. Conforming client implementations that process certificates and CRLs using ML-DSA MUST recognize the corresponding OIDs. Encoding rules for ML-DSA signature values are specified . - When the id-ML-DSA identifier appears in the algorithm field as an AlgorithmIdentifier, the encoding MUST omit the parameters field. That is, the AlgorithmIdentifier SHALL be a SEQUENCE of one component, the OID id-ML-DSA. + The identifiers defined in can be used as the AlgorithmIdentifier + in the signatureAlgorithm field in the sequence Certificate/CertificateList and the signature field + in the sequence TBSCertificate/TBSCertList in certificates and CRLs, respectively, + . The parameters of these signature algorithms MUST be absent, + as explained in . + The signatureValue field contains the corresponding ML-DSA signature computed upon the ASN.1 DER encoded + tbsCertificate/tbsCertList . + Conforming Certification Authority (CA) implementations MUST specify the algorithms explicitly + by using the OIDs specified in + when encoding ML-DSA signatures in certificates and CRLs. Conforming client implementations that process + certificates and CRLs using ML-DSA MUST recognize the corresponding OIDs. Encoding rules + for ML-DSA signature values are specified . + When the id-ML-DSA identifier appears in the algorithm field as an AlgorithmIdentifier, the encoding MUST + omit the parameters field. That is, the AlgorithmIdentifier SHALL be a SEQUENCE of one component, + the OID id-ML-DSA.
-
+ +
ML-DSA Public Keys in PKIX - In the X.509 certificate, the subjectPublicKeyInfo field has the SubjectPublicKeyInfo type, which has the following ASN.1 syntax: + In the X.509 certificate, the subjectPublicKeyInfo field has the SubjectPublicKeyInfo type, which has the following + ASN.1 syntax: SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, @@ -185,9 +239,12 @@ The fields in SubjectPublicKeyInfo have the following meanings:
  • algorithm is the algorithm identifier and parameters for the public key (see above).
    • -
  • subjectPublicKey contains the byte stream of the public key. The algorithms defined in this document always encode the public key as TODO.
    • +
  • subjectPublicKey contains the byte stream of the public key. The algorithms defined in this document always encode + the public key as TODO.
- The public parameters for ML-DSA are based upon a polynomial ring R_q for prime q. A (k*l) public matrix A is produced, consisting of polynomials whose coefficients are sampled uniformly at random from the integers modulo q. This sampling is performed by expanding a nonce (rho) using an XOF. + The public parameters for ML-DSA are based upon a polynomial ring R_q for prime q. A (k*l) public matrix A is produced, + consisting of polynomials whose coefficients are sampled uniformly at random from the integers modulo q. This + sampling is performed by expanding a nonce (rho) using an XOF. The ML-DSA public key MUST be encoded using the ASN.1 type MLDSAPublicKey: @@ -212,10 +269,18 @@ MLDSAPublicKey ::= OCTET STRING - where MLDSAPublicKey is a concatenation of rho and t1. Here, rho is the nonce used to seed the XOF to produce the matrix A, and t1 is a vector encoded in 320*k bytes where k is the rank of the vector over the polynomial ring R_q. These parameters MUST be encoded as a single OCTET STRING. The size required to hold a MLDSAPublicKey public key element is therefore 32+320*k bytes. - The id-ML-DSA identifier defined in MUST be used as the algorithm field in the SubjectPublicKeyInfo sequence to identify a ML-DSA public key. - The ML-DSA public key (a concatenation of rho and t1 that is an OCTET STRING) is mapped to a subjectPublicKey (a value of type BIT STRING) as follows: the most significant bit of the OCTET STRING value becomes the most significant bit of the BIT STRING value, and so on; the least significant bit of the OCTET STRING becomes the least significant bit of the BIT STRING. - The following is an example of a ML-DSA-44 public key encoded using the textual encoding defined in . + where MLDSAPublicKey is a concatenation of rho and t1. Here, rho is the nonce used to seed the XOF to produce the + matrix A, and t1 is a vector encoded in 320*k bytes where k is the rank of the vector over the polynomial ring + R_q. These parameters MUST be encoded as a single OCTET STRING. The size required to hold a + MLDSAPublicKey public key element is therefore 32+320*k bytes. + The id-ML-DSA identifier defined in MUST be used as the algorithm field in the + SubjectPublicKeyInfo sequence to identify a ML-DSA public key. + The ML-DSA public key (a concatenation of rho and t1 that is an OCTET STRING) is mapped to a subjectPublicKey (a value + of type BIT STRING) as follows: the most significant bit of the OCTET STRING value becomes the most significant + bit of the BIT STRING value, and so on; the least significant bit of the OCTET STRING becomes the least significant + bit of the BIT STRING. + The following is an example of a ML-DSA-44 public key encoded using the textual encoding defined in + . -----BEGIN PUBLIC KEY----- MIIHtDANBgsrBgEEAQKCCwcGBQOCB6EAFyP2dnbMELz5lkTFG7YvOdqVF5km835e @@ -263,24 +328,36 @@ x5AXF2HOm4o= -----END PUBLIC KEY----- - Conforming CA implementations MUST specify the X.509 public key algorithm explicitly by using the OIDs specified in when using ML-DSA public keys in certificates and CRLs. Conforming client implementations that process ML-DSA public keys when processing certificates and CRLs MUST recognize the corresponding OIDs. + Conforming CA implementations MUST specify the X.509 public key algorithm explicitly by using + the OIDs specified in when using ML-DSA public keys in certificates and CRLs. + Conforming client implementations that process ML-DSA public keys when processing certificates and CRLs + MUST recognize the corresponding OIDs.
-
+ +
Key Usage Bits - The intended application for the key is indicated in the keyUsage certificate extension; see . If the keyUsage extension is present in a certificate that indicates id-ML-DSA in the SubjectPublicKeyInfo, then the at least one of following MUST be present: + The intended application for the key is indicated in the keyUsage certificate extension; see + . If the keyUsage extension is present in a + certificate that indicates id-ML-DSA in the SubjectPublicKeyInfo, then the at least one of following + MUST be present: - Requirements about the keyUsage extension bits defined in still apply. -
+ Requirements about the keyUsage extension bits defined in still apply. +
ML-DSA Private Keys - EDNOTE: this section is still under construction as we discuss the best way to formulate the private key with the wider working group. - A ML-DSA private key is encoded as MLDSAPrivateKey in the privateKey field as an OCTET STRING. ML-DSA public keys are optionally distributed in the publicKey field of the MLDSAPrivateKey structure. This follows the OneAsymmetricKey syntax. + + A ML-DSA private key is encoded as MLDSAPrivateKey in the privateKey field as an OCTET STRING. ML-DSA public keys are + optionally distributed in the publicKey field of the MLDSAPrivateKey structure. This follows the OneAsymmetricKey + syntax. The ASN.1 encoding for a ML-DSA private key is as follows: MLDSAPrivateKey ::= SEQUENCE { @@ -305,9 +382,11 @@ x5AXF2HOm4o= - A fully populated ML-DSA private key consists of 6 parameters. The size necessary to hold all private key elements is 32+32+32+32*[(k+l)*ceiling(log(2*eta+1))+13*k] bytes. The description of k, l, and eta as well as public key and secret key sizes for security levels 2, 3, and 5 can be found in Figure 1 of the Appendix. + A fully populated ML-DSA private key consists of 6 parameters. The size necessary to hold all private key elements + is 32+32+32+32*[(k+l)*ceiling(log(2*eta+1))+13*k] bytes. The description of k, l, and eta as well as public + key and secret key sizes for security levels 2, 3, and 5 can be found in Figure 1 of the Appendix. -
+
@@ -316,9 +395,11 @@ x5AXF2HOm4o= TBD --> +
ASN.1 Module - This section includes the ASN.1 module for the ML-DSA signature algorithm. This module does not come from any previously existing RFC. This module references . + This section includes the ASN.1 module for the ML-DSA signature algorithm. This module does not come from any previously + existing RFC. This module references . [ EDNOTE: Add ASN.1 here ] PKIX1-PQ-Algorithms { iso(1) identified-organization(3) dod(6) @@ -368,35 +449,75 @@ x5AXF2HOm4o= END
+
IANA Considerations - Extensions in certificates and CRLs are identified using object Identifiers (OIDs). The creation and delegation of these arcs is to be determined. - IANA is requested to register the id-mod-pkix1-PQ-algorithms OID for the ASN.1 module identifier found in Section 5 in the "SMI Security for PKIX Module Identifier" registry. + Extensions in certificates and CRLs are identified using object Identifiers (OIDs). The creation and delegation of these + arcs is to be determined. + IANA is requested to register the id-mod-pkix1-PQ-algorithms OID for the ASN.1 module identifier found in Section 5 in + the "SMI Security for PKIX Module Identifier" registry.
+
Security Considerations The Security Considerations section of applies to this specification as well. - The digital signature scheme defined within this document are modeled under existentially unforgeable digital signatures with respect to an adaptive chosen message attack (EUF-CMA). For the purpose of estimating security strength, it has been assumed that the attacker has access to signatures for no more than 2^{64} chosen messages. + The digital signature scheme defined within this document are modeled under + strongly existentially unforgeable under chosen message attack (SUF-CMA). + For the purpose of estimating security strength, it has been assumed that the attacker has access to signatures + for no more than 2^{64} chosen messages. EDNOTE: Discuss implications of not hash-then-sign. Implications in performance too. - Within the hash-then-sign paradigm, hash functions are used as a domain restrictor over the message to be signed. By pre-hashing, the onus of resistance to existential forgeries becomes heavily reliant on the collision-resistance of the hash function in use. As well as this security goal, the hash-then-sign paradigm also has the ability to improve performance by reducing the size of signed messages. As a corollary, hashing remains mandatory even for short messages and assigns a further computational requirement onto the verifier. This makes the performance of hash-then-sign schemes more consistent, but not necessarily more efficient. ML-DSA diverges from the hash-then-sign paradigm by hashing the message + Within the hash-then-sign paradigm, hash functions are used as a domain restrictor over the message to be signed. By + pre-hashing, the onus of resistance to existential forgeries becomes heavily reliant on the collision-resistance + of the hash function in use. As well as this security goal, the hash-then-sign paradigm also has the ability to + improve performance by reducing the size of signed messages. As a corollary, hashing remains mandatory even for + short messages and assigns a further computational requirement onto the verifier. This makes the performance of + hash-then-sign schemes more consistent, but not necessarily more efficient. ML-DSA diverges from the hash-then-sign + paradigm by hashing the message - during the signing procedure (at the point in which the challenge polynomial). However, due to the fact that ML-DSA signatures may require the signing procedure to be repeated several times for a signature to be produced, ML-DSA implementations can make use of pre-hashing the message to prevent rehashing with each attempt. + during the signing procedure (at the point in which the challenge polynomial). However, due to the fact that ML-DSA + signatures may require the signing procedure to be repeated several times for a signature to be produced, ML-DSA + implementations can make use of pre-hashing the message to prevent rehashing with each attempt. EDNOTE: Discuss deterministic vs randomized signing and the impact on security. - ML-DSA offers both deterministic and randomized signing. By default ML-DSA signatures are non-deterministic, the private random seed rho' is pseudorandomly derived from the signer’s private key, the message, and a 256-bit string, rnd - where rnd should be generated by an approved RBG. In the deterministic version, rng is instead a 256-bit constant string. The source of randomness in the randomized mode has been "hedged" against sources of poor entropy, by including the signers private key and message into the derivation. The primary purpose of rnd is to facilitate countermeasures to side-channel attacks and fault attacks on deterministic signatures. + ML-DSA offers both deterministic and randomized signing. By default ML-DSA signatures are non-deterministic, the private + random seed rho' is pseudorandomly derived from the signer’s private key, the message, and a 256-bit string, + rnd - where rnd should be generated by an approved RBG. In the deterministic version, rng is instead a 256-bit + constant string. The source of randomness in the randomized mode has been "hedged" against sources of poor entropy, + by including the signers private key and message into the derivation. The primary purpose of rnd is to facilitate + countermeasures to side-channel attacks and fault attacks on deterministic signatures. EDNOTE: Discuss side-channels for ML-DSA. - ML-DSA has been designed to provide side-channel resilience by eliminating a reliance on Gaussian sampling. While deliberate design decisions such as these can help to deliver a greater ease of secure implementation - particularly against side-channel attacks - it does not necessarily provide resistance to more powerful attacks such as differential power analysis. Some amount of side-channel leakage has been demonstrated in parts of the signing algorithm (specifically the bit-unpacking function), from which a demonstration of key recovery has been made over a large sample of signatures. Masking countermeasures exist for ML-DSA, but come with a performance overhead. + ML-DSA has been designed to provide side-channel resilience by eliminating a reliance on Gaussian sampling. While + deliberate design decisions such as these can help to deliver a greater ease of secure implementation - particularly + against side-channel attacks - it does not necessarily provide resistance to more powerful attacks such as + differential power analysis. Some amount of side-channel leakage has been demonstrated in parts of the signing + algorithm (specifically the bit-unpacking function), from which a demonstration of key recovery has been made over + a large sample of signatures. Masking countermeasures exist for ML-DSA, but come with a performance + overhead. - A fundamental security property also associated with digital signatures is non-repudiation. Non-repudiation refers to the assurance that the owner of a signature key pair that was capable of generating an existing signature corresponding to certain data cannot convincingly deny having signed the data. The digital signature scheme ML-DSA possess three security properties beyond unforgeability, that are associated with non-repudiation. These are exclusive ownership, message-bound signatures, and non-resignability. These properties are based tightly on the assumed collision resistance of the hash function used (in this case SHAKE-256). + A fundamental security property also associated with digital signatures is non-repudiation. Non-repudiation refers to + the assurance that the owner of a signature key pair that was capable of generating an existing signature + corresponding to certain data cannot convincingly deny having signed the data. The digital signature scheme + ML-DSA possess three security properties beyond unforgeability, that are associated with non-repudiation. These + are exclusive ownership, message-bound signatures, and non-resignability. These properties are based tightly on + the assumed collision resistance of the hash function used (in this case SHAKE-256). - Exclusive ownership is a property in which a signature sigma uniquely determines the public key and message for which it is valid. Message-bound signatures is the property that a valid signature uniquely determines the message for which it is valid, but not necessarily the public key. Non-resignability is the property in which one cannot produce a valid signature under another key given a signature sigma for some unknown message m. These properties are not provided by classical signature schemes such as DSA or ECDSA, and have led to a variety of attacks such as Duplicate-Signature Key Selection (DSKS) attacks , and attacks on the protocols for secure routing. A full discussion of these properties in ML-DSA can be found at . + Exclusive ownership is a property in which a signature sigma uniquely determines the public key and message for which it + is valid. Message-bound signatures is the property that a valid signature uniquely determines the message for + which it is valid, but not necessarily the public key. Non-resignability is the property in which one cannot + produce a valid signature under another key given a signature sigma for some unknown message m. These properties + are not provided by classical signature schemes such as DSA or ECDSA, and have led to a variety of attacks such + as Duplicate-Signature Key Selection (DSKS) attacks , and attacks on the protocols for secure + routing. A full discussion of these properties in ML-DSA can be found at + . - These properties are dependent, in part, on unambiguous public key serialization. It for this reason the public key structure defined in is intentionally encoded as a single OCTET STRING. + These properties are dependent, in part, on unambiguous public key serialization. It for this reason the public key + structure defined in is intentionally encoded as a single + OCTET STRING.
@@ -424,6 +545,36 @@ x5AXF2HOm4o= + + + + DRAFT FIPS 204 (Initial Public Draft): Module-Lattice-Based Digital Signature Standard + + + + + + + National Institute of Standards and Technology + + + + Information Technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation. ITU-T Recommendation X.680 (2021) | ISO/IEC 8824-1:2021. + + ITU-T + + + + + + + Information technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER). ITU-T Recommendation X.690 (2021) | ISO/IEC 8825-1:2021. + + ITU-T + + + + Informative References @@ -461,18 +612,6 @@ x5AXF2HOm4o= International Conference on the Theory and Application of Cryptology and Information Security - - - FIPS 204 (Initial Public Draft): Module-Lattice-Based Digital Signature Standard - - - - - - - National Institute of Standards and Technology - - BUFFing signature schemes beyond unforgeability and the case of post-quantum signatures @@ -527,10 +666,21 @@ x5AXF2HOm4o= Acknowledgements We would like to thank ... for their insightful comments. +
Security Strengths - Instead of defining the strength of a quantum algorithm in a traditional manner using precise estimates of the number of bits of security, NIST has instead elected to define a collection of broad security strength categories. Each category is defined by a comparatively easy-to-analyze reference primitive that cover a range of security strengths offered by existing NIST standards in symmetric cryptography, which NIST expects to offer significant resistance to quantum cryptanalysis. These categories describe any attack that breaks the relevant security definition that must require computational resources comparable to or greater than those required for: Level 1 - key search on a block cipher with a 128-bit key (e.g., AES128), Level 2 - collision search on a 256-bit hash function (e.g., SHA256/ SHA3-256), Level 3 - key search on a block cipher with a 192-bit key (e.g., AES192), Level 4 - collision search on a 384-bit hash function (e.g. SHA384/ SHA3-384), Level 5 - key search on a block cipher with a 256-bit key (e.g., AES 256). - The parameter sets defined for NIST security levels 2, 3 and 5 are listed in the Figure 1, along with the resulting signature size, public key, and private key sizes in bytes. + Instead of defining the strength of a quantum algorithm in a traditional manner using precise estimates of the number + of bits of security, NIST has instead elected to define a collection of broad security strength categories. Each + category is defined by a comparatively easy-to-analyze reference primitive that cover a range of security strengths + offered by existing NIST standards in symmetric cryptography, which NIST expects to offer significant resistance + to quantum cryptanalysis. These categories describe any attack that breaks the relevant security definition that + must require computational resources comparable to or greater than those required for: Level 1 - key search on a + block cipher with a 128-bit key (e.g., AES128), Level 2 - collision search on a 256-bit hash function (e.g., + SHA256/ SHA3-256), Level 3 - key search on a block cipher with a 192-bit key (e.g., AES192), Level 4 - collision + search on a 384-bit hash function (e.g. SHA384/ SHA3-384), Level 5 - key search on a block cipher with a 256-bit + key (e.g., AES 256). + The parameter sets defined for NIST security levels 2, 3 and 5 are listed in the Figure 1, along with the resulting + signature size, public key, and private key sizes in bytes. -
+
From 1f0913238c198d6daeed8af62327c566bc66eb8f Mon Sep 17 00:00:00 2001 From: Sean Turner Date: Tue, 9 Jul 2024 08:04:03 -0400 Subject: [PATCH 2/7] fix tagging issue --- draft-ietf-lamps-dilithium-certificates.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-lamps-dilithium-certificates.xml b/draft-ietf-lamps-dilithium-certificates.xml index 703e7b7..7a4f05a 100644 --- a/draft-ietf-lamps-dilithium-certificates.xml +++ b/draft-ietf-lamps-dilithium-certificates.xml @@ -180,7 +180,7 @@ country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) sigAlgs(3) TBD } - The contents of the parameters component for each algorithm MUST be absent. + The contents of the parameters component for each algorithm MUST be absent.
From 96f021d4f31fd58338b4279d3db66c28480afaf3 Mon Sep 17 00:00:00 2001 From: Sean Turner Date: Tue, 9 Jul 2024 08:05:17 -0400 Subject: [PATCH 3/7] fix tagging issue #2 --- draft-ietf-lamps-dilithium-certificates.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-lamps-dilithium-certificates.xml b/draft-ietf-lamps-dilithium-certificates.xml index 7a4f05a..499a9ab 100644 --- a/draft-ietf-lamps-dilithium-certificates.xml +++ b/draft-ietf-lamps-dilithium-certificates.xml @@ -212,7 +212,7 @@ The identifiers defined in can be used as the AlgorithmIdentifier in the signatureAlgorithm field in the sequence Certificate/CertificateList and the signature field in the sequence TBSCertificate/TBSCertList in certificates and CRLs, respectively, - . The parameters of these signature algorithms MUST be absent, + . The parameters of these signature algorithms MUST be absent, as explained in . The signatureValue field contains the corresponding ML-DSA signature computed upon the ASN.1 DER encoded tbsCertificate/tbsCertList . From 79ceea7a762b8f9d26fd2b4bede8e0eff03cf17e Mon Sep 17 00:00:00 2001 From: Sean Turner Date: Tue, 9 Jul 2024 08:08:19 -0400 Subject: [PATCH 4/7] fixing target --- draft-ietf-lamps-dilithium-certificates.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-lamps-dilithium-certificates.xml b/draft-ietf-lamps-dilithium-certificates.xml index 499a9ab..b2650de 100644 --- a/draft-ietf-lamps-dilithium-certificates.xml +++ b/draft-ietf-lamps-dilithium-certificates.xml @@ -516,7 +516,7 @@ x5AXF2HOm4o= . These properties are dependent, in part, on unambiguous public key serialization. It for this reason the public key - structure defined in is intentionally encoded as a single + structure defined in is intentionally encoded as a single OCTET STRING.
From f9211b288d2879231731295448b571137898ce50 Mon Sep 17 00:00:00 2001 From: Sean Turner Date: Tue, 9 Jul 2024 08:11:47 -0400 Subject: [PATCH 5/7] fixing tagging issue #3 --- draft-ietf-lamps-dilithium-certificates.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-lamps-dilithium-certificates.xml b/draft-ietf-lamps-dilithium-certificates.xml index b2650de..fa3220b 100644 --- a/draft-ietf-lamps-dilithium-certificates.xml +++ b/draft-ietf-lamps-dilithium-certificates.xml @@ -504,7 +504,7 @@ x5AXF2HOm4o= corresponding to certain data cannot convincingly deny having signed the data. The digital signature scheme ML-DSA possess three security properties beyond unforgeability, that are associated with non-repudiation. These are exclusive ownership, message-bound signatures, and non-resignability. These properties are based tightly on - the assumed collision resistance of the hash function used (in this case SHAKE-256). + the assumed collision resistance of the hash function used (in this case SHAKE-256). Exclusive ownership is a property in which a signature sigma uniquely determines the public key and message for which it is valid. Message-bound signatures is the property that a valid signature uniquely determines the message for From 07122b9d16e1c37ed3306ef58294944636341cdc Mon Sep 17 00:00:00 2001 From: Sean Turner Date: Tue, 9 Jul 2024 08:22:21 -0400 Subject: [PATCH 6/7] fixing mlsdsapublickey->mldsapublickey Freudian slip --- draft-ietf-lamps-dilithium-certificates.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-lamps-dilithium-certificates.xml b/draft-ietf-lamps-dilithium-certificates.xml index fa3220b..b4991f5 100644 --- a/draft-ietf-lamps-dilithium-certificates.xml +++ b/draft-ietf-lamps-dilithium-certificates.xml @@ -226,7 +226,7 @@ the OID id-ML-DSA. -
+
ML-DSA Public Keys in PKIX In the X.509 certificate, the subjectPublicKeyInfo field has the SubjectPublicKeyInfo type, which has the following ASN.1 syntax: From c4eda20d91263b99345966932062b8c84be204ed Mon Sep 17 00:00:00 2001 From: Sean Turner Date: Tue, 9 Jul 2024 08:24:16 -0400 Subject: [PATCH 7/7] fixing ref anchor --- draft-ietf-lamps-dilithium-certificates.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-lamps-dilithium-certificates.xml b/draft-ietf-lamps-dilithium-certificates.xml index b4991f5..30479bb 100644 --- a/draft-ietf-lamps-dilithium-certificates.xml +++ b/draft-ietf-lamps-dilithium-certificates.xml @@ -546,7 +546,7 @@ x5AXF2HOm4o= - + DRAFT FIPS 204 (Initial Public Draft): Module-Lattice-Based Digital Signature Standard