| ML-DSA for Certificates | +plain text | +same as main | +
| Internet-Draft | +ML-DSA for Certificates | +July 2024 | +
| Massimo, et al. | +Expires 19 January 2025 | +[Page] | +
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.]¶
++ This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79.¶
++ Internet-Drafts are working documents of the Internet Engineering Task + Force (IETF). Note that other groups may also distribute working + documents as Internet-Drafts. The list of current Internet-Drafts is + at https://datatracker.ietf.org/drafts/current/.¶
++ Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress."¶
++ This Internet-Draft will expire on 19 January 2025.¶
++ Copyright (c) 2024 IETF Trust and the persons identified as the + document authors. All rights reserved.¶
++ This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with + respect to this document. Code Components extracted from this + document must include Revised BSD License text as described in + Section 4.e of the Trust Legal Provisions and are provided without + warranty as described in the Revised BSD License.¶
+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 [NIST-PQC] + in [DRAFTFIPS204]. 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 [RFC5280] for ML-DSA, like + [RFC3279] did for classic cryptography and + [RFC5480] did for elliptic curve cryptography. + The private key format is also specified.¶
+An ASN.1 module [X680] is included for reference purposes. Note that as per [RFC5280], + certificates use the Distinguished Encoding Rules; see [X690]. Also note that NIST + defined the object identifiers for the ML-DSA algorithms in an ASN.1 module; see + (TODO insert reference).¶
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14 [RFC2119] + [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
+The AlgorithmIdentifier type, which is included herein for convenience, is defined as follows:¶
+
+ AlgorithmIdentifier{ALGORITHM-TYPE, ALGORITHM-TYPE:AlgorithmSet} ::=
+ SEQUENCE {
+ algorithm ALGORITHM-TYPE."&"id({AlgorithmSet}),
+ parameters ALGORITHM-TYPE.
+ "&"Params({AlgorithmSet}{@algorithm}) OPTIONAL
+ }
+¶
+The fields in AlgorithmIdentifier have the following meanings:¶
+The OIDs are:¶
+
+ id-ML-DSA-44 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
+ country(16) us(840) organization(1) gov(101) csor(3)
+ nistAlgorithm(4) sigAlgs(3) TBD }
+¶
+
+ id-ML-DSA-65 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
+ country(16) us(840) organization(1) gov(101) csor(3)
+ nistAlgorithm(4) sigAlgs(3) TBD }
+¶
+
+ id-ML-DSA-87 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
+ 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.¶
+ML-DSA is a digital signature scheme built upon the Fiat-Shamir-with-aborts framework + [Fiat-Shamir]. The security is based upon + the hardness of lattice problems over module lattices [Dilithium]. + 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 [RFC5280] + 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 + [RFC5280] 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 {
+ tbsCertList TBSCertList,
+ signatureAlgorithm AlgorithmIdentifier,
+ signatureValue BIT STRING }
+¶
+The identifiers defined in Section 2 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, + [RFC5280]. The parameters of these signature algorithms MUST be absent, + as explained in Section 2.¶
+The signatureValue field contains the corresponding ML-DSA signature computed upon the ASN.1 DER encoded + tbsCertificate/tbsCertList [RFC5280].¶
+Conforming Certification Authority (CA) implementations MUST specify the algorithms explicitly + by using the OIDs specified in Section 2 + 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 Section 2.¶
+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.¶
+In the X.509 certificate, the subjectPublicKeyInfo field has the SubjectPublicKeyInfo type, which has the following + ASN.1 syntax:¶
+
+ SubjectPublicKeyInfo ::= SEQUENCE {
+ algorithm AlgorithmIdentifier,
+ subjectPublicKey BIT STRING
+ }
+¶
+The fields in SubjectPublicKeyInfo have the following meanings:¶
+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:¶
++ 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 Section 2 MUST be used as the algorithm field in the + SubjectPublicKeyInfo sequence [RFC5280] 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 + [RFC7468].¶
++-----BEGIN PUBLIC KEY----- +MIIHtDANBgsrBgEEAQKCCwcGBQOCB6EAFyP2dnbMELz5lkTFG7YvOdqVF5km835e +UHXNaynmIrWHeKMla2gHZTCAwgLWIr9RAh1K11KRvFf+HYMs3ykOrd4xQ2vgLsjP +jU0bup+rgRK5gvm3Z37rm2jAXDzJNxeM5lEDTklz9BQwOdQGm1rI/MXeMGssnOG4 +a9QvNPERdcG7VpTAEEevuTWmOeiKK3+kNCpoMRZr4WkgeInRyVUZXUvbYKkbm1Yj +2Mn2ZhgqFW4M1IJwq3LPDCAXZU9R0dTQCt9Ns04HQHNylARZya6TdW+F2k+pfZ3U +BRGbdI0MbVkOxqgRTfdWLlcXCfPn9/qdbz2K18QKdEuBBtPdZxiwTePDS6XvXjEp +KZg9bukd7Yxqhg+DPGQp+yQLW4H3lkOkq6mCNW2z86OVnja7xHYL8vAU8xDZ9IeL +oAIJm37X+qLOMIrT7qJE6zx2k+cJBnxBMSErEmOGOHb+dMvZyn8O77EyOSJS5pyn +70quzO8k+VieM8jc7ZJan3NUeC7F3Os45uAJzEa1ssKwMx+f4Dtz8GkSjjwCIdFA +fp6MNzek90lPKqJuxL37NGDB9scH6nLQOKpikaYkBYxD/huNtAe/e9MEHFlD1/Uz +bSWTN2qQ4UmdV7iJKtIvesDrzx7D6v5EUh9QGdt4D3dNI7NvdyOGrQXwMz8M1EOB +RX7QbAySLAkpGtpjcqkyiW0nOmslMtgI1JPM0bSzx1DuIaWjG/jf6HKpu2Ev2UlN +pYs8cMoFeHmJpzGUkGlFwE+nGysZOx708p98yDRrQyY/Fw6Qg1xzFle14CTqW86h +sD4K0scryDnETg3ZXpwhfQncYfxBbnIIyvxn2AnyGjy6h2r0b1SC8xzxWP7tGaSX +0H4sdGPvv1AIc6id4VhtrKZgau7JK24c4lqun3WgmZH3+/wyDeyf+Zrb8/DPK3N3 +ZI4R+xkZDzSkuFWLh5om8MykaFT6TNmc5Hc1kO039tgz0vqXpsQHir+EiFPbugEp +JLoxmoCgdxy9RLvDkSjnDwyI4Hg1djp9nRhpTVjvMdoIw6dSyO11ilEwppm+dNIn +Gxd6iO7yaE2tJ6UjIc+7tuKoZkzmsO6p4hN8VKhzXcVjnRr6xox4sD5u3esqtJly +9lsMU0qZnqJU4jbBS3SQloj3m8pl4cdf/j6ZHNiAAnfX6hhUGZDetTEv7MICeSW0 +b77XO5i4udTcYQtLvdo7mmyzG/N8NNR1T9pw89GYJ1maJhC2JyYx3Qwedppk0xac +BwWednYgQMMNEUKmAGoZxytTHtFfPhGQ4s7gZ6zw2CTiqAEGLfGj6lrwuBgXXAn+ +S8B7UwF4b4ReCpwdYO1N5AyWXAax5T67H5a/5VkiX8zT5lX6+/bAqT8waLIImE3Q +bEK74kOgQvULbzLzVjqJYPiAF8RwPIWRxH8ocOAM+NG0pREiEgDlO0xrcW26PeIo +pGEsxOfiZRq1CLIRFn2FyczJQ8xFwC7fWio3q91+RGr+hzgBE69HuT8C/Z/pBT/x +Im+D4lM1l++Xyn1RAoHyfnZy+nQK9i4hZ3eGyvpYfjfNGN5S+cBHY7/pKcr/EFaE +WgN97C4eTLD/SDxCoS9K25XEVFECHNfgY5NS3sfizlVrQqRIecoSLUhyqswlXYF8 +xgi58ZRh0oCGv6/4oyNROhwBi/aJYL0RRSYd5ZuARcs/aZ+QhdMOkprdzZSh4wDX +n3Vw1Rm1GAJEDVEojLoFtpWroe4YdsFHDmkJodZl3PHZIOuwHRr8YsqcHwuXM5nW +iGZRw+PoJP6gri+ev62U0jW5k7t7v35aF4ccBhwg4AVT2odFnj72hwD6df29LMIa +Zebj4iagOADfdVJhNUis9YseJwJtmlCJqUAB/6BQsCqeleD9LldTMutN/mq67DSe +z33nzBeLs0PnhtYiX2z3yjw4s+6/c4Q0o+fikm4t23A1Px8sDi72yplLRl67L6L8 +I4zXOW4eA9PFQFndAhDblmceVOoCmRuncXte56/8trdyGepF7+tm+79zKXeDkVkf +XmyHbcipFPHg00EUDgt2Wovq63obQXHP9f1KWon8YGOmW5MJbBNWiu83RZvwX7YW +6Z+STzC7aMzmQECmKEuiW1Zx6kcZnXFYDrlEiyit+lCiUyjqVbEJb3GJnOJM7Lmj +WEhutG6MSdJFuP/LHc0xxjxrQeG776skEujPcIt+kWqYXpdKTthWbfiuqCKbs+Qa +cGz3tRhyH2urDZC0LuZHF15AyQmSmRP4FcC9aMn6q4alx/+LUZwGvrjb4xJNAtqC +aapC8vTyNxKBJhawlkSewVoI3c7ra0WKYJ7YGaHct1VeH9u47a7pu/hYC1dAPWd8 +kajqEv2JJyWk0rrCi5OzrIfxE9Bl9C4nFWCPsd61qGLmi7u+1MrdN3k6dk6TG/y5 +Qkn9iw7wFyoaq6p6RFtFFPnAJJDiHEMp/ZFfY9Rxquvb4EK6FjAHAtKejzEMte4x +zXK4C4pBZTy+RTMvu7j0CGVlKRgSyj05LX2c22NY6YB1ZSoe9r8NFeRSOQ0ojHBf +afbiN3jcuOA/nB1MHq6ll/VpLR9NIAJyC4Xh+isdDK4JIXesSD9iNA5CIVXMUlE4 +x5AXF2HOm4o= +-----END PUBLIC KEY----- + +¶ +
Conforming CA implementations MUST specify the X.509 public key algorithm explicitly by using + the OIDs specified in Section 2 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.¶
+The intended application for the key is indicated in the keyUsage certificate extension; see + Section 4.2.1.3 of [RFC5280]. 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:¶
++ digitalSignature; or + nonRepudiation; or + keyCertSign; or + cRLSign. +¶ +
Requirements about the keyUsage extension bits defined in [RFC5280] still apply.¶
+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 {
+ version Version,
+ privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,
+ privateKey OCTET STRING,
+ publicKey [1] MLDSAPublicKey OPTIONAL
+ }
+¶
+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.¶
+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 [RFC5912].¶
+[ EDNOTE: Add ASN.1 here ]
+
+ PKIX1-PQ-Algorithms { iso(1) identified-organization(3) dod(6)
+ internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
+ id-mod-pkix1-PQ-algorithms(X) }
+
+ DEFINITIONS EXPLICIT TAGS ::=
+
+ BEGIN
+
+ -- EXPORTS ALL;
+
+ IMPORTS
+
+ -- FROM RFC 5912
+
+ PUBLIC-KEY, SIGNATURE-ALGORITHM, DIGEST-ALGORITHM, SMIME-CAPS
+ FROM AlgorithmInformation-2009
+ { iso(1) identified-organization(3) dod(6) internet(1)
+ security(5) mechanisms(5) pkix(7) id-mod(0)
+ id-mod-algorithmInformation-02(58) }
+
+ --
+ -- Public Key (pk-) Algorithms
+ --
+ PublicKeys PUBLIC-KEY ::= {
+ -- This expands PublicKeys from RFC 5912
+ pk-MLDSATBD |
+ pk-TBD-TBD,
+ ...
+ }
+
+ -- The hashAlgorithm is mda-shake256
+ -- The XOF seed rho is 32 bytes
+ -- The vector t1 is 320*k bytes
+ -- These are encoded as a single string
+
+ pk-MLDSA PUBLIC-KEY ::= {
+ IDENTIFIER id-MLDSA
+ -- KEY no ASN.1 wrapping --
+ PARAMS ARE absent
+ CERT-KEY-USAGE { nonRepudiation, digitalSignature,
+ keyCertSign, cRLSign }
+ --- PRIVATE-KEY no ASN.1 wrapping --
+ }
+
+ END
+¶
+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.¶
+The Security Considerations section of [RFC5280] applies to this specification as well.¶
+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 + + 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.¶
+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.¶
+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 + [CDFFJ21]. + + These properties are dependent, in part, on unambiguous public key serialization. It for this reason the public key + structure defined in Section 4 is intentionally encoded as a single + OCTET STRING.¶
+We would like to thank ... for their insightful comments.¶
+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.¶
++|=======+=======+=====+========+========+========| +| Level | (k,l) | eta | Sig. | Public | Private| +| | | | (B) | Key(B) | Key(B) | +|=======+=======+=====+========+========+========| +| 2 | (4,4) | 2 | 2420 | 1312 | 2528 | +| 3 | (6,5) | 4 | 3293 | 1952 | 4000 | +| 5 | (8,7) | 2 | 4595 | 2592 | 4864 | +|=======+=======+=====+========+========+========| ++
| ML-DSA for Certificates | +plain text | +same as main | +