cabforum · slghtr-says · Aug 26, 2026
@@ -575,6 +575,8 @@ FIPS 140-3, Federal Information Processing Standards Publication - Security Requ
 
 FIPS 186-5, Federal Information Processing Standards Publication - Digital Signature Standard (DSS), Information Technology Laboratory, National Institute of Standards and Technology, February 2023.
 
+FIPS 204, Federal Information Processing Standards Publication - Module-Lattice-Based Digital Signature Standard, Information Technology Laboratory, National Institute of Standards and Technology, August 2024.
+
 ISO 21188:2018, Public key infrastructure for financial services -- Practices and policy framework.
 
 Network and Certificate System Security Requirements, Version 1.7, available at <https://cabforum.org/network-security-requirements/>
@@ -2088,6 +2090,13 @@ For ECDSA key pairs, the CA SHALL:
 
 - Ensure that the key represents a valid point on the NIST P-256, NIST P-384 or NIST P-521 elliptic curve.
 
+For ML-DSA key pairs, the CA SHALL:
+
+- Ensure that the key uses one of the following parameter sets, as specified in FIPS 204:
+  - ML-DSA-44 (OID: 2.16.840.1.101.3.4.3.17),
+  - ML-DSA-65 (OID: 2.16.840.1.101.3.4.3.18), or
+  - ML-DSA-87 (OID: 2.16.840.1.101.3.4.3.19).
+
 No other algorithms or key sizes are permitted.
 
 ### 6.1.6 Public key parameters generation and quality checking
@@ -2096,6 +2105,8 @@ RSA: The CA SHALL confirm that the value of the public exponent is an odd number
 
 ECDSA: The CA SHOULD confirm the validity of all keys using either the ECC Full Public Key Validation Routine or the ECC Partial Public Key Validation Routine. [Source: Sections 5.6.2.3.2 and 5.6.2.3.3, respectively, of NIST SP 800-56A: Revision 2]
 
+ML-DSA: The CA SHALL confirm that the public key is a valid encoding for the specified parameter set per FIPS 204.
+
 ### 6.1.7 Key usage purposes (as per X.509 v3 key usage field)
 
 Private Keys corresponding to Root Certificates MUST NOT be used to sign Certificates except in the following cases:
@@ -2894,7 +2905,7 @@ Table: Permitted `policyQualifiers`
 
 ##### 7.1.2.7.11 Subscriber Certificate Key Usage
 
-The acceptable Key Usage values vary based on whether the Certificate's `subjectPublicKeyInfo` identifies an RSA public key or an ECC public key. CAs MUST ensure the Key Usage is appropriate for the Certificate Public Key.
+The acceptable Key Usage values vary based on whether the Certificate's `subjectPublicKeyInfo` identifies an RSA public key, an ECC public key, or an ML-DSA public key. CAs MUST ensure the Key Usage is appropriate for the Certificate Public Key.
 
 Table: Key Usage for RSA Public Keys
 
@@ -2928,6 +2939,20 @@ Table: Key Usage for ECC Public Keys
 
 **Note**: The `keyAgreement` bit is currently permitted, although setting it is NOT RECOMMENDED, as it is a Pending Prohibition (<https://github.com/cabforum/servercert/issues/384>).
 
+Table: Key Usage for ML-DSA Public Keys
+
+| **Key Usage**      | **Permitted** | **Required**     |
+| -----              | --            | ---              |
+| `digitalSignature` | Y             | MUST             |
+| `nonRepudiation`   | N             | --               |
+| `keyEncipherment`  | N             | --               |
+| `dataEncipherment` | N             | --               |
+| `keyAgreement`     | N             | --               |
+| `keyCertSign`      | N             | --               |
+| `cRLSign`          | N             | --               |
+| `encipherOnly`     | N             | --               |
+| `decipherOnly`     | N             | --               |
+
 ##### 7.1.2.7.12 Subscriber Certificate Subject Alternative Name
 
 For Subscriber Certificates, the Subject Alternative Name MUST be present and MUST contain at least one `dNSName` or `iPAddress` `GeneralName`. See below for further requirements about the permitted fields and their validation requirements.
@@ -3406,6 +3431,22 @@ When encoded, the `AlgorithmIdentifier` for ECDSA keys MUST be byte-for-byte ide
 - For P-384 keys, `301006072a8648ce3d020106052b81040022`.
 - For P-521 keys, `301006072a8648ce3d020106052b81040023`.
 
+##### 7.1.3.1.3 ML-DSA
+
+The CA SHALL indicate an ML-DSA key using one of the following algorithm identifiers:
+
+- id-ml-dsa-44 (OID: 2.16.840.1.101.3.4.3.17),
+- id-ml-dsa-65 (OID: 2.16.840.1.101.3.4.3.18), or
+- id-ml-dsa-87 (OID: 2.16.840.1.101.3.4.3.19).
+
+The parameters for ML-DSA keys SHALL be absent. The CA MUST NOT use HashML-DSA, as specified in FIPS 204; only "pure" ML-DSA is permitted. Additionally, the CA SHALL NOT use these algorithm identifiers if the algorithm identifier of the Certificate's signature algorithm is not one of id-ml-dsa-44 (OID: 2.16.840.1.101.3.4.3.17), id-ml-dsa-65 (OID: 2.16.840.1.101.3.4.3.18), or id-ml-dsa-87 (OID: 2.16.840.1.101.3.4.3.19).
+
+When encoded, the `AlgorithmIdentifier` for ML-DSA keys MUST be byte-for-byte identical with the following hex-encoded bytes:
+
+- For id-ml-dsa-44, `300b0609608648016503040311`.
+- For id-ml-dsa-65, `300b0609608648016503040312`.
+- For id-ml-dsa-87, `300b0609608648016503040313`.
+
 #### 7.1.3.2 Signature AlgorithmIdentifier
 
 All objects signed by a CA Private Key MUST conform to these requirements on the use of the `AlgorithmIdentifier` or `AlgorithmIdentifier`-derived type in the context of signatures.
@@ -3514,6 +3555,18 @@ If the signing key is P-384, the signature MUST use ECDSA with SHA-384. When enc
 
 If the signing key is P-521, the signature MUST use ECDSA with SHA-512. When encoded, the `AlgorithmIdentifier` MUST be byte-for-byte identical with the following hex-encoded bytes: `300a06082a8648ce3d040304`.
 
+##### 7.1.3.2.3 ML-DSA
+
+The CA SHALL use the appropriate signature algorithm and encoding based upon the signing key used.
+
+If the signing key is ML-DSA-44, the signature algorithm MUST be id-ml-dsa-44 (OID: 2.16.840.1.101.3.4.3.17). When encoded, the `AlgorithmIdentifier` MUST be byte-for-byte identical with the following hex-encoded bytes: `300b0609608648016503040311`.
+
+If the signing key is ML-DSA-65, the signature algorithm MUST be id-ml-dsa-65 (OID: 2.16.840.1.101.3.4.3.18). When encoded, the `AlgorithmIdentifier` MUST be byte-for-byte identical with the following hex-encoded bytes: `300b0609608648016503040312`.
+
+If the signing key is ML-DSA-87, the signature algorithm MUST be id-ml-dsa-87 (OID: 2.16.840.1.101.3.4.3.19). When encoded, the `AlgorithmIdentifier` MUST be byte-for-byte identical with the following hex-encoded bytes: `300b0609608648016503040313`.
+
+If used within a Certificate or Precertificate, such as the `signatureAlgorithm` field of a Certificate or the `signature` field of a TBSCertificate, the CA SHALL NOT use these signature algorithms unless the algorithm identifier of the public key being certified is one of id-ml-dsa-44 (OID: 2.16.840.1.101.3.4.3.17), id-ml-dsa-65 (OID: 2.16.840.1.101.3.4.3.18), or id-ml-dsa-87 (OID: 2.16.840.1.101.3.4.3.19). This restriction does not apply if used within a CRL, such as the `signatureAlgorithm` field of a CertificateList, or within an OCSP response, such as the `signatureAlgorithm` of a BasicOCSPResponse, as these objects do not certify a public key.
+
 ### 7.1.4 Name Forms
 
 This section details encoding rules that apply to all Certificates issued by a CA. Further restrictions may be specified within [Section 7.1.2](#712-certificate-content-and-extensions), but these restrictions do not supersede these requirements.