]> AWS

US jakemas@amazon.com

AWS

US kpanos@amazon.com

sn3rd

sean@sn3rd.com

Cloudflare

bas@cloudflare.com

SEC LAMPS WG ML-DSA Certificate X.509 PKIX Digital signatures are used within X.509 certificates, Certificate Revocation Lists (CRLs), and to sign messages. This document describes the conventions for using FIPS 204, 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. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Limited Additional Mechanisms for PKIX and SMIME (lamps) Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

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 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. defines two variants of ML-DSA: a pure and a prehash variant. Only the former is specified in this document. See for the rationale. The pure variant of ML-DSA supports the typical prehash flow, see . In short: one cryptographic module can compute the hash mu on line 6 of algorithm 7 of and pass it to a second module to finish the signature. The first module only needs access to the full message and the public key, whereas the second module only needs access to hash mu and the private key. Prior to standardisation, ML-DSA was known as Dilithium. ML-DSA and Dilithium are not compatible.

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.

Identifiers The AlgorithmIdentifier type is defined in as follows: The fields in AlgorithmIdentifier have the following meanings:

• algorithm identifies the cryptographic algorithm with an object identifier.
• parameters, which are optional, are the associated parameters for the algorithm identifier in the algorithm field.

The OIDs are: The contents of the parameters component for each algorithm MUST be absent. The ctx value used in the ML-DSA signing and verification of ML-DSA signatures defined in this specification (X.509 certificates, CRLs) is the empty string.

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 NIST PQC 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. 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. 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 . That is, the AlgorithmIdentifier SHALL be a SEQUENCE of one component, the OID id-ml-dsa-*. 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 .

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: The fields in SubjectPublicKeyInfo have the following meaning:

• algorithm is the algorithm identifier and parameters for the public key (see above).
• subjectPublicKey contains the byte stream of the public key.

The PUBLIC-KEY ASN.1 types for ML-DSA are defined here: Algorithm 22 in Section 7.2 of defines the raw byte string encoding of an ML-DSA public key. When used in a SubjectPublicKeyInfo type, the subjectPublicKey BIT STRING contains the raw byte string encoding of the public key. When an ML-DSA public key appears outside of a SubjectPublicKeyInfo type in an environment that uses ASN.1 encoding, it can be encoded as an OCTET STRING by using the ML-DSA-PublicKey type. describes the Asymmetric Key Package's OneAsymmetricKey type for encoding asymmetric keypairs. When an ML-DSA private key or keypair is encoded as a OneAsymmetricKey, it follows the description in . When the ML-DSA private key appears outside of an Asymmetric Key Package in an environment that uses ASN.1 encoding, it can be encoded as an OCTET STRING by using the ML-DSA-PrivateKey type. contains example ML-DSA public keys encoded using the textual encoding defined in .

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: If the keyUsage extension is present in a certificate that indicates id-ml-dsa-* in the SubjectPublicKeyInfo, then the following MUST NOT be present: Requirements about the keyUsage extension bits defined in still apply.

Private Key Format An ML-DSA private key is encoded by storing its 32-octet seed in the privateKey field as follows. specifies two formats for an ML-DSA private key: a 32-octet seed (xi) and an (expanded) private key. The expanded private key (and public key) is computed from the seed using ML-DSA.KeyGen_internal(xi) (algorithm 6). "Asymmetric Key Packages" describes how to encode a private key in a structure that both identifies what algorithm the private key is for and allows for the public key and additional attributes about the key to be included as well. For illustration, the ASN.1 structure OneAsymmetricKey is replicated below. When used in a OneAsymmetricKey type, the privateKey OCTET STRING contains the raw octet string encoding of the 32-octet seed. The publicKey field SHOULD be omitted because the public key can be computed as noted earlier in this section. contains example ML-DSA private keys encoded using the textual encoding defined in .

IANA Considerations For the ASN.1 module in , IANA is requested to assign an object identifier (OID) for the module identifier (TBD1) with a Description of "id-mod-x509-ml-dsa-2024". The OID for the module should be allocated in the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0).

Security Considerations The Security Considerations section of 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. ML-DSA offers both deterministic and randomized signing. By default ML-DSA signatures are non-deterministic. The private random seed (rho') for the signature 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. In the design of ML-DSA, care has been taken to make side-channel resilience easier to achieve. For instance, ML-DSA does not depend on Gaussian sampling. Implementations must still take great care not to leak information via various side channels. 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 . 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.

Rationale for disallowing HashML-DSA The HashML-DSA mode defined in Section 5.4 of MUST NOT be used; in other words, public keys identified by id-hash-ml-dsa-44-with-sha512, id-hash-ml-dsa-65-with-sha512, and id-hash-ml-dsa-87-with-sha512 MUST NOT be in X.509 certificates used for CRLs, OCSP, certificate issuance and related PKIX protocols (e.g. TLS). The use of HashML-DSA public keys within end entity certificates is not prohibited, but conventions for doing so are outside the scope of this document. This restriction is for both implementation and security reasons. The implementation reason for disallowing HashML-DSA stems from the fact that ML-DSA and HashML-DSA are incompatible algorithms that require different Verify() routines. This forwards to the protocol the complexity of informing the client whether to use ML-DSA.Verify() or HashML-DSA.Verify() along with the hash algorithm to use. Additionally, since the same OIDs are used to identify the ML-DSA public keys and ML-DSA signature algorithms, an implementation would need to commit a given public key to be either of type ML-DSA or HashML-DSA at the time of certificate creation. This is anticipated to cause operational issues in contexts where the operator does not know at key generation time whether the key will need to produce pure or pre-hashed signatures. ExternalMu-ML-DSA avoids all of these operational concerns by virtue of having keys and signatures that are indistinguishable from ML-DSA (i.e., ML-DSA and ExternalMu-ML-DSA are mathematically equivalent algorithms). The difference between ML-DSA and ExternalMu-ML-DSA is merely an internal implementation detail of the signer and has no impact on the verifier or network protocol. The security reason for disallowing HashML-DSA is that the design of the ML-DSA algorithm provides enhanced resistance against signature collision attacks, compared with conventional RSA or ECDSA signature algorithms. Specifically, ML-DSA binds the hash of the public key tr to the message to-be-signed prior to hashing, as described in line 6 of Algorithm 7 of . In practice, this provides binding to the indended verification public key, preventing some attacks that would otherwise allow a signature to be successfully verified against a non-intended public key. Also, this unlikely, theoretical binding means that in the unlikely discovery of a collision attack against SHA-3, an attacker would have to perform a public-key-specific collision search in order to find message pairs such that H(tr || m1) = H(tr || m2) since a direct hash collision H(m1) = H(m2) will not suffice. HashML-DSA removes both of these enhanced security properties.

References Normative References ITU-T ITU-T National Institute of Standards and Technology (NIST) In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document defines the syntax for private-key information and a content type for it. Private-key information includes a private key for a specified public-key algorithm and a set of attributes. The Cryptographic Message Syntax (CMS), as defined in RFC 5652, can be used to digitally sign, digest, authenticate, or encrypt the asymmetric key format content type. This document obsoletes RFC 5208. [STANDARDS-TRACK] This document presents a framework to assist the writers of certificate policies or certification practice statements for participants within public key infrastructures, such as certification authorities, policy authorities, and communities of interest that wish to rely on certificates. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy or a certification practice statement. This document supersedes RFC 2527. Informative References National Institute of Standards and Technology (NIST) This document describes and discusses the textual encodings of the Public-Key Infrastructure X.509 (PKIX), Public-Key Cryptography Standards (PKCS), and Cryptographic Message Syntax (CMS). The textual encodings are well-known, are implemented by several applications and libraries, and are widely deployed. This document articulates the de facto rules by which existing implementations operate and defines them so that future implementations can interoperate.

ASN.1 Module This appendix includes the ASN.1 module for the ML-DSA. Note that as per , certificates use the Distinguished Encoding Rules; see . This module imports objects from .

Security Strengths Instead of defining the strength of a quantum algorithm in a traditional manner using the imprecise notion of bits of security, NIST has instead elected to define security levels by picking a reference scheme, which NIST expects to offer notable levels of resistance to both quantum and classical attack. To wit, an algorithm that achieves NIST PQC security level 1 must require computational resources to break the relevant security property, which are greater than those required for a brute-force key search on AES-128. Levels 3 and 5 use AES-192 and AES-256 as reference respectively. Levels 2 and 4 use collision search for SHA-256 and SHA-384 as reference. 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. Note that these are the sizes of the plain private and public keys; and not the sizes of the resultant OneAsymmetricKey and SubjectPublicKeyInfo objects in which they are wrapped.

ML-DSA Parameters

Examples This appendix contains examples of ML-DSA public keys, private keys and certificates.

Example Private Key The following is an example of a ML-DSA-44 private key with hex seed 000102…1e1f: The following is an example of a ML-DSA-65 private key with hex seed 000102…1e1f: The following is an example of a ML-DSA-87 private key with hex seed 000102…1e1f: NOTE: The private key is the seed and all three examples keys use the same seed; therefore, the private above are the same except for the OID used to represent the ML-DSA algorithm's security strength.

Example Public Key The following is the ML-DSA-44 public key corresponding to the private key in the previous section. The following is the ML-DSA-65 public key corresponding to the private key in the previous section. The following is the ML-DSA-87 public key corresponding to the private key in the previous section.

Example Certificates The following is a self-signed certificate for the ML-DSA-44 public key in the previous section. The following is a self-signed certificate for the ML-DSA-65 public key in the previous section. The following is a self-signed certificate for the ML-DSA-87 public key in the previous section.

Pre-hashing (ExternalMu-ML-DSA) Some applications require pre-hashing, where the signature generation process can be separated into a pre-hash step and a core signature step in order to ease operational requirements around large or inconsistently-sized payloads. Pre-hashing can be performed at the protocol layer, but not all protocols support it. Examples in are certificates and CRLs; these do not include message digesting before signing. This can make signing large CRLs or a high volume of certificates with large public keys challenging. As mentioned in the introduction, pure ML-DSA signing itself supports a pre-hashing flow by splitting the operation over two modules. In this section, we make this "ExternalMu-ML-DSA" more explicit. There are two steps. First an ExternalMu-ML-DSA.Prehash() followed by ExternalMu-ML-DSA.Sign(). Together these are functionally equivalent to ML-DSA.Sign() from in that used in sequence they create exactly the same signatures as regular pure ML-DSA, which can be verified by the unmodified ML-DSA.Verify(). An ML-DSA key and certificate can be used with either ML-DSA or ExternalMu-ML-DSA interchangeably. Note that ExternalMu-ML-DSA describes a different signature API from ML-DSA and therefore might require explicit support from hardware or software cryptographic modules. Note that the signing mode defined here is different from HashML-DSA defined in Section 5.4 of . This specification uses exclusively ExternalMu-ML-DSA for pre-hashed use cases. See for additional discussion of why HashML-DSA is disallowed in PKIX. All functions and notation used in and are defined in . External operations:

External steps of ExternalMu-ML-DSA 255 then return error # return an error indication if the context string is # too long end if M' = BytesToBits(IntegerToBytes(0, 1) ∥ IntegerToBytes(|ctx|, 1) || ctx) || M mu = H(BytesToBits(H(pk, 64)) || M', 64) return mu ]]>

Internal operations:

Internal steps of ExternalMu-ML-DSA

ExternalMu-ML-DSA requires the public key, or its prehash, as input to the pre-digesting function. This assumes the signer generating the pre-hash is in possession of the public key before signing and is different from conventional pre-hashing which only requires the message and the hash function as input. Security-wise, during the signing operation of pure (or "one-step") ML-DSA, the cryptographic module extracts the public key hash tr from the secret key object, and thus there is no possibility of mismatch between tr and sk. In ExternalMu-ML-DSA, the public key or its hash needs to be provided to the Prehash() routine indpedendly of the secret key, and while the exact mechanism by which it is delivered will be implementation-specific, it does open a windown for mismatches between tr and sk. First, this will produce a signature which will fail to verify under the intended public key since a compliant Verify() routine will independently compute tr from the public key. Implementors should pay careful attention to how the public key or its hash is delivered to the ExternalMu-ML-DSA.Prehash() routine, and from where they are sourcing this data.

Acknowledgments We would like to thank ... for their insightful comments.