Summary

  • RFC 9881 defines PKIX use of the pure ML-DSA variants ML-DSA-44, ML-DSA-65, and ML-DSA-87 in certificates and CRLs.
  • Their complete OIDs are 2.16.840.1.101.3.4.3.17 for ML-DSA-44, 2.16.840.1.101.3.4.3.18 for ML-DSA-65, and 2.16.840.1.101.3.4.3.19 for ML-DSA-87. The corresponding security categories are Level 2, Level 3, and Level 5, respectively.
  • The AlgorithmIdentifier parameters field MUST be absent, not encoded as NULL; signatures are raw ML-DSA values over the DER-encoded signed structure, with an empty context string.

The certificate profile is a byte-level contract. In a certificate or CRL, the selected OID appears in AlgorithmIdentifier, while the raw ML-DSA signature occupies signatureValue. A verifier must therefore hash and verify the DER encoding of the signed structure, not a reserialized approximation. RFC 9881 leaves the optional context empty for this PKIX use.

SubjectPublicKeyInfo carries the raw ML-DSA public-key byte string, without another ASN.1 wrapper. The public-key sizes are 1,312 octets for ML-DSA-44, 1,952 for ML-DSA-65, and 2,592 for ML-DSA-87. When keyUsage is present, at least one signature-related bit must be set; encryption and key-agreement bits MUST NOT be set for an ML-DSA key. Those are RFC requirements, not merely implementation preferences.

Private-key interchange is a separate failure surface. OneAsymmetricKey may contain a seed, an expanded key, or both. The seed-only form is recommended for storage efficiency. A parser must select the representation from its ASN.1 tag, never from apparent length. If both forms are present, a failed consistency check means the recipient MUST reject the key as malformed.

RFC 9881 selects pure ML-DSA. HashML-DSA OIDs MUST NOT be used in the covered PKIX protocols. This is also the boundary with pre-standardization Dilithium: ML-DSA and Dilithium are not compatible, so a familiar implementation label cannot justify accepting the other wire format.

Sources