Internet X.509 Public Key Infrastructure -- Algorithm Identifiers for the Module-Lattice-Based Digital Signature Algorithm (ML-DSA)
RFC 9881
Jake Massimo
AWS
Panos Kampanakis
AWS
Sean Turner
sn3rd
Bas Westerbaan
Cloudflare
2025-10
SEC
lamps
ML-DSA
Certificate
X.509
PKIX
Digital signatures are used within X.509 certificates and Certificate Revocation Lists (CRLs), and to sign messages. This document specifies the conventions for using FIPS 204, the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates and CRLs. The conventions for the associated signatures, subject public keys, and private key are also described.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9881.
Copyright Notice
Copyright (c) 2025 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.
Table of Contents
- 1. Introduction
  - 1.1. Requirements Language
- 2. Identifiers
- 3. ML-DSA Signatures in PKIX
- 4. ML-DSA Public Keys in PKIX
- 5. Key Usage Bits
- 6. Private Key Format
- 7. IANA Considerations
- 8. Operational Considerations
  - 8.1. Private Key Format
  - 8.2. Private Key Consistency Testing
  - 8.3. Rationale for Disallowing HashML-DSA
- 9. Security Considerations
- 10. References
  - 10.1. Normative References
  - 10.2. Informative References
- Appendix A. ASN.1 Module
- Appendix B. Security Strengths
- Appendix C. Examples
  - C.1. Example Private Keys
    - C.1.1. ML-DSA-44 Private Key Examples
    - C.1.2. ML-DSA-65 Private Key Examples
    - C.1.3. ML-DSA-87 Private Key Examples
  - C.2. Example Public Keys
  - C.3. Example Certificates
  - C.4. Example Inconsistent Seed and Expanded Private Keys
- Appendix D. Pre-Hashing (Externalμ-ML-DSA)
- Acknowledgments
- Authors' Addresses
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 [NIST-PQC] in [FIPS204]. 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.
[FIPS204] defines two variants of ML-DSA: pure and pre-hash. Only the former is specified in this document. See Section 8.3 for the rationale. The pure variant of ML-DSA supports the typical pre-hash flow. Refer to Appendix D for more details.
Prior to standardization, 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Identifiers
The AlgorithmIdentifier type is defined in [RFC5912] as follows:

AlgorithmIdentifier{ALGORITHM-TYPE, ALGORITHM-TYPE:AlgorithmSet} ::=
        SEQUENCE {
            algorithm   ALGORITHM-TYPE.&id({AlgorithmSet}),
            parameters  ALGORITHM-TYPE.
                   &Params({AlgorithmSet}{@algorithm}) OPTIONAL
        }
NOTE: The above syntax is from [RFC5912] and is compatible with the 2021 ASN.1 syntax [X680]. See [RFC5280] for the 1988 ASN.1 syntax.
The fields in AlgorithmIdentifier have the following meanings:
- algorithm identifies the cryptographic algorithm with an object identifier (OID).
- parameters, which are optional, are the associated parameters for the algorithm identifier in the algorithm field.
The NIST-registered OIDs [CSOR] 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) id-ml-dsa-44(17) }

   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) id-ml-dsa-65(18) }

   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) id-ml-dsa-87(19) }
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 [Fiat-Shamir]. The security is based upon the hardness of lattice problems over module lattices [Dilithium]. 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 equivalent to that in [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  ::=  SIGNED{ TBSCertificate }

  SIGNED{ToBeSigned} ::= SEQUENCE {
     toBeSigned           ToBeSigned,
     algorithmIdentifier  SEQUENCE {
         algorithm        SIGNATURE-ALGORITHM.
                            &id({SignatureAlgorithms}),
         parameters       SIGNATURE-ALGORITHM.
                            &Params({SignatureAlgorithms}
                              {@algorithmIdentifier.algorithm})
                                OPTIONAL
     },
     signature BIT STRING (CONTAINING SIGNATURE-ALGORITHM.&Value(
                              {SignatureAlgorithms}
                              {@algorithmIdentifier.algorithm}))
  }
Signatures are also used in the CRL list ASN.1; the representation below is equivalent to that in [RFC5280]. In an 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  ::=  SIGNED{ TBSCertList }
The following SIGNATURE-ALGORITHM ASN.1 classes are for ML-DSA-44, ML-DSA-65, and ML-DSA-87:

  sa-ml-dsa-44 SIGNATURE-ALGORITHM ::= {
    IDENTIFIER id-ml-dsa-44
    PARAMS ARE absent
    PUBLIC-KEYS { pk-ml-dsa-44 }
    SMIME-CAPS { IDENTIFIED BY id-ml-dsa-44 }
    }

  sa-ml-dsa-65 SIGNATURE-ALGORITHM ::= {
    IDENTIFIER id-ml-dsa-65
    PARAMS ARE absent
    PUBLIC-KEYS { pk-ml-dsa-65 }
    SMIME-CAPS { IDENTIFIED BY id-ml-dsa-65 }
    }

  sa-ml-dsa-87 SIGNATURE-ALGORITHM ::= {
    IDENTIFIER id-ml-dsa-87
    PARAMS ARE absent
    PUBLIC-KEYS { pk-ml-dsa-87 }
    SMIME-CAPS { IDENTIFIED BY id-ml-dsa-87 }
    }
NOTE: The above syntax is from [RFC5912] and is compatible with the 2021 ASN.1 syntax [X680].
The identifiers defined in Section 2 can be used as the AlgorithmIdentifier in the signatureAlgorithm field in the sequence Certificate/CertificateList and in 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. That is, the AlgorithmIdentifier SHALL be a SEQUENCE of one component, the OID id-ml-dsa-*, where * is 44, 65, or 87 -- see Section 2.
The signatureValue field contains the corresponding ML-DSA signature computed upon the ASN.1 DER-encoded TBSCertificate/TBSCertList [RFC5280]. The optional context string (ctx) parameter as defined in Section 5.2 of [FIPS204] is left to its default value: the empty string.
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 in Section 2.
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:

  SubjectPublicKeyInfo {PUBLIC-KEY: IOSet} ::= SEQUENCE {
      algorithm        AlgorithmIdentifier {PUBLIC-KEY, {IOSet}},
      subjectPublicKey BIT STRING
  }
NOTE: The above syntax is from [RFC5912] and is compatible with the 2021 ASN.1 syntax [X680]. See [RFC5280] for the 1988 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 public key.
Algorithm 22 in Section 7.2 of [FIPS204] defines the raw byte string encoding of an ML-DSA public key. When used in a SubjectPublicKeyInfo type, the subjectPublicKey BIT STRING contains this 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 could be encoded as an OCTET STRING by using the ML-DSA-44-PublicKey, ML-DSA-65-PublicKey, and ML-DSA-87-PublicKey types corresponding to the correct key size defined below.
The PUBLIC-KEY ASN.1 types for ML-DSA are defined here:

  pk-ml-dsa-44 PUBLIC-KEY ::= {
    IDENTIFIER id-ml-dsa-44
    -- KEY no ASN.1 wrapping --
    CERT-KEY-USAGE
      { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
    PRIVATE-KEY ML-DSA-44-PrivateKey }  -- defined in Section 6

  pk-ml-dsa-65 PUBLIC-KEY ::= {
    IDENTIFIER id-ml-dsa-65
    -- KEY no ASN.1 wrapping --
    CERT-KEY-USAGE
      { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
    PRIVATE-KEY ML-DSA-65-PrivateKey }  -- defined in Section 6

  pk-ml-dsa-87 PUBLIC-KEY ::= {
    IDENTIFIER id-ml-dsa-87
    -- KEY no ASN.1 wrapping --
    CERT-KEY-USAGE
      { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
    PRIVATE-KEY ML-DSA-87-PrivateKey }  -- defined in Section 6

  ML-DSA-44-PublicKey ::= OCTET STRING (SIZE (1312))

  ML-DSA-65-PublicKey ::= OCTET STRING (SIZE (1952))

  ML-DSA-87-PublicKey ::= OCTET STRING (SIZE (2592))
NOTE: The above syntax is from [RFC5912] and is compatible with the 2021 ASN.1 syntax [X680].
[RFC5958] specifies 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 Section 6.
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 using one of the ML-DSA-PrivateKey CHOICE formats defined in Section 6. The seed format is RECOMMENDED as it efficiently stores both the private and public key.
Appendix C contains example ML-DSA public keys encoded using the textual encoding defined in [RFC7468].
Key Usage Bits
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 includes id-ml-dsa-* (where * is 44, 65, or 87 -- see Section 2) in the SubjectPublicKeyInfo, then the subject public key can only be used for verifying digital signatures on certificates or CRLs, or those used in an entity authentication service, a data origin authentication service, an integrity service, and/or a non-repudiation service that protects against the signing entity falsely denying some action. This means that the keyUsage extension MUST have at least one of the following bits set:
- digitalSignature
- nonRepudiation
- keyCertSign
- cRLSign
ML-DSA subject public keys cannot be used to establish keys or encrypt data, so the keyUsage extension MUST NOT have any of the following bits set:
- keyEncipherment
- dataEncipherment
- keyAgreement
- encipherOnly
- decipherOnly
Requirements about the keyUsage extension bits defined in [RFC5280] still apply.
Private Key Format
[FIPS204] specifies two formats for an ML-DSA private key: a 32-octet seed (ξ) (GREEK SMALL LETTER XI, U+03BE) and an (expanded) private key. The expanded private key (and public key) is computed from the seed using ML-DSA.KeyGen_internal(ξ) (algorithm 6).
"Asymmetric Key Packages" [RFC5958] specifies 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.

  OneAsymmetricKey ::= SEQUENCE {
    version                  Version,
    privateKeyAlgorithm      SEQUENCE {
    algorithm                PUBLIC-KEY.&id({PublicKeySet}),
    parameters               PUBLIC-KEY.&Params({PublicKeySet}
                               {@privateKeyAlgorithm.algorithm})
                                  OPTIONAL}
    privateKey               OCTET STRING (CONTAINING
                               PUBLIC-KEY.&PrivateKey({PublicKeySet}
                                 {@privateKeyAlgorithm.algorithm})),
    attributes           [0] Attributes OPTIONAL,
    ...,
    [[2: publicKey       [1] BIT STRING (CONTAINING
                               PUBLIC-KEY.&Params({PublicKeySet}
                                 {@privateKeyAlgorithm.algorithm})
                                 OPTIONAL ]],
    ...
  }
NOTE: The above syntax is from [RFC5958] and is compatible with the 2021 ASN.1 syntax [X680].
For ML-DSA private keys, the privateKey field in OneAsymmetricKey contains one of the following DER-encoded CHOICE structures. The seed format is a fixed 32-byte OCTET STRING (34 bytes total with the 0x8020 tag and length) for all security levels, while the expandedKey and both formats vary in size by security level:

ML-DSA-44-PrivateKey ::= CHOICE {
  seed [0] OCTET STRING (SIZE (32)),
  expandedKey OCTET STRING (SIZE (2560)),
  both SEQUENCE {
      seed OCTET STRING (SIZE (32)),
      expandedKey OCTET STRING (SIZE (2560))
      }
  }

ML-DSA-65-PrivateKey ::= CHOICE {
  seed [0] OCTET STRING (SIZE (32)),
  expandedKey OCTET STRING (SIZE (4032)),
  both SEQUENCE {
      seed OCTET STRING (SIZE (32)),
      expandedKey OCTET STRING (SIZE (4032))
      }
  }

ML-DSA-87-PrivateKey ::= CHOICE {
  seed [0] OCTET STRING (SIZE (32)),
  expandedKey OCTET STRING (SIZE (4896)),
  both SEQUENCE {
      seed OCTET STRING (SIZE (32)),
      expandedKey OCTET STRING (SIZE (4896))
      }
  }
NOTE: The above syntax is from [RFC5912] and is compatible with the 2021 ASN.1 syntax [X680].
The CHOICE allows three representations of the private key:
1. The seed format (tag [0]) contains just the 32-byte seed value (ξ) from which both the expanded private key and public key can be derived using ML-DSA.KeyGen_internal(ξ).
2. The expandedKey format contains the expanded private key that was derived from the seed.
3. The both format contains both the seed and expanded private key, allowing for interoperability; some may want to use and retain the seed and others may only support expanded private keys.
When encoding an ML-DSA private key in a OneAsymmetricKey object, any of these three formats may be used, though the seed format is RECOMMENDED for storage efficiency.
The privateKeyAlgorithm field uses the AlgorithmIdentifier structure with the appropriate OID as defined in Section 2. If present, the publicKey field will hold the encoded public key as defined in Section 4.
NOTE: While the private key can be stored in multiple formats, the seed-only format is RECOMMENDED as it is the most compact representation. Both the expanded private key and the public key can be deterministically derived from the seed using ML-DSA.KeyGen_internal(ξ). Alternatively, the public key can be generated from the private key. While the publicKey field and expandedKey format are technically redundant when using the seed-only format, they MAY be included to enable keypair consistency checks during import operations.
When parsing the private key, the ASN.1 tag explicitly indicates which variant of CHOICE is present. Implementations should use the context-specific tag IMPLICIT [0] (raw value 0x80) for seed, OCTET STRING (0x04) for expandedKey, and SEQUENCE (0x30) for both to parse the private key, rather than any other heuristic like length of the enclosing OCTET STRING.
Appendix C contains example ML-DSA private keys encoded using the textual encoding defined in [RFC7468].
IANA Considerations
For the ASN.1 module in Appendix A, IANA has assigned the following object identifier (OID) in the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0):
Registered ASN.1 Module
Decimal | Description | Reference
119 | id-mod-x509-ml-dsa-2025 | RFC 9881
Operational Considerations
Private Key Format
An ML-DSA.KeyGen seed (ξ) represents the RECOMMENDED format for storing and transmitting ML-DSA private keys. This format is explicitly permitted by [FIPS204] as an acceptable representation of a keypair. In particular, generating the seed in one cryptographic module and then importing or exporting it into another cryptographic module is allowed. The internal key-generation function ML-DSA.KeyGen_internal(ξ) can be accessed for this purpose.
Note also that unlike other private key compression methods in other algorithms, expanding a private key from a seed is a one-way function, meaning that once a full key is expanded from seed and the seed discarded, the seed cannot be recreated, even if the full expanded private key is available. For this reason, it is RECOMMENDED that implementations retain and export the seed, even when also exporting the expanded private key. ML-DSA seed extraction can be implemented by including the seed ξ that is randomly generated at line 1 of Algorithm 1 ML-DSA.KeyGen in the returned output.
When encoding an ML-DSA private key in a OneAsymmetricKey object, any of these three formats may be used, though the seed format is RECOMMENDED for storage efficiency.
Private Key Consistency Testing
When receiving a private key that contains both the seed and the expandedKey, the recipient SHOULD perform a seed consistency check to ensure that the sender properly generated the private key. Recipients that do not perform this seed consistency check avoid keygen and compare operations, but are unable to ensure that the seed and expandedKey match.
If the check is done and the seed and the expandedKey are not consistent, the recipient MUST reject the private key as malformed.
The seed consistency check consists of regenerating the expanded form from the seed via ML-DSA.KeyGen_internal, and ensuring it is bytewise equal to the value presented in the private key.
Appendix C.4 includes some examples of inconsistent seeds and expanded private keys.
Rationale for Disallowing HashML-DSA
The HashML-DSA mode defined in Section 5.4 of [FIPS204] 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. This restriction is primarily to increase interoperability.
ML-DSA and HashML-DSA are incompatible algorithms that require different Verify() routines. This introduces the complexity of informing the verifier whether to use ML-DSA.Verify() or HashML-DSA.Verify(). 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 whether the key will need to produce pure or pre-hashed signatures at key-generation time. The External μ mode described in Appendix D avoids all of these operational concerns.
A minor security reason for disallowing HashML-DSA is that the design of the ML-DSA algorithm provides enhanced resistance against collision attacks, compared with HashML-DSA or conventional RSA or ECDSA signature algorithms. Specifically, ML-DSA prepends the SHAKE256 hash of the public key (tr) to the message to-be-signed prior to hashing, as described in line 6 of Algorithm 7 of [FIPS204]. This means that in the unlikely discovery of a collision attack against the SHA-3 family, 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), because a direct hash collision H(m1) = H(m2) will not suffice. HashML-DSA removes this enhanced security property. In spite of its lack of targeted collision protection, the practical security risk of using HashML-DSA in X.509 signatures would be immaterial. This is because a hash of the issuing CA's public key is already included in the Authority Key Identifier (AKI) extension, which is signed as part of the TBSCertificate structure. Even when it is a SHA-1 hash, general second pre-images against the AKI hash of existing issuing CAs would be impractical.
Security Considerations
The Security Considerations section of [RFC5280] applies to this specification as well.
The ML-DSA signature scheme is strongly unforgeable under chosen message attacks (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 depends on high quality random numbers that are suitable for use in cryptography. The use of inadequate pseudo-random number generators (PRNGs) to generate such values can significantly undermine various security properties. For instance, using an inadequate PRNG for key generation might allow an attacker to efficiently recover the private key by trying a small set of possibilities, rather than brute-force searching the whole keyspace. The generation of random numbers of a sufficient level of quality for use in cryptography is difficult; see Section 3.6.1 of [FIPS204] for some additional information.
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 secure implementation with greater ease -- 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 comes with performance overhead.
ML-DSA offers both deterministic and randomized signing. Signatures generated with either mode are compatible and a verifier cannot tell them apart. In the deterministic case, a signature only depends on the private key and the message to be signed. This makes the implementation easier to test and does not require a randomness source during signing. In the randomized case, signing mixes in a 256-bit random string from an approved random bit generator (RBG). When randomized, ML-DSA is easier to harden against fault and hardware side-channel attacks.
A security property that is also associated with digital signatures is non-repudiation. Non-repudiation refers to the assurance that the owner of a signature keypair that was capable of generating an existing signature corresponding to certain data cannot convincingly deny having signed the data, unless its private key was compromised. The digital signature scheme ML-DSA possesses 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 full discussion of these properties in ML-DSA can be found at [CDFFJ21].
References
Normative References
[CSOR]

Computer Security Objects Register (CSOR)
National Institute of Standards and Technology
13 June 2025
[FIPS204]

Module-Lattice-Based Digital Signature Standard
National Institute of Standards and Technology
13 August 2024
NIST FIPS 204
DOI 10.6028/NIST.FIPS.204
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC5280]

Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
D. Cooper
S. Santesson
S. Farrell
S. Boeyen
R. Housley
W. Polk
May 2008
RFC 5280
DOI 10.17487/RFC5280
[RFC5912]

New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)
P. Hoffman
J. Schaad
June 2010
RFC 5912
DOI 10.17487/RFC5912
[RFC5958]

Asymmetric Key Packages
S. Turner
August 2010
RFC 5958
DOI 10.17487/RFC5958
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
[X680]

Information Technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation
ITU-T
February 2021
ITU-T Recommendation X.680
ISO/IEC 8824-1:2021
[X690]

Information Technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)
ITU-T
February 2021
ITU-T Recommendation X.690
ISO/IEC 8825-1:2021
Informative References
[CDFFJ21]

BUFFing signature schemes beyond unforgeability and the case of post-quantum signatures
C. Cremers
S. Düzlü
R. Fiedler
M. Fischlin
C. Janson
October 2023
Cryptology ePrint Archive, Paper 2020/1525
[Dilithium]

CRYSTALS-Dilithium Algorithm Specifications and Supporting Documentation (Version 3.1)
S. Bai
L. Ducas
E. Kiltz
T. Lepoint
V. Lyubashevsky
P. Schwabe
G. Seiler
D. Stehlé
2021-02-08
[Fiat-Shamir]

Fiat-Shamir with aborts: Applications to lattice and factoring-based signatures
V. Lyubashevsky
2009
International Conference on the Theory and Application of Cryptology and Information Security
[FIPS204-ExternalMuFAQ]

FIPS 204 Section 6 FAQ
National Institute of Standards and Technology
2025
[NIST-PQC]

Post-Quantum Cryptography (PQC)
National Institute of Standards and Technology
28 July 2025
[RFC3647]

Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework
S. Chokhani
W. Ford
R. Sabett
C. Merrill
S. Wu
November 2003
RFC 3647
DOI 10.17487/RFC3647
[RFC7468]

Textual Encodings of PKIX, PKCS, and CMS Structures
S. Josefsson
S. Leonard
April 2015
RFC 7468
DOI 10.17487/RFC7468
ASN.1 Module
This appendix includes the ASN.1 module [X680] for the ML-DSA. Note that as per [RFC5280], certificates use the Distinguished Encoding Rules; see [X690]. This module imports objects from [RFC5912].

X509-ML-DSA-2025
{ iso(1) identified-organization(3) dod(6)
  internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
  id-mod-x509-ml-dsa-2025(119) }

DEFINITIONS IMPLICIT TAGS ::= BEGIN

EXPORTS ALL;

IMPORTS

 PUBLIC-KEY, SIGNATURE-ALGORITHM
   FROM AlgorithmInformation-2009  -- [RFC 5912]
     { iso(1) identified-organization(3) dod(6) internet(1)
       security(5) mechanisms(5) pkix(7) id-mod(0)
       id-mod-algorithmInformation-02(58) } ;

--
-- ML-DSA Identifiers
--

nistAlgorithms OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
  country(16) us(840) organization(1) gov(101) csor(3)
  nistAlgorithms(4) }

sigAlgs OBJECT IDENTIFIER ::= { nistAlgorithms 3 }

id-ml-dsa-44 OBJECT IDENTIFIER ::= { sigAlgs 17 }

id-ml-dsa-65 OBJECT IDENTIFIER ::= { sigAlgs 18 }

id-ml-dsa-87 OBJECT IDENTIFIER ::= { sigAlgs 19 }

--
-- Public Key Algorithms
--

PublicKeys PUBLIC-KEY ::= {
  -- This expands PublicKeys from [RFC 5912]
  pk-ml-dsa-44 |
  pk-ml-dsa-65 |
  pk-ml-dsa-87,
  ...
}

--
-- ML-DSA Public Keys
--

pk-ml-dsa-44 PUBLIC-KEY ::= {
  IDENTIFIER id-ml-dsa-44
  -- KEY no ASN.1 wrapping; 1312 octets --
  PARAMS ARE absent
  CERT-KEY-USAGE { digitalSignature, nonRepudiation,
                   keyCertSign, cRLSign }
  PRIVATE-KEY ML-DSA-44-PrivateKey
  }

ML-DSA-44-PrivateKey ::= CHOICE {
  seed [0] OCTET STRING (SIZE (32)),
  expandedKey OCTET STRING (SIZE (2560)),
  both SEQUENCE {
      seed OCTET STRING (SIZE (32)),
      expandedKey OCTET STRING (SIZE (2560))
      }
  }

pk-ml-dsa-65 PUBLIC-KEY ::= {
  IDENTIFIER id-ml-dsa-65
  -- KEY no ASN.1 wrapping; 1952 octets --
  PARAMS ARE absent
  CERT-KEY-USAGE { digitalSignature, nonRepudiation,
                   keyCertSign, cRLSign }
  PRIVATE-KEY ML-DSA-65-PrivateKey
  }

ML-DSA-65-PrivateKey ::= CHOICE {
  seed [0] OCTET STRING (SIZE (32)),
  expandedKey OCTET STRING (SIZE (4032)),
  both SEQUENCE {
      seed OCTET STRING (SIZE (32)),
      expandedKey OCTET STRING (SIZE (4032))
      }
  }

pk-ml-dsa-87 PUBLIC-KEY ::= {
  IDENTIFIER id-ml-dsa-87
  -- KEY no ASN.1 wrapping; 2592 octets --
  PARAMS ARE absent
  CERT-KEY-USAGE { digitalSignature, nonRepudiation,
                    keyCertSign, cRLSign }
  PRIVATE-KEY ML-DSA-87-PrivateKey
  }

ML-DSA-87-PrivateKey ::= CHOICE {
  seed [0] OCTET STRING (SIZE (32)),
  expandedKey OCTET STRING (SIZE (4896)),
  both SEQUENCE {
      seed OCTET STRING (SIZE (32)),
      expandedKey OCTET STRING (SIZE (4896))
      }
  }

ML-DSA-44-PublicKey ::= OCTET STRING (SIZE (1312))

ML-DSA-65-PublicKey ::= OCTET STRING (SIZE (1952))

ML-DSA-87-PublicKey ::= OCTET STRING (SIZE (2602))

--
-- Signature Algorithms
--

SignatureAlgorithms SIGNATURE-ALGORITHM ::= {
  -- This expands SignatureAlgorithms from [RFC 5912]
  sa-ml-dsa-44 |
  sa-ml-dsa-65 |
  sa-ml-dsa-87,
  ... }

--
-- ML-DSA Signature Algorithm Identifiers
--

sa-ml-dsa-44 SIGNATURE-ALGORITHM ::= {
  IDENTIFIER id-ml-dsa-44
  PARAMS ARE absent
  PUBLIC-KEYS { pk-ml-dsa-44 }
  SMIME-CAPS { IDENTIFIED BY id-ml-dsa-44 }
  }

sa-ml-dsa-65 SIGNATURE-ALGORITHM ::= {
  IDENTIFIER id-ml-dsa-65
  PARAMS ARE absent
  PUBLIC-KEYS { pk-ml-dsa-65 }
  SMIME-CAPS { IDENTIFIED BY id-ml-dsa-65 }
  }

sa-ml-dsa-87 SIGNATURE-ALGORITHM ::= {
  IDENTIFIER id-ml-dsa-87
  PARAMS ARE absent
  PUBLIC-KEYS { pk-ml-dsa-87 }
  SMIME-CAPS { IDENTIFIED BY id-ml-dsa-87 }
  }
END
Security Strengths
Instead of defining the strength of a quantum algorithm using the common but 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 attacks. 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 references, respectively. Levels 2 and 4 use collision search for SHA-256 and SHA-384 as references.
The parameter sets defined for NIST security levels 2, 3, and 5 are listed in Table 2, along with the resulting signature size, public key, and private key sizes in bytes. Note that these are the sizes of the raw keys, not including ASN.1 encoding overhead from OneAsymmetricKey and SubjectPublicKeyInfo wrappers. Private key sizes are shown for both the seed format and expanded format.
ML-DSA Parameters
Level | (k,l) | eta | Sig. (B) | Public Key(B) | Private Seed(B) | Private Expand(B)
2 | (4,4) | 2 | 2420 | 1312 | 32 | 2560
3 | (6,5) | 4 | 3309 | 1952 | 32 | 4032
5 | (8,7) | 2 | 4627 | 2592 | 32 | 4896
Examples
This appendix contains examples of ML-DSA private keys, public keys, certificates, and inconsistent seed and expanded private keys.
Example Private Keys
The following examples show ML-DSA private keys in different formats, all derived from the same seed 000102...1e1f. For each security level, we show the seed-only format (using a context-specific [0] primitive tag with an implicit encoding of OCTET STRING), the expanded format, and both formats together.
NOTE: All examples use the same seed value, showing how the same seed produces different expanded private keys for each security level.
ML-DSA-44 Private Key Examples
Each of the examples includes the textual encoding [RFC7468] followed by the so-called "pretty print"; the private keys are the same.
Seed Format

-----BEGIN PRIVATE KEY-----
MDQCAQAwCwYJYIZIAWUDBAMRBCKAIAABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZ
GhscHR4f
-----END PRIVATE KEY-----

SEQUENCE {
  INTEGER { 0 }
  SEQUENCE {
    OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.3.17 }
  }
  OCTET_STRING {
    [0 PRIMITIVE] { `000102030405060708090a0b0c0d0e0f10111213141
5161718191a1b1c1d1e1f` }
  }
}
Expanded Format

-----BEGIN PRIVATE KEY-----
MIIKGAIBADALBglghkgBZQMEAxEEggoEBIIKANeytHJUquDbReeTDUqY0sl9jxOX
0Xidr6FwJLMW6b7JOc4Pf3f421ZE3No2a/5HNL2V9DX/mmE6pUqkHCxpTAQymgex
+rtI9SownxGhiY+EjiMi/+Yj7IENs77jNoWFSogmnaMg1RIL/P6JoY4w9xFNg6pA
SmRrbJlziYYNElIu4ABuI4SBkYZhmyYNEYZk1KYoIhhEgkAomBRhSKZhTEJIoZII
wjgpUSRICKElwggxCMRxIBQJFINsGKeAhBBuycBwIrVkCLBhDAcEmBJEUYhpWQBG
IpMgQQYuQrZMARZJFChMQahRgEYKURZRWgggAiJE3JhJ0TJR4TBl08CFkqhREqFk
ADkiCUZiHMcM2Qht0AYmUkCFgEQwkQYsUMgJJMWEGpZtSpgsmQZtpEQyIKdkWjJu
EbVwIJJhJBOOBIUsCkhyyKBR0wgqmSCAWCQgJAdOWRSIEKRkYMBt4LKNGxkJIDQi
wCRBCUNxCiEgYaIBUiJSG4CAmjQAE5NN0zIpIhcKmJJpGhRRICchnMAgYqKBSBhp
GoVNg0RpWyBBAxJCyxhGAakNDAIxg7AhWiJKyJIF2ZBpBDBqSwZK0rIBHEBAgUIy
UjJyVKZAWhgQDDISksKAUhJiXIIoC7RsA0KNUxAMFAEO4TZSiIQkkQIKY0YmIAYp
EcIo0CBIArNsojYJWoZIy7Rhi0ZixECCGokJEAJNJLJFIBIlJMkFiCiMycBNWUgi
CiduwTRkTJBgW0RQgoZJQ4gEQ7KMYDCAoogthKRtjKYp0MaEQgZGiYhRAKmNAUmN
5DgNpAaN05RxQrJsGoRhG6MoQrQoCKBxGsUx4KBMATdlJChiFCiQCRBh2UAiGzNg
CQKS0CSBIAQISRhEoyItXIhEFJgIpEZhAZVkCzkKDJRQykBq0rIgwDgBgjCOE7kI
kYCEFIgpwBiREjUNoCQi4gQG2cKFBCgSHMmJGAJy0kApwggS2AYqmZRxm7hoI4Qp
GiKJFEUR3IJEUJZFDESEwLIEmqYFQ4YsRDJuiEQhIKhMmjBw47gtYyaIAyVJA0OM
SKgJyhRyUzROEkMIG6cEWTAi2ZSA4jQigUISnDAqlDQmYQRFJCYoE0YJSjJtESgJ
GLglYigRE0ENQbIRkIRMixISosaIycAwIgYG0hiOhIYwkERSEogx2SBxE8UoQwYO
AzBgzKaEWCZSTIgBHvclYshf+kOs+kkhfysXLXu8FGIObZgKcaq73wxF6aIG7LFC
P+4V3swXYBMAFJ2SI81ubG4fqOQfx8ZJOKtokF/T3NpQ2HCC59DXHRvJsrhMhVI8
qP5srSlK34O+FbEI/3IdDMh7w906dZAYSw6EVmOpH8nhw8U6YdhnQgsE8JI1V1O8
ZaBjaP1BKV/QmSQTLG+R9nlkwUJnSnJcNDkUxM7PWMB0vK9FWMl795EeB6ptCTjy
7iuzwajFldY16ENC/eoB3CSyEa0vwoHPd+WREMerxUvwyG1IC5vidkcdydYDzumM
/as+n8+3A3k1YFSepEUPp7M/uRacRLTSX7nEV/SXkc09oD6slglYE8EFEyzNpOY+
SSKM0j2KHzeFbxQtk7kNsJ+Cr4kljGOquAR6gMA2yTV+ogRvjcY1TwxSlfNCu0F9
PP6wsf0zYiwp4Uy72S4TY8ZevUUEt1EjKblnDjLhssZ6VOfxpV+Ln56gToyjpwXm
KjxeY3N0r7eutt3qYSzeKPAaIC16pONHItJ90/m4mJTQGf1dTXEZ7+NyO7oQTLi7
CYHgdN46/iANqq6tgmzEXyRNv0Ma+rNO+994JHTS/VcRj2RiFJNO2Zy6OwA+jWej
g29vGfxBkQzlFj7jrpnrhNUU63YeY2hOpW+XkdLdSqxuYWi5SMgX91oiKssOjNwD
zEr+j2cVfho2O3+u/58XK5iRNnfFod0IXp7kwiBSwa9YGTEWZz3NO/xfNLhV3MbH
eIVknp5x9D1K6g9Lcsp+2gV4uhPTGmWNLQYKmmb/ae0b55l6L7HScj04+b+r4Y+O
ezzakG5Om16ULI6uspYHDr/TZJR6lAzJeL7Wazd0nm1dzXvoxJREDiuEzs/vuYwL
7fs8QeM1nSzXGX++cgxIqmxrZGXB7mPjVpwq3HREkTcLf3gm/gt3odGdZBAdAyuR
gQa0LS73N0flYB/kulDyPt5SHwMagX0VKUpDci6DeHhLbbDPG6norpEdkgG5zpzD
AZxvXCfLmNomFEtkIlp8kysw92Hnii1Zodi4PsY0Si9t1H52VwbQC/SnmmqSbDup
HYEsjyx5erF5Zwnl0WhWd4KTUp8ChtAVw7U5lhlkKjM+nlk9bj9TU5lCCOnmozKF
HX9lJSKpKLkX4n4tbUITff4uv6b7HGeybAJUUoaF9+vb4xWmjqotp2noqfQtPmAA
fHEzCSaywAEtg+rU5P0e2HLM0ZciAdKwJ/NUWsLTDNeLwddA/sy8b8KgRGxuMOrF
H1ppCYqi1EfyCFtOTkuSzMJpIdLeR4UYzQkM4meuotJ62lf9iLSXbYn7hDzcz0mn
bKJnnmgBv6f7AxiW+1BilwS5kjk2u13ThTERIcrfsRmV5ZtzA0z2ftA6uBOGdkjQ
JYKAh+lJqa/Ra5XXLZmx7coleqwTL/t6Bwmu1anA/wX7Dyu/KECe7XtfWAG+lkzt
AZ4ct4UdOFHxApBnThn/sAizAcSs9kGiuxQhbh1pyr9Ste8idJaw8weZqFXRF/rT
dEpvozUD6nmLUt3X7lQmYJ2/zT8ME7Fk1sBR9+1KEZcZpxLjiNMoQCCB/xNUtVTS
wjev7TsVHEuo6fS964SZowZuJrvGnorwid7HFzHR3FKeqxfvc3RzTA/kdUlMg4Nr
3TSgO5vImRRxYGG/uY7G5hw+1EOO3K8lJDxkcIa56nAYsNmooLAM7LAKveJJjWnC
M2EBp3LL5PVxUj9RvQWILN81i4ScwUCqH68iQjoShRzg4z/UiXWklZ+lxf5BjJOQ
gZGrbnQbd7/gLL1pjueVxGbWFWGeZEE4LG6sAYNO6atzzqgLviNceNqRvXm2+C+J
l4XWhwDTk+Z1wiJNa3oa0hMgSVZ5ra7XAWe1CGZxOlMQnbe299gTBOzf2Dsxmx7y
SDBrRa0p593Mhj2sVgSLXWnqF1AR92FMAKhqhjzeGHKokyh4uax+GsW9pJl7cgZP
DNdfTIFOA03hGsuQE89+qSa05+qs4HDHuiGI760uQx4SI9Rd0FxNhAPC5FzuZBPs
vnUn6HPkVcTmEKYYOarMC9VtJIPnjymLZqR46y9VjLr8qGvoR7rrAsWyFsjNiP6k
3ySbCeZwogcDq6wksKkavEpWRmAUQroQvs/TCZOIAFHQf1agWpN556jmvv7j8i+q
EGOY93BgBuQum+HvidJcJy8RqVCVxYfXE3MihN6dvTxyF7BoniHY6w/2lmg=
-----END PRIVATE KEY-----

SEQUENCE {
  INTEGER { 0 }
  SEQUENCE {
    OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.3.17 }
  }
  OCTET_STRING {
    OCTET_STRING { `d7b2b47254aae0db45e7930d4a98d2c97d8f1397d178
[encoded data, 5056 characters]
b0689e21d8eb0ff69668` }
  }
}
Both Format

-----BEGIN PRIVATE KEY-----
MIIKPgIBADALBglghkgBZQMEAxEEggoqMIIKJgQgAAECAwQFBgcICQoLDA0ODxAR
EhMUFRYXGBkaGxwdHh8EggoA17K0clSq4NtF55MNSpjSyX2PE5fReJ2voXAksxbp
vsk5zg9/d/jbVkTc2jZr/kc0vZX0Nf+aYTqlSqQcLGlMBDKaB7H6u0j1KjCfEaGJ
j4SOIyL/5iPsgQ2zvuM2hYVKiCadoyDVEgv8/omhjjD3EU2DqkBKZGtsmXOJhg0S
Ui7gAG4jhIGRhmGbJg0RhmTUpigiGESCQCiYFGFIpmFMQkihkgjCOClRJEgIoSXC
CDEIxHEgFAkUg2wYp4CEEG7JwHAitWQIsGEMBwSYEkRRiGlZAEYikyBBBi5CtkwB
FkkUKExBqFGARgpRFlFaCCACIkTcmEnRMlHhMGXTwIWSqFESoWQAOSIJRmIcxwzZ
CG3QBiZSQIWARDCRBixQyAkkxYQalm1KmCyZBm2kRDIgp2RaMm4RtXAgkmEkE44E
hSwKSHLIoFHTCCqZIIBYJCAkB05ZFIgQpGRgwG3gso0bGQkgNCLAJEEJQ3EKISBh
ogFSIlIbgICaNAATk03TMikiFwqYkmkaFFEgJyGcwCBiooFIGGkahU2DRGlbIEED
EkLLGEYBqQ0MAjGDsCFaIkrIkgXZkGkEMGpLBkrSsgEcQECBQjJSMnJUpkBaGBAM
MhKSwoBSEmJcgigLtGwDQo1TEAwUAQ7hNlKIhCSRAgpjRiYgBikRwijQIEgCs2yi
NglahkjLtGGLRmLEQIIaiQkQAk0kskUgEiUkyQWIKIzJwE1ZSCIKJ27BNGRMkGBb
RFCChklDiARDsoxgMICiiC2EpG2MpinQxoRCBkaJiFEAqY0BSY3kOA2kBo3TlHFC
smwahGEboyhCtCgIoHEaxTHgoEwBN2UkKGIUKJAJEGHZQCIbM2AJApLQJIEgBAhJ
GESjIi1ciEQUmAikRmEBlWQLOQoMlFDKQGrSsiDAOAGCMI4TuQiRgIQUiCnAGJES
NQ2gJCLiBAbZwoUEKBIcyYkYAnLSQCnCCBLYBiqZlHGbuGgjhCkaIokURRHcgkRQ
lkUMRITAsgSapgVDhixEMm6IRCEgqEyaMHDjuC1jJogDJUkDQ4xIqAnKFHJTNE4S
QwgbpwRZMCLZlIDiNCKBQhKcMCqUNCZhBEUkJigTRglKMm0RKAkYuCViKBETQQ1B
shGQhEyLEhKixojJwDAiBgbSGI6EhjCQRFISiDHZIHETxShDBg4DMGDMpoRYJlJM
iAEe9yViyF/6Q6z6SSF/Kxcte7wUYg5tmApxqrvfDEXpogbssUI/7hXezBdgEwAU
nZIjzW5sbh+o5B/Hxkk4q2iQX9Pc2lDYcILn0NcdG8myuEyFUjyo/mytKUrfg74V
sQj/ch0MyHvD3Tp1kBhLDoRWY6kfyeHDxTph2GdCCwTwkjVXU7xloGNo/UEpX9CZ
JBMsb5H2eWTBQmdKclw0ORTEzs9YwHS8r0VYyXv3kR4Hqm0JOPLuK7PBqMWV1jXo
Q0L96gHcJLIRrS/Cgc935ZEQx6vFS/DIbUgLm+J2Rx3J1gPO6Yz9qz6fz7cDeTVg
VJ6kRQ+nsz+5FpxEtNJfucRX9JeRzT2gPqyWCVgTwQUTLM2k5j5JIozSPYofN4Vv
FC2TuQ2wn4KviSWMY6q4BHqAwDbJNX6iBG+NxjVPDFKV80K7QX08/rCx/TNiLCnh
TLvZLhNjxl69RQS3USMpuWcOMuGyxnpU5/GlX4ufnqBOjKOnBeYqPF5jc3Svt662
3ephLN4o8BogLXqk40ci0n3T+biYlNAZ/V1NcRnv43I7uhBMuLsJgeB03jr+IA2q
rq2CbMRfJE2/Qxr6s07733gkdNL9VxGPZGIUk07ZnLo7AD6NZ6ODb28Z/EGRDOUW
PuOumeuE1RTrdh5jaE6lb5eR0t1KrG5haLlIyBf3WiIqyw6M3APMSv6PZxV+GjY7
f67/nxcrmJE2d8Wh3QhenuTCIFLBr1gZMRZnPc07/F80uFXcxsd4hWSennH0PUrq
D0tyyn7aBXi6E9MaZY0tBgqaZv9p7RvnmXovsdJyPTj5v6vhj457PNqQbk6bXpQs
jq6ylgcOv9NklHqUDMl4vtZrN3SebV3Ne+jElEQOK4TOz++5jAvt+zxB4zWdLNcZ
f75yDEiqbGtkZcHuY+NWnCrcdESRNwt/eCb+C3eh0Z1kEB0DK5GBBrQtLvc3R+Vg
H+S6UPI+3lIfAxqBfRUpSkNyLoN4eEttsM8bqeiukR2SAbnOnMMBnG9cJ8uY2iYU
S2QiWnyTKzD3YeeKLVmh2Lg+xjRKL23UfnZXBtAL9KeaapJsO6kdgSyPLHl6sXln
CeXRaFZ3gpNSnwKG0BXDtTmWGWQqMz6eWT1uP1NTmUII6eajMoUdf2UlIqkouRfi
fi1tQhN9/i6/pvscZ7JsAlRShoX369vjFaaOqi2naeip9C0+YAB8cTMJJrLAAS2D
6tTk/R7YcszRlyIB0rAn81RawtMM14vB10D+zLxvwqBEbG4w6sUfWmkJiqLUR/II
W05OS5LMwmkh0t5HhRjNCQziZ66i0nraV/2ItJdtifuEPNzPSadsomeeaAG/p/sD
GJb7UGKXBLmSOTa7XdOFMREhyt+xGZXlm3MDTPZ+0Dq4E4Z2SNAlgoCH6Umpr9Fr
ldctmbHtyiV6rBMv+3oHCa7VqcD/BfsPK78oQJ7te19YAb6WTO0Bnhy3hR04UfEC
kGdOGf+wCLMBxKz2QaK7FCFuHWnKv1K17yJ0lrDzB5moVdEX+tN0Sm+jNQPqeYtS
3dfuVCZgnb/NPwwTsWTWwFH37UoRlxmnEuOI0yhAIIH/E1S1VNLCN6/tOxUcS6jp
9L3rhJmjBm4mu8aeivCJ3scXMdHcUp6rF+9zdHNMD+R1SUyDg2vdNKA7m8iZFHFg
Yb+5jsbmHD7UQ47cryUkPGRwhrnqcBiw2aigsAzssAq94kmNacIzYQGncsvk9XFS
P1G9BYgs3zWLhJzBQKofryJCOhKFHODjP9SJdaSVn6XF/kGMk5CBkatudBt3v+As
vWmO55XEZtYVYZ5kQTgsbqwBg07pq3POqAu+I1x42pG9ebb4L4mXhdaHANOT5nXC
Ik1rehrSEyBJVnmtrtcBZ7UIZnE6UxCdt7b32BME7N/YOzGbHvJIMGtFrSnn3cyG
PaxWBItdaeoXUBH3YUwAqGqGPN4YcqiTKHi5rH4axb2kmXtyBk8M119MgU4DTeEa
y5ATz36pJrTn6qzgcMe6IYjvrS5DHhIj1F3QXE2EA8LkXO5kE+y+dSfoc+RVxOYQ
phg5qswL1W0kg+ePKYtmpHjrL1WMuvyoa+hHuusCxbIWyM2I/qTfJJsJ5nCiBwOr
rCSwqRq8SlZGYBRCuhC+z9MJk4gAUdB/VqBak3nnqOa+/uPyL6oQY5j3cGAG5C6b
4e+J0lwnLxGpUJXFh9cTcyKE3p29PHIXsGieIdjrD/aWaA==
-----END PRIVATE KEY-----

SEQUENCE {
  INTEGER { 0 }
  SEQUENCE {
    OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.3.17 }
  }
  OCTET_STRING {
    SEQUENCE {
      OCTET_STRING { `000102030405060708090a0b0c0d0e0f1011121314
15161718191a1b1c1d1e1f` }
      OCTET_STRING { `d7b2b47254aae0db45e7930d4a98d2c97d8f1397d1
[encoded data, 5056 characters]
17b0689e21d8eb0ff69668` }
    }
  }
}
ML-DSA-65 Private Key Examples
Each of the examples includes the textual encoding [RFC7468] followed by the so-called "pretty print"; the private keys are the same.
Seed Format

-----BEGIN PRIVATE KEY-----
MDQCAQAwCwYJYIZIAWUDBAMSBCKAIAABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZ
GhscHR4f
-----END PRIVATE KEY-----

SEQUENCE {
  INTEGER { 0 }
  SEQUENCE {
    OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.3.18 }
  }
  OCTET_STRING {
    [0 PRIMITIVE] { `000102030405060708090a0b0c0d0e0f10111213141
5161718191a1b1c1d1e1f` }
  }
}
Expanded Format

-----BEGIN PRIVATE KEY-----
[encoded data, 5376 characters]
v++Sr2yhR7EyRNbIkvyO8iOrP0P5JML0Zgl+6A==
-----END PRIVATE KEY-----

SEQUENCE {
  INTEGER { 0 }
  SEQUENCE {
    OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.3.18 }
  }
  OCTET_STRING {
    OCTET_STRING { `48683d91978e31eb3dddb8b0473482d2b88a5f625949
[encoded data, 8000 characters]
3f43f924c2f466097ee8` }
  }
}
Both Format

-----BEGIN PRIVATE KEY-----
[encoded data, 5440 characters]
1siS/I7yI6s/Q/kkwvRmCX7o
-----END PRIVATE KEY-----

SEQUENCE {
  INTEGER { 0 }
  SEQUENCE {
    OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.3.18 }
  }
  OCTET_STRING {
    SEQUENCE {
      OCTET_STRING { `000102030405060708090a0b0c0d0e0f1011121314
15161718191a1b1c1d1e1f` }
      OCTET_STRING { `48683d91978e31eb3dddb8b0473482d2b88a5f6259
[encoded data, 8000 characters]
ab3f43f924c2f466097ee8` }
    }
  }
}
ML-DSA-87 Private Key Examples
Each of the examples includes the textual encoding [RFC7468] followed by the so-called "pretty print"; the private keys are the same.
Seed Format

-----BEGIN PRIVATE KEY-----
MDQCAQAwCwYJYIZIAWUDBAMTBCKAIAABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZ
GhscHR4f
-----END PRIVATE KEY-----

SEQUENCE {
  INTEGER { 0 }
  SEQUENCE {
    OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.3.19 }
  }
  OCTET_STRING {
    [0 PRIMITIVE] { `000102030405060708090a0b0c0d0e0f10111213141
5161718191a1b1c1d1e1f` }
  }
}
Expanded Format

-----BEGIN PRIVATE KEY-----
[encoded data, 6528 characters]
v+h/H5X/wulvxVllZ+lDZN+qbZ1abrma5N30JA==
-----END PRIVATE KEY-----

SEQUENCE {
  INTEGER { 0 }
  SEQUENCE {
    OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.3.19 }
  }
  OCTET_STRING {
    OCTET_STRING { `9792bcec2f2430686a82fccf3c2f5ff665e771d7ab41
[encoded data, 9728 characters]
6d9d5a6eb99ae4ddf424` }
  }
}
Both Format

-----BEGIN PRIVATE KEY-----
[encoded data, 6592 characters]
WWVn6UNk36ptnVpuuZrk3fQk
-----END PRIVATE KEY-----

SEQUENCE {
  INTEGER { 0 }
  SEQUENCE {
    OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.3.19 }
  }
  OCTET_STRING {
    SEQUENCE {
      OCTET_STRING { `000102030405060708090a0b0c0d0e0f1011121314
15161718191a1b1c1d1e1f` }
      OCTET_STRING { `9792bcec2f2430686a82fccf3c2f5ff665e771d7ab
[encoded data, 9728 characters]
aa6d9d5a6eb99ae4ddf424` }
    }
  }
}
Example Public Keys
The following is the ML-DSA-44 public key corresponding to the private key in the previous section. The textual encoding [RFC7468] is followed by the so-called "pretty print"; the public keys are the same.

-----BEGIN PUBLIC KEY-----
MIIFMjALBglghkgBZQMEAxEDggUhANeytHJUquDbReeTDUqY0sl9jxOX0Xidr6Fw
JLMW6b7JT8mUbULxm3mnQTu6oz5xSctC7VEVaTrAQfrLmIretf4OHYYxGEmVtZLD
l9IpTi4U+QqkFLo4JomaxD9MzKy8JumoMrlRGNXLQzy++WYLABOOCBf2HnYsonTD
atVU6yKqwRYuSrAay6HjjE79j4C2WzM9D3LlXf5xzpweu5iJ58VhBsD9c4A6Kuz+
r97XqjyyztpU0SvYzTanjPl1lDtHq9JeiArEUuV0LtHo0agq+oblkMdYwVrk0oQN
kryhpQkPQElll/yn2LlRPxob2m6VCqqY3kZ1B9Sk9aTwWZIWWCw1cvYu2okFqzWB
ZwxKAnd6M+DKcpX9j0/20aCjp2g9ZfX19/xg2gI+gmxfkhRMAvfRuhB1mHVT6pNn
/NdtmQt/qZzUWv24g21D5Fn1GH3wWEeXCaAepoNZNfpwRgmQzT3BukAbqUurHd5B
rGerMxncrKBgSNTE7vJ+4TqcF9BTj0MPLWQtwkFWYN54h32NirxyUjl4wELkKF9D
GYRsRBJiQpdoRMEOVWuiFbWnGeWdDGsqltOYWQcf3MLN51JKe+2uVOhbMY6FTo/i
svPt+slxkSgnCq/R5QRMOk/a/Z/zH5B4S46ORZYUSg2vWGUR09mWK56pWvGXtOX8
YPKx7RXeOlvvX4m9x52RBR2bKBbnT6VFMe/cHL501EiFf0drzVjyHAtlOzt2pOB2
plWaMCcYVVzGP3SFmqurkl8COGHKjND3utsocfZ9VTJtdFETWtRfShumkRj7ssij
DuyTku8/l3Bmya3VxxDMZHsVFNIX2VjHAXw+kP0gwE5nS5BIbpNwoxoAHTL0c5ee
SQZ0nn5Hf6C3RQj4pfI3gxK4PCW9OIygsP/3R4uvQrcWZ+2qyXxGsSlkPlhuWwVa
DCEZRtTzbmdb7Vhg+gQqMV2YJhZNapI3w1pfv0lUkKW9TfJIuVxKrneEtgVnMWas
QkW1tLCCoJ6TI+YvIHjFt2eDRG3v1zatOjcC1JsImESQCmGDM5e8RBmzDXqXoLOH
wZEUdMTUG1PjKpd6y28Op122W7OeWecB52lX3vby1EVZwxp3EitSBOO1whnxaIsU
7QvAuAGz5ugtzUPpwOn0F0TNmBW9G8iCDYuxI/BPrNGxtoXdWisbjbvz7ZM2cPCV
oYC08ZLQixC4+rvfzCskUY4y7qCl4MkEyoRHgAg/OwzS0Li2r2e8NVuUlAJdx7Cn
j6gOOi2/61EyiFHWB4GY6Uk2Ua54fsAlH5Irow6fUd9iptcnhM890gU5MXbfoySl
Er2Ulwo23TSlFKhnkfDrNvAUWwmrZGUbSgMTsplhGiocSIkWJ1mHaKMRQGC6RENI
bfUVIqHOiLMJhcIW+ObtF43VZ7MEoNTK+6iCooNC8XqaomrljbYwCD0sNY/fVmw/
XWKkKFZ7yeqM6VyqDzVHSwv6jzOaJQq0388gg76O77wQVeGP4VNw7ssmBWbYP/Br
IRquxDyim1TM0A+IFaJGXvC0ZRXMfkHzEk8J7/9zkwmrWLKaFFmgC85QOOk4yWeP
cusOTuX9quZtn4Vz/Jf8QrSVn0v4th14Qz6GsDNdbpGRxNi/SHs5BcEIz9asJLDO
t9y3z1H4TQ7Wh7lerrHFM8BvDZcCPZKnCCWDe1m6bLfU5WsKh8IDhiro8xW6WSXo
7e+meTaaIgJ2YVHxapZfn4Hs52zAcLVYaeTbl4TPBcgwsyQsgxI=
-----END PUBLIC KEY-----

SEQUENCE {
  SEQUENCE {
    OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.3.17 }
  }
  BIT_STRING { `00` `d7b2b47254aae0db45e7930d4a98d2c97d8f1397d17
89dafa17024b316e9bec94fc9946d42f19b79a7413bbaa33e7149cb42ed51156
93ac041facb988adeb5fe0e1d8631184995b592c397d2294e2e14f90aa414ba3
826899ac43f4cccacbc26e9a832b95118d5cb433cbef9660b00138e0817f61e7
62ca274c36ad554eb22aac1162e4ab01acba1e38c4efd8f80b65b333d0f72e55
dfe71ce9c1ebb9889e7c56106c0fd73803a2aecfeafded7aa3cb2ceda54d12bd
8cd36a78cf975943b47abd25e880ac452e5742ed1e8d1a82afa86e590c758c15
ae4d2840d92bca1a5090f40496597fca7d8b9513f1a1bda6e950aaa98de46750
7d4a4f5a4f0599216582c3572f62eda8905ab3581670c4a02777a33e0ca7295f
d8f4ff6d1a0a3a7683d65f5f5f7fc60da023e826c5f92144c02f7d1ba1075987
553ea9367fcd76d990b7fa99cd45afdb8836d43e459f5187df058479709a01ea
6835935fa70460990cd3dc1ba401ba94bab1dde41ac67ab3319dcaca06048d4c
4eef27ee13a9c17d0538f430f2d642dc2415660de78877d8d8abc72523978c04
2e4285f4319846c44126242976844c10e556ba215b5a719e59d0c6b2a96d3985
9071fdcc2cde7524a7bedae54e85b318e854e8fe2b2f3edfac9719128270aafd
1e5044c3a4fdafd9ff31f90784b8e8e4596144a0daf586511d3d9962b9ea95af
197b4e5fc60f2b1ed15de3a5bef5f89bdc79d91051d9b2816e74fa54531efdc1
cbe74d448857f476bcd58f21c0b653b3b76a4e076a6559a302718555cc63f748
59aabab925f023861ca8cd0f7badb2871f67d55326d7451135ad45f4a1ba6911
8fbb2c8a30eec9392ef3f977066c9add5c710cc647b1514d217d958c7017c3e9
0fd20c04e674b90486e9370a31a001d32f473979e4906749e7e477fa0b74508f
8a5f2378312b83c25bd388ca0b0fff7478baf42b71667edaac97c46b129643e5
86e5b055a0c211946d4f36e675bed5860fa042a315d9826164d6a9237c35a5fb
f495490a5bd4df248b95c4aae7784b605673166ac4245b5b4b082a09e9323e62
f2078c5b76783446defd736ad3a3702d49b089844900a61833397bc4419b30d7
a97a0b387c1911474c4d41b53e32a977acb6f0ea75db65bb39e59e701e76957d
ef6f2d44559c31a77122b5204e3b5c219f1688b14ed0bc0b801b3e6e82dcd43e
9c0e9f41744cd9815bd1bc8820d8bb123f04facd1b1b685dd5a2b1b8dbbf3ed9
33670f095a180b4f192d08b10b8fabbdfcc2b24518e32eea0a5e0c904ca84478
0083f3b0cd2d0b8b6af67bc355b9494025dc7b0a78fa80e3a2dbfeb51328851d
6078198e9493651ae787ec0251f922ba30e9f51df62a6d72784cf3dd20539317
6dfa324a512bd94970a36dd34a514a86791f0eb36f0145b09ab64651b4a0313b
299611a2a1c48891627598768a3114060ba4443486df51522a1ce88b30985c21
6f8e6ed178dd567b304a0d4cafba882a28342f17a9aa26ae58db630083d2c358
fdf566c3f5d62a428567bc9ea8ce95caa0f35474b0bfa8f339a250ab4dfcf208
3be8eefbc1055e18fe15370eecb260566d83ff06b211aaec43ca29b54ccd00f8
815a2465ef0b46515cc7e41f3124f09efff739309ab58b29a1459a00bce5038e
938c9678f72eb0e4ee5fdaae66d9f8573fc97fc42b4959f4bf8b61d78433e86b
0335d6e9191c4d8bf487b3905c108cfd6ac24b0ceb7dcb7cf51f84d0ed687b95
eaeb1c533c06f0d97023d92a70825837b59ba6cb7d4e56b0a87c203862ae8f31
5ba5925e8edefa679369a2202766151f16a965f9f81ece76cc070b55869e4db9
784cf05c830b3242c8312` }
}
The following is the ML-DSA-65 public key corresponding to the private key in the previous section. The textual encoding [RFC7468] is followed by the so-called "pretty print"; the public keys are the same.

-----BEGIN PUBLIC KEY-----
MIIHsjALBglghkgBZQMEAxIDggehAEhoPZGXjjHrPd24sEc0gtK4il9iWUn9j1il
YeaWvUwn0Fs427Lt8B5mTv2Bvh6ok2iM5oqi1RxZWPi7xutOie5n0sAyCVTVchLK
xyKf8dbq8DkovVFRH42I2EdzbH3icw1ZeOVBBxMWCXiGdxG/VTmgv8TDUMK+Vyuv
DuLi+xbM/qCAKNmaxJrrt1k33c4RHNq2L/886ouiIz0eVvvFxaHnJt5j+t0q8Bax
GRd/o9lxotkncXP85VtndFrwt8IdWX2+uT5qMvNBxJpai+noJQiNHyqkUVXWyK4V
Nn5OsAO4/feFEHGUlzn5//CQI+r0UQTSqEpFkG7tRnGkTcKNJ5h7tV32np6FYfYa
gKcmmVA4Zf7Zt+5yqOF6GcQIFE9LKa/vcDHDpthXFhC0LJ9CEkWojxl+FoErAxFZ
tluWh+Wz6TTFIlrpinm6c9Kzmdc1EO/60Z5TuEUPC6j84QEv2Y0mCnSqqhP64kmg
BrHDT1uguILyY3giL7NvIoPCQ/D/618btBSgpw1V49QKVrbLyIrh8Dt7KILZje6i
jhRcne39jq8c7y7ZSosFD4lk9G0eoNDCpD4N2mGCrb9PbtF1tnQiV4Wb8i86QX7P
H52JMXteU51YevFrnhMT4EUU/6ZLqLP/K4Mh+IEcs/sCLI9kTnCkuAovv+5gSrtz
eQkeqObFx038AoNma0DAeThwAoIEoTa/XalWjreY00kDi9sMEeA0ReeEfLUGnHXP
KKxgHHeZ2VghDdvLIm5Rr++fHeR7Bzhz1tP5dFa+3ghQgudKKYss1I9LMJMVXzZs
j6YBxq+FjfoywISRsqKYh/kDNZSaXW7apnmIKjqV1r9tlwoiH0udPYy/OEr4GqyV
4rMpTgR4msg3J6XcBFWflq9B2KBTUW/u7rxSdG62qygZ4JEIcQ2DXwEfpjBlhyrT
NNXN/7KyMQUH6S/Jk64xfal/TzCc2vD2ftmdkCFVdgg4SflTskbX/ts/22dnmFCl
rUBOZBR/t89Pau3dBa+0uDSWjR/ogBSWDc5dlCI2Um4SpHjWnl++aXAxCzCMBoRQ
GM/HsqtDChOmsax7sCzMuz2RGsLxEGhhP74Cm/3OAs9c04lQ7XLIOUTt+8dWFa+H
+GTAUfPFVFbFQShjpAwG0dq1Yr3/BXG408ORe70wCIC7pemYI5uV+pG31kFtTzmL
OtvNMJg+01krTZ731CNv0A9Q2YqlOiNaxBcnIPd9lhcmcpgM/o/3pacCeD7cK6Mb
IlkBWhEvx/RoqcL5RkA5AC0w72eLTLeYvBFiFr96mnwYugO3tY/QdRXTEVBJ02FL
56B+dEMAdQ3x0sWHUziQWer8PXhczdMcB2SL7cA6XDuK1G0GTVnBPVc3Ryn8TilT
YuKlGRIEUwQovBUir6KP9f4WVeMEylvIwnrQ4MajndTfKJVsFLOMyTaCzv5AK71e
gtKcRk5E6103tI/FaN/gzG6OFrrqBeUTVZDxkpTnPoNnsCFtu4FQMLneVZE/CAOc
QjUcWeVRXdWvjgiaFeYl6Pbe5jk4bEZJfXomMoh3TeWBp96WKbQbRCQUH5ePuDMS
CO/ew8bg3jm8VwY/Pc1sRwNzwIiR6inLx8xtZIO4iJCDrOhqp7UbHCz+birRjZfO
NvvFbqQvrpfmp6wRSGRHjDZt8eux57EakJhQT9WXW98fSdxwACtjwXOanSY/utQH
P2qfbCuK9LTDMqEDoM/6Xe6y0GLKPCFf02ACa+fFFk9KRCTvdJSIBNZvRkh3Msgg
LHlUeGR7TqcdYnwIYCTMo1SkHwh3s48Zs3dK0glcjaU7Bp4hx2ri0gB+FnGe1ACA
0zT32lLp9aWZBDnK8IOpW4M/Aq0QoIwabQ8mDAByhb1KL0dwOlrvRlKH0lOxisIl
FDFiEP9WaBSxD4eik9bxmdPDlZmQ0MEmi09Q1fn877vyN70MKLgBgtZll0HxTxC/
uyG7oSq2IKojlvVsBoa06pAXmQIkIWsv6K12xKkUju+ahqNjWmqne8Hc+2+6Wad9
/am3Uw3AyoZIyNlzc44Burjwi0kF6EqkZBvWAkEM2XUgJl8vIx8rNeFesvoE0r2U
1ad6uvHg4WEBCpkAh/W0bqmIsrwFEv2g+pI9rdbEXFMB0JSDZzJltasuEPS6Ug9r
utVkpcPV4nvbCA99IOEylqMYGVTDnGSclD6+F99cH3quCo/hJsR3WFpdTWSKDQCL
avXozTG+aakpbU8/0l7YbyIeS5P2X1kplnUzYkuSNXUMMHB1ULWFNtEJpxMcWlu+
SlcVVnwSU0rsdmB2Huu5+uKJHHdFibgOVmrVV93vc2cZa3In6phw7wnd/seda5MZ
poebUgXXa/erpazzOvtZ0X/FTmg4PWvloI6bZtpT3N4Ai7KUuFgr0TLNzEmVn9vC
HlJyGIDIrQNSx58DpDu9hMTN/cbFKQBeHnzZo0mnFoo1Vpul3qgYlo1akUZr1uZO
IL9iQXGYr8ToHCjdd+1AKCMjmLUvvehryE9HW5AWcQziqrwRoGtNuskB7BbPNlyj
8tU4E5SKaToPk+ecRspdWm3KPSjKUK0YvRP8pVBZ3ZsYX3n5xHGWpOgbIQS8RgoF
HgLy6ERP
-----END PUBLIC KEY-----

SEQUENCE {
  SEQUENCE {
    OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.3.18 }
  }
  BIT_STRING { `00` `48683d91978e31eb3dddb8b0473482d2b88a5f62594
9fd8f58a561e696bd4c27d05b38dbb2edf01e664efd81be1ea893688ce68aa2d
51c5958f8bbc6eb4e89ee67d2c0320954d57212cac7229ff1d6eaf03928bd515
11f8d88d847736c7de2730d5978e5410713160978867711bf5539a0bfc4c350c
2be572baf0ee2e2fb16ccfea08028d99ac49aebb75937ddce111cdab62fff3ce
a8ba2233d1e56fbc5c5a1e726de63fadd2af016b119177fa3d971a2d9277173f
ce55b67745af0b7c21d597dbeb93e6a32f341c49a5a8be9e825088d1f2aa4515
5d6c8ae15367e4eb003b8fdf7851071949739f9fff09023eaf45104d2a84a459
06eed4671a44dc28d27987bb55df69e9e8561f61a80a72699503865fed9b7ee7
2a8e17a19c408144f4b29afef7031c3a6d8571610b42c9f421245a88f197e168
12b031159b65b9687e5b3e934c5225ae98a79ba73d2b399d73510effad19e53b
8450f0ba8fce1012fd98d260a74aaaa13fae249a006b1c34f5ba0b882f263782
22fb36f2283c243f0ffeb5f1bb414a0a70d55e3d40a56b6cbc88ae1f03b7b288
2d98deea28e145c9dedfd8eaf1cef2ed94a8b050f8964f46d1ea0d0c2a43e0dd
a6182adbf4f6ed175b6742257859bf22f3a417ecf1f9d89317b5e539d587af16
b9e1313e04514ffa64ba8b3ff2b8321f8811cb3fb022c8f644e70a4b80a2fbfe
e604abb7379091ea8e6c5c74dfc0283666b40c0793870028204a136bf5da9568
eb798d349038bdb0c11e03445e7847cb5069c75cf28ac601c7799d958210ddbc
b226e51afef9f1de47b073873d6d3f97456bede085082e74a298b2cd48f4b309
3155f366c8fa601c6af858dfa32c08491b2a29887f90335949a5d6edaa679882
a3a95d6bf6d970a221f4b9d3d8cbf384af81aac95e2b3294e04789ac83727a5d
c04559f96af41d8a053516feeeebc52746eb6ab2819e09108710d835f011fa63
065872ad334d5cdffb2b2310507e92fc993ae317da97f4f309cdaf0f67ed99d9
0215576083849f953b246d7fedb3fdb67679850a5ad404e64147fb7cf4f6aedd
d05afb4b834968d1fe88014960dce5d942236526e12a478d69e5fbe6970310b3
08c06845018cfc7b2ab430a13a6b1ac7bb02cccbb3d911ac2f11068613fbe029
bfdce02cf5cd38950ed72c83944edfbc75615af87f864c051f3c55456c541286
3a40c06d1dab562bdff0571b8d3c3917bbd300880bba5e998239b95fa91b7d64
16d4f398b3adbcd30983ed3592b4d9ef7d4236fd00f50d98aa53a235ac417272
0f77d96172672980cfe8ff7a5a702783edc2ba31b2259015a112fc7f468a9c2f
9464039002d30ef678b4cb798bc116216bf7a9a7c18ba03b7b58fd07515d3115
049d3614be7a07e744300750df1d2c58753389059eafc3d785ccdd31c07648be
dc03a5c3b8ad46d064d59c13d57374729fc4e295362e2a5191204530428bc152
2afa28ff5fe1655e304ca5bc8c27ad0e0c6a39dd4df28956c14b38cc93682cef
e402bbd5e82d29c464e44eb5d37b48fc568dfe0cc6e8e16baea05e5135590f19
294e73e8367b0216dbb815030b9de55913f08039c42351c59e5515dd5af8e089
a15e625e8f6dee639386c46497d7a263288774de581a7de9629b41b4424141f9
78fb8331208efdec3c6e0de39bc57063f3dcd6c470373c08891ea29cbc7cc6d6
483b8889083ace86aa7b51b1c2cfe6e2ad18d97ce36fbc56ea42fae97e6a7ac1
14864478c366df1ebb1e7b11a9098504fd5975bdf1f49dc70002b63c1739a9d2
63fbad4073f6a9f6c2b8af4b4c332a103a0cffa5deeb2d062ca3c215fd360026
be7c5164f4a4424ef74948804d66f46487732c8202c795478647b4ea71d627c0
86024cca354a41f0877b38f19b3774ad2095c8da53b069e21c76ae2d2007e167
19ed40080d334f7da52e9f5a5990439caf083a95b833f02ad10a08c1a6d0f260
c007285bd4a2f47703a5aef465287d253b18ac22514316210ff566814b10f87a
293d6f199d3c3959990d0c1268b4f50d5f9fcefbbf237bd0c28b80182d665974
1f14f10bfbb21bba12ab620aa2396f56c0686b4ea9017990224216b2fe8ad76c
4a9148eef9a86a3635a6aa77bc1dcfb6fba59a77dfda9b7530dc0ca8648c8d97
3738e01bab8f08b4905e84aa4641bd602410cd97520265f2f231f2b35e15eb2f
a04d2bd94d5a77abaf1e0e161010a990087f5b46ea988b2bc0512fda0fa923da
dd6c45c5301d09483673265b5ab2e10f4ba520f6bbad564a5c3d5e27bdb080f7
d20e13296a3181954c39c649c943ebe17df5c1f7aae0a8fe126c477585a5d4d6
48a0d008b6af5e8cd31be69a9296d4f3fd25ed86f221e4b93f65f59299675336
24b9235750c30707550b58536d109a7131c5a5bbe4a5715567c12534aec76607
61eebb9fae2891c774589b80e566ad557ddef7367196b7227ea9870ef09ddfec
79d6b9319a6879b5205d76bf7aba5acf33afb59d17fc54e68383d6be5a08e9b6
6da53dcde008bb294b8582bd132cdcc49959fdbc21e52721880c8ad0352c79f0
3a43bbd84c4cdfdc6c529005e1e7cd9a349a7168a35569ba5dea818968d5a914
66bd6e64e20bf62417198afc4e81c28dd77ed4028232398b52fbde86bc84f475
b9016710ce2aabc11a06b4dbac901ec16cf365ca3f2d53813948a693a0f93e79
c46ca5d5a6dca3d28ca50ad18bd13fca55059dd9b185f79f9c47196a4e81b210
4bc460a051e02f2e8444f` }
}
The following is the ML-DSA-87 public key corresponding to the private key in the previous section. The textual encoding [RFC7468] is followed by the so-called "pretty print"; the public keys are the same.

-----BEGIN PUBLIC KEY-----
MIIKMjALBglghkgBZQMEAxMDggohAJeSvOwvJDBoaoL8zzwvX/Zl53HXq0G5AljP
p+kOyXEkpzsyO5uiGrZNdnxDP1pSHv/hj4bkahiJUsRGfgSLcp5/xNEV5+SNoYlt
X+EZsQ3N3vYssweVQHS0IzblKDbeYdqUH4036misgQb6vhkHBnmvYAhTcSD3B5O4
6pzA5ue3tMmlx0IcYPJEUboekz2xou4Wx5VZ8hs9G4MFhQqkKvuxPx9NW59INfnY
ffzrFi0O9Kf9xMuhdDzRyHu0ln2hbMh2S2Vp347lvcv/6aTgV0jm/fIlr55O63dz
ti6Phfm1a1SJRVUYRPvYmAakrDab7S0lYQD2iKatXgpwmCbcREnpHiPFUG5kI2Hv
WjE3EvebxLMYaGHKhaS6sX5/lD0bijM6o6584WtEDWAY+eBNr1clx/GpP60aWie2
eJW9JJqpFoXeIK8yyLfiaMf5aHfQyFABE1pPCo8bgmT6br5aNJ2K7K0aFimczy/Z
x7hbrOLO06oSdrph7njtflyltnzdRYqTVAMOaru6v1agojFv7J26g7UdQv0xZ/Hg
+QhV1cZlCbIQJl3B5U7ES0O6fPmu8Ri0TYCRLOdRZqZlHhFs6+SSKacGLAmTH3Gr
0ik/dvfvwyFbqXgAA35Y5HC9u7Q8GwQ56vecVNk7RKrJ7+n74VGHTPsqZMvuKMxM
D+d3Xl2HDxwC5bLjxQBMmV8kybd5y3U6J30Ocf1CXra8LKVs4SnbUfcHQPMeY5dr
UMcxLpeX14xbGsJKX6NHzJFuCoP1w7Z1zTC4Hj+hC5NETgc5dXHM6Yso2lHbkFa8
coxbCxGB4vvTh7THmrGl/v7ONxZ693LdrRTrTDmC2lpZ0OnrFz7GMVCRFwAno6te
9qoSnLhYVye5NYooUB1xOnLz8dsxcUKG+bZAgBOvBgRddVkvwLfdR8c+2cdbEenX
xp98rfwygKkGLFJzxDvhw0+HRIhkzqe1yX1tMvWb1fJThGU7tcT6pFvqi4lAKEPm
Rba5Jp4r2YjdrLAzMo/7BgRQ998IAFPmlpslHodezsMs/FkoQNaatpp14Gs3nFNd
lSZrCC9PCckxYrM7DZ9zB6TqqlIQRDf+1m+O4+q71F1nslqBM/SWRotSuv/b+tk+
7xqYGLXkLscieIo9jTUp/Hd9K6VwgB364B7IgwKDfB+54DVXJ2Re4QRsP5Ffaugt
rU+2sDVqRlGP/INBVcO0/m2vpsyKXM9TxzoISdjUT33PcnVOcOG337RHu070nRpx
j2Fxu84gCVDgzpJhBrFRo+hx1c5JcxvWZQqbDKly2hxfE21Egg6mODwI87OEzyM4
54nFE/YYzFaUpvDO4QRRHh7XxfI6Hr/YoNuEJFUyQBVtv2IoMbDGQ9HFUbbz96mN
KbhcLeBaZfphXu4WSVvZBzdnIRW1PpHF2QAozz8ak5U6FT3lO0QITpzP9rc2aTkm
2u/rstd6pa1om5LzFoZmnfFtFxXMWPeiz7ct0aUekvglmTp0Aivn6etgVGVEVwlN
FJKPICFeeyIqxWtRrb7I2L22mDl5p+OiG0S10VGMqX0LUZX1HtaiQ1DIl0fh7epR
tEjj6RRwVM6SeHPJDbOU2GiI4H3/F3WT1veeFSMCIErrA74jhq8+JAeL0CixaJ9e
FHyfRSyM6wLsWcydtjoDV2zur+mCOQI4l9oCNmMKU8Def0NaGYaXkvqzbnueY1dg
8JBp5kMucAA1rCoCh5//Ch4b7FIgRxk9lOtd8e/VPuoRRMp4lAhS9eyXJ5BLNm7e
T14tMx+tX8KC6ixH6SMUJ3HD3XWoc1dIfe+Z5fGOnZ7WI8F10CiIxR+CwHqA1UcW
s8PCvb4unwqbuq6+tNUpNodkBvXADo5LvQpewFeX5iB8WrbIjxpohCG9BaEU9Nfe
KsJB+g6L7f9H92Ldy+qpEAT40x6FCVyBBUmUrTgm40S6lgQIEPwLKtHeSM+t4ALG
LlpJoHMas4NEvBY23xa/YH1WhV5W1oQAPHGOS62eWgmZefzd7rHEp3ds03o0F8sO
GE4p75vA6HR1umY74J4Aq1Yut8D3Fl+WmptCQUGYzPG/8qLI1omkFOznZiknZlaJ
6U25YeuuxWFcvBp4lcaFGslhQy/xEY1GB9Mu+dxzLVEzO+S00OMN3qeE7Ki+R+dB
vpwZYx3EcKUu9NwTpPNjP9Q014fBcJd7QX31mOHQ3eUGu3HW8LwX7HDjsDzcGWXL
Npk/YzsEcuUNCSOsbGb98dPmRZzBIfD1+U0J6dvPXWkOIyM4OKC6y3xjjRsmUKQw
jNFxtoVRJtHaZypu2FqNeMKG+1b0qz0hSXUoBFxjJiyKQq8vmALFO3u4vijnj+C1
zkX7t6GvGjsoqNlLeJDjyILjm8mOnwrXYCW/DdLwApjnFBoiaz187kFPYE0eC6VN
EdX+WLzOpq13rS6MHKrPMkWQFLe5EAGx76itFypSP7jjZbV3Ehv5/Yiixgwh6CHX
tqy0elqZXkDKztXCI7j+beXhjp0uWJOu/rt6rn/xoUYmDi8RDpOVKCE6ACWjjsea
q8hhsl68UJpGdMEyqqy34BRvFO/RHPyvTKpPd1pxbOMl4KQ1pNNJ1yC88TdFCvxF
BG/Bofg6nTKXd6cITkqtrnEizpcAWTBSjrPH9/ESmzcoh6NxFVo7ogGiXL8dy2Tn
ze4JLDFB+1VQ/j0N2C6HDleLK0ZQCBgRO49laXc8Z3OFtppCt33Lp6z/2V/URS4j
qqHTfh2iFR6mWNQKNZayesn4Ep3GzwZDdyYktZ9PRhIw30ccomCHw5QtXGaH32CC
g1k1o/h8t2Kww7HQ3aSmUzllvvG3uCkuJUwBTQkP7YV8RMGDnGlMCmTj+tkKEfU0
citu4VdPLhSdVddE3kiHAk4IURQxwGJ1DhbHSrnzJC8ts/+xKo1hB/qiKdb2NzsH
8205MrO9sEwZ3WTq3X+Tw8Vkw1ihyB3PHJwx5bBlaPl1RMF9wVaYxcs4mDqa/EJ4
P6p3OlLJ2CYGkL6eMVaqW8FQneo/aVh2lc1v8XK6g+am2KfWu+u7zaNnJzGYP4m8
WDHcN8PzxcVvrMaX88sgvV2629cC5UhErC9iaQH+FZ25Pf1Hc9j+c1YrhGwfyFbR
gCdihA68cteYi951y8pw0xnTLODMAlO7KtRVcj7gx/RzbObmZlxayjKkgcU4Obwl
kWewE9BCM5Xuuaqu4yBhSafVUNZ/xf3+SopcNdJRC2ZDeauPcoVaKvR6vOKmMgSO
r4nly0qI3rxTpZUQOszk8c/xis/wev4etXFqoeQLYxNMOjrpV5+of1Fb4JPC0p22
1rZck2YeAGNrWScE0JPMZxbCNC6xhT1IyFxjrIooVEYse3fn470erFvKKP+qALXT
SfilR62HW5aowrKRDJMBMJo/kTilaTER9Vs8AJypR8Od/ILZjrHKpKnL6IX3hvqG
5VvgYiIvi6kKl0BzMmsxISrs4KNKYA==
-----END PUBLIC KEY-----

SEQUENCE {
  SEQUENCE {
    OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.3.19 }
  }
  BIT_STRING { `00` `9792bcec2f2430686a82fccf3c2f5ff665e771d7ab4
[encoded data, 5120 characters]
3326b31212aece0a34a60` }
}
Example Certificates
NOTE: The example certificates in this section have key usage bits set to digitalSignature, keyCertSign, and cRLSign to lessen the number of examples, i.e., brevity. Certificate Policies (CPs) [RFC3647] for production CAs should consider whether this combination is appropriate.
The following is a self-signed certificate for the ML-DSA-44 public key in the previous section. The textual encoding [RFC7468] is followed by the so-called "pretty print"; the certificates are the same.

-----BEGIN CERTIFICATE-----
[encoded data, 5312 characters]
AAAAABcmOEM=
-----END CERTIFICATE-----

SEQUENCE {
  SEQUENCE {
    [0] {
      INTEGER { 2 }
    }
    INTEGER { `159ffe6f22fd5cc42c524df6fd5e28d0de38f34e` }
    SEQUENCE {
      OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.3.17 }
    }
    SEQUENCE {
      SET {
        SEQUENCE {
          # organizationName
          OBJECT_IDENTIFIER { 2.5.4.10 }
          PrintableString { "IETF" }
        }
      }
      SET {
        SEQUENCE {
          # commonName
          OBJECT_IDENTIFIER { 2.5.4.3 }
          PrintableString { "LAMPS WG" }
        }
      }
    }
    SEQUENCE {
      UTCTime { "200203043210Z" }
      UTCTime { "400129043210Z" }
    }
    SEQUENCE {
      SET {
        SEQUENCE {
          # organizationName
          OBJECT_IDENTIFIER { 2.5.4.10 }
          PrintableString { "IETF" }
        }
      }
      SET {
        SEQUENCE {
          # commonName
          OBJECT_IDENTIFIER { 2.5.4.3 }
          PrintableString { "LAMPS WG" }
        }
      }
    }
    SEQUENCE {
      SEQUENCE {
        OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.3.17 }
      }
      BIT_STRING { `00` `d7b2b47254aae0db45e7930d4a98d2c97d8f139
7d1789dafa17024b316e9bec94fc9946d42f19b79a7413bbaa33e7149cb42ed5
115693ac041facb988adeb5fe0e1d8631184995b592c397d2294e2e14f90aa41
4ba3826899ac43f4cccacbc26e9a832b95118d5cb433cbef9660b00138e0817f
61e762ca274c36ad554eb22aac1162e4ab01acba1e38c4efd8f80b65b333d0f7
2e55dfe71ce9c1ebb9889e7c56106c0fd73803a2aecfeafded7aa3cb2ceda54d
12bd8cd36a78cf975943b47abd25e880ac452e5742ed1e8d1a82afa86e590c75
8c15ae4d2840d92bca1a5090f40496597fca7d8b9513f1a1bda6e950aaa98de4
67507d4a4f5a4f0599216582c3572f62eda8905ab3581670c4a02777a33e0ca7
295fd8f4ff6d1a0a3a7683d65f5f5f7fc60da023e826c5f92144c02f7d1ba107
5987553ea9367fcd76d990b7fa99cd45afdb8836d43e459f5187df058479709a
01ea6835935fa70460990cd3dc1ba401ba94bab1dde41ac67ab3319dcaca0604
8d4c4eef27ee13a9c17d0538f430f2d642dc2415660de78877d8d8abc7252397
8c042e4285f4319846c44126242976844c10e556ba215b5a719e59d0c6b2a96d
39859071fdcc2cde7524a7bedae54e85b318e854e8fe2b2f3edfac9719128270
aafd1e5044c3a4fdafd9ff31f90784b8e8e4596144a0daf586511d3d9962b9ea
95af197b4e5fc60f2b1ed15de3a5bef5f89bdc79d91051d9b2816e74fa54531e
fdc1cbe74d448857f476bcd58f21c0b653b3b76a4e076a6559a302718555cc63
f74859aabab925f023861ca8cd0f7badb2871f67d55326d7451135ad45f4a1ba
69118fbb2c8a30eec9392ef3f977066c9add5c710cc647b1514d217d958c7017
c3e90fd20c04e674b90486e9370a31a001d32f473979e4906749e7e477fa0b74
508f8a5f2378312b83c25bd388ca0b0fff7478baf42b71667edaac97c46b1296
43e586e5b055a0c211946d4f36e675bed5860fa042a315d9826164d6a9237c35
a5fbf495490a5bd4df248b95c4aae7784b605673166ac4245b5b4b082a09e932
3e62f2078c5b76783446defd736ad3a3702d49b089844900a61833397bc4419b
30d7a97a0b387c1911474c4d41b53e32a977acb6f0ea75db65bb39e59e701e76
957def6f2d44559c31a77122b5204e3b5c219f1688b14ed0bc0b801b3e6e82dc
d43e9c0e9f41744cd9815bd1bc8820d8bb123f04facd1b1b685dd5a2b1b8dbbf
3ed933670f095a180b4f192d08b10b8fabbdfcc2b24518e32eea0a5e0c904ca8
44780083f3b0cd2d0b8b6af67bc355b9494025dc7b0a78fa80e3a2dbfeb51328
851d6078198e9493651ae787ec0251f922ba30e9f51df62a6d72784cf3dd2053
93176dfa324a512bd94970a36dd34a514a86791f0eb36f0145b09ab64651b4a0
313b299611a2a1c48891627598768a3114060ba4443486df51522a1ce88b3098
5c216f8e6ed178dd567b304a0d4cafba882a28342f17a9aa26ae58db630083d2
c358fdf566c3f5d62a428567bc9ea8ce95caa0f35474b0bfa8f339a250ab4dfc
f2083be8eefbc1055e18fe15370eecb260566d83ff06b211aaec43ca29b54ccd
00f8815a2465ef0b46515cc7e41f3124f09efff739309ab58b29a1459a00bce5
038e938c9678f72eb0e4ee5fdaae66d9f8573fc97fc42b4959f4bf8b61d78433
e86b0335d6e9191c4d8bf487b3905c108cfd6ac24b0ceb7dcb7cf51f84d0ed68
7b95eaeb1c533c06f0d97023d92a70825837b59ba6cb7d4e56b0a87c203862ae
8f315ba5925e8edefa679369a2202766151f16a965f9f81ece76cc070b55869e
4db9784cf05c830b3242c8312` }
    }
    [3] {
      SEQUENCE {
        SEQUENCE {
          # keyUsage
          OBJECT_IDENTIFIER { 2.5.29.15 }
          BOOLEAN { TRUE }
          OCTET_STRING {
            BIT_STRING { b`1000011` }
          }
        }
        SEQUENCE {
          # basicConstraints
          OBJECT_IDENTIFIER { 2.5.29.19 }
          BOOLEAN { TRUE }
          OCTET_STRING {
            SEQUENCE {
              BOOLEAN { TRUE }
            }
          }
        }
        SEQUENCE {
          # subjectKeyIdentifier
          OBJECT_IDENTIFIER { 2.5.29.14 }
          OCTET_STRING {
            OCTET_STRING { `329a07b1fabb48f52a309f11a1898f848e23
22ff` }
          }
        }
      }
    }
  }
  SEQUENCE {
    OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.3.17 }
  }
  BIT_STRING { `00` `67a8951fc308e12f6867611fdc254bf4bcb514f7f5f
[encoded data, 4736 characters]
beeef101f232d6e97c2c4dff3f40000000000000000000000000017263843` }
}
The following is a self-signed certificate for the ML-DSA-65 public key in the previous section. The textual encoding [RFC7468] is followed by the so-called "pretty print"; the certificates are the same.

-----BEGIN CERTIFICATE-----
[encoded data, 7360 characters]
IA==
-----END CERTIFICATE-----

SEQUENCE {
  SEQUENCE {
    [0] {
      INTEGER { 2 }
    }
    INTEGER { `159ffe6f22fd5cc42c524df6fd5e28d0de38f34e` }
    SEQUENCE {
      OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.3.18 }
    }
    SEQUENCE {
      SET {
        SEQUENCE {
          # organizationName
          OBJECT_IDENTIFIER { 2.5.4.10 }
          PrintableString { "IETF" }
        }
      }
      SET {
        SEQUENCE {
          # commonName
          OBJECT_IDENTIFIER { 2.5.4.3 }
          PrintableString { "LAMPS WG" }
        }
      }
    }
    SEQUENCE {
      UTCTime { "200203043210Z" }
      UTCTime { "400129043210Z" }
    }
    SEQUENCE {
      SET {
        SEQUENCE {
          # organizationName
          OBJECT_IDENTIFIER { 2.5.4.10 }
          PrintableString { "IETF" }
        }
      }
      SET {
        SEQUENCE {
          # commonName
          OBJECT_IDENTIFIER { 2.5.4.3 }
          PrintableString { "LAMPS WG" }
        }
      }
    }
    SEQUENCE {
      SEQUENCE {
        OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.3.18 }
      }
      BIT_STRING { `00` `48683d91978e31eb3dddb8b0473482d2b88a5f6
25949fd8f58a561e696bd4c27d05b38dbb2edf01e664efd81be1ea893688ce68
aa2d51c5958f8bbc6eb4e89ee67d2c0320954d57212cac7229ff1d6eaf03928b
d51511f8d88d847736c7de2730d5978e5410713160978867711bf5539a0bfc4c
350c2be572baf0ee2e2fb16ccfea08028d99ac49aebb75937ddce111cdab62ff
f3cea8ba2233d1e56fbc5c5a1e726de63fadd2af016b119177fa3d971a2d9277
173fce55b67745af0b7c21d597dbeb93e6a32f341c49a5a8be9e825088d1f2aa
45155d6c8ae15367e4eb003b8fdf7851071949739f9fff09023eaf45104d2a84
a45906eed4671a44dc28d27987bb55df69e9e8561f61a80a72699503865fed9b
7ee72a8e17a19c408144f4b29afef7031c3a6d8571610b42c9f421245a88f197
e16812b031159b65b9687e5b3e934c5225ae98a79ba73d2b399d73510effad19
e53b8450f0ba8fce1012fd98d260a74aaaa13fae249a006b1c34f5ba0b882f26
378222fb36f2283c243f0ffeb5f1bb414a0a70d55e3d40a56b6cbc88ae1f03b7
b2882d98deea28e145c9dedfd8eaf1cef2ed94a8b050f8964f46d1ea0d0c2a43
e0dda6182adbf4f6ed175b6742257859bf22f3a417ecf1f9d89317b5e539d587
af16b9e1313e04514ffa64ba8b3ff2b8321f8811cb3fb022c8f644e70a4b80a2
fbfee604abb7379091ea8e6c5c74dfc0283666b40c0793870028204a136bf5da
9568eb798d349038bdb0c11e03445e7847cb5069c75cf28ac601c7799d958210
ddbcb226e51afef9f1de47b073873d6d3f97456bede085082e74a298b2cd48f4
b3093155f366c8fa601c6af858dfa32c08491b2a29887f90335949a5d6edaa67
9882a3a95d6bf6d970a221f4b9d3d8cbf384af81aac95e2b3294e04789ac8372
7a5dc04559f96af41d8a053516feeeebc52746eb6ab2819e09108710d835f011
fa63065872ad334d5cdffb2b2310507e92fc993ae317da97f4f309cdaf0f67ed
99d90215576083849f953b246d7fedb3fdb67679850a5ad404e64147fb7cf4f6
aeddd05afb4b834968d1fe88014960dce5d942236526e12a478d69e5fbe69703
10b308c06845018cfc7b2ab430a13a6b1ac7bb02cccbb3d911ac2f11068613fb
e029bfdce02cf5cd38950ed72c83944edfbc75615af87f864c051f3c55456c54
12863a40c06d1dab562bdff0571b8d3c3917bbd300880bba5e998239b95fa91b
7d6416d4f398b3adbcd30983ed3592b4d9ef7d4236fd00f50d98aa53a235ac41
72720f77d96172672980cfe8ff7a5a702783edc2ba31b2259015a112fc7f468a
9c2f9464039002d30ef678b4cb798bc116216bf7a9a7c18ba03b7b58fd07515d
3115049d3614be7a07e744300750df1d2c58753389059eafc3d785ccdd31c076
48bedc03a5c3b8ad46d064d59c13d57374729fc4e295362e2a5191204530428b
c1522afa28ff5fe1655e304ca5bc8c27ad0e0c6a39dd4df28956c14b38cc9368
2cefe402bbd5e82d29c464e44eb5d37b48fc568dfe0cc6e8e16baea05e513559
0f19294e73e8367b0216dbb815030b9de55913f08039c42351c59e5515dd5af8
e089a15e625e8f6dee639386c46497d7a263288774de581a7de9629b41b44241
41f978fb8331208efdec3c6e0de39bc57063f3dcd6c470373c08891ea29cbc7c
c6d6483b8889083ace86aa7b51b1c2cfe6e2ad18d97ce36fbc56ea42fae97e6a
7ac114864478c366df1ebb1e7b11a9098504fd5975bdf1f49dc70002b63c1739
a9d263fbad4073f6a9f6c2b8af4b4c332a103a0cffa5deeb2d062ca3c215fd36
0026be7c5164f4a4424ef74948804d66f46487732c8202c795478647b4ea71d6
27c086024cca354a41f0877b38f19b3774ad2095c8da53b069e21c76ae2d2007
e16719ed40080d334f7da52e9f5a5990439caf083a95b833f02ad10a08c1a6d0
f260c007285bd4a2f47703a5aef465287d253b18ac22514316210ff566814b10
f87a293d6f199d3c3959990d0c1268b4f50d5f9fcefbbf237bd0c28b80182d66
59741f14f10bfbb21bba12ab620aa2396f56c0686b4ea9017990224216b2fe8a
d76c4a9148eef9a86a3635a6aa77bc1dcfb6fba59a77dfda9b7530dc0ca8648c
8d973738e01bab8f08b4905e84aa4641bd602410cd97520265f2f231f2b35e15
eb2fa04d2bd94d5a77abaf1e0e161010a990087f5b46ea988b2bc0512fda0fa9
23dadd6c45c5301d09483673265b5ab2e10f4ba520f6bbad564a5c3d5e27bdb0
80f7d20e13296a3181954c39c649c943ebe17df5c1f7aae0a8fe126c477585a5
d4d648a0d008b6af5e8cd31be69a9296d4f3fd25ed86f221e4b93f65f5929967
533624b9235750c30707550b58536d109a7131c5a5bbe4a5715567c12534aec7
660761eebb9fae2891c774589b80e566ad557ddef7367196b7227ea9870ef09d
dfec79d6b9319a6879b5205d76bf7aba5acf33afb59d17fc54e68383d6be5a08
e9b66da53dcde008bb294b8582bd132cdcc49959fdbc21e52721880c8ad0352c
79f03a43bbd84c4cdfdc6c529005e1e7cd9a349a7168a35569ba5dea818968d5
a91466bd6e64e20bf62417198afc4e81c28dd77ed4028232398b52fbde86bc84
f475b9016710ce2aabc11a06b4dbac901ec16cf365ca3f2d53813948a693a0f9
3e79c46ca5d5a6dca3d28ca50ad18bd13fca55059dd9b185f79f9c47196a4e81
b2104bc460a051e02f2e8444f` }
    }
    [3] {
      SEQUENCE {
        SEQUENCE {
          # keyUsage
          OBJECT_IDENTIFIER { 2.5.29.15 }
          BOOLEAN { TRUE }
          OCTET_STRING {
            BIT_STRING { b`1000011` }
          }
        }
        SEQUENCE {
          # basicConstraints
          OBJECT_IDENTIFIER { 2.5.29.19 }
          BOOLEAN { TRUE }
          OCTET_STRING {
            SEQUENCE {
              BOOLEAN { TRUE }
            }
          }
        }
        SEQUENCE {
          # subjectKeyIdentifier
          OBJECT_IDENTIFIER { 2.5.29.14 }
          OCTET_STRING {
            OCTET_STRING { `1b0563e3cd3346149c8c9ebcf23b0a4e5a90
0eea` }
          }
        }
      }
    }
  }
  SEQUENCE {
    OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.3.18 }
  }
  BIT_STRING { `00` `11816868a90c66934bdbb1d19c53a6a5dc30535ff6d
[encoded data, 6528 characters]
00000000000000000000000000000000000060d0f131c20` }
}
The following is a self-signed certificate for the ML-DSA-87 public key in the previous section. The textual encoding [RFC7468] is followed by the so-called "pretty print"; the certificates are the same.

-----BEGIN CERTIFICATE-----
[encoded data, 9920 characters]
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQMEhUdHiUs
-----END CERTIFICATE-----

SEQUENCE {
  SEQUENCE {
    [0] {
      INTEGER { 2 }
    }
    INTEGER { `159ffe6f22fd5cc42c524df6fd5e28d0de38f34e` }
    SEQUENCE {
      OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.3.19 }
    }
    SEQUENCE {
      SET {
        SEQUENCE {
          # organizationName
          OBJECT_IDENTIFIER { 2.5.4.10 }
          PrintableString { "IETF" }
        }
      }
      SET {
        SEQUENCE {
          # commonName
          OBJECT_IDENTIFIER { 2.5.4.3 }
          PrintableString { "LAMPS WG" }
        }
      }
    }
    SEQUENCE {
      UTCTime { "200203043210Z" }
      UTCTime { "400129043210Z" }
    }
    SEQUENCE {
      SET {
        SEQUENCE {
          # organizationName
          OBJECT_IDENTIFIER { 2.5.4.10 }
          PrintableString { "IETF" }
        }
      }
      SET {
        SEQUENCE {
          # commonName
          OBJECT_IDENTIFIER { 2.5.4.3 }
          PrintableString { "LAMPS WG" }
        }
      }
    }
    SEQUENCE {
      SEQUENCE {
        OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.3.19 }
      }
      BIT_STRING { `00` `9792bcec2f2430686a82fccf3c2f5ff665e771d
[encoded data, 5120 characters]
74073326b31212aece0a34a60` }
    }
    [3] {
      SEQUENCE {
        SEQUENCE {
          # keyUsage
          OBJECT_IDENTIFIER { 2.5.29.15 }
          BOOLEAN { TRUE }
          OCTET_STRING {
            BIT_STRING { b`1000011` }
          }
        }
        SEQUENCE {
          # basicConstraints
          OBJECT_IDENTIFIER { 2.5.29.19 }
          BOOLEAN { TRUE }
          OCTET_STRING {
            SEQUENCE {
              BOOLEAN { TRUE }
            }
          }
        }
        SEQUENCE {
          # subjectKeyIdentifier
          OBJECT_IDENTIFIER { 2.5.29.14 }
          OCTET_STRING {
            OCTET_STRING { `89886750b57c24db3fc012e61ede59753337
374f` }
          }
        }
      }
    }
  }
  SEQUENCE {
    OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.3.19 }
  }
  BIT_STRING { `00` `08783d565efc7b97440f8bd9818b466be538dbccedb
[encoded data, 9152 characters]
0000000000000000000000000000000000000000000040c12151d1e252c` }
}
Example Inconsistent Seed and Expanded Private Keys
WARNING: These private keys are purposely bad; do not use them in production systems.
The following examples demonstrate inconsistent seed and expanded private keys.
Three ML-DSA-44-PrivateKey examples of inconsistent seed and expanded private keys follow:
1. The first ML-DSA-PrivateKey example includes the both CHOICE , i.e., both seed and expandedKey are included. The seed and expandedKey values can be checked for inconsistencies.
2. The second ML-DSA-PrivateKey example includes only expandedKey. The public key fails to match the tr hash value in the private key.
3. The third ML-DSA-PrivateKey example also includes only expandedKey. The private s_1 and s_2 vectors imply a t vector whose private low bits do not match the t_0 vector portion of the private key (its high bits t_1 are the primary content of the public key).
The second and third examples would not be detected by implementations that do not regenerate the public key from the private key or, when they do, they neglect to check consistency of tr and t_0.
The following is the first example:

-----BEGIN PRIVATE KEY-----
MIIKPgIBADALBglghkgBZQMEAxEEggoqMIIKJgQgAAECAwQFBgcICQoLDA0ODxAR
EhMUFRYXGBkaGxwdHh8EggoAUQyb/R3XN09Oiucd1YKBEGqTQS7Y+jV/dLu0Zh7L
GSHTp1/JO4jvDmqbhRvs7BmZm+gQaMhZ1t8RXGCMFQEXDrbAVcIvYlWSSXbYlaX1
TSw4WWxAPM72+XPiKl+MfCuoNjNEcJCniyK7Qc/e2vvLLt7PkHDM5hLkKrCh8T65
3DwUkDGJwoHgsDHalISCEgijtDDSKEoEByDDRELgQC5EoHEBqSwDJmQSQSQYMiQA
Ii5KlmALGZAiMyBShkUbCEyTGIQZAG1TgAwQpChQBgogBgwjETLSxEDSEgIENIYj
lQygtkxbSJGMEoQgGQKRGIEKJRAcoGlgkCgDxjCTBJARuJAERTLBIEzawpDZiCwY
RiTKsAUjsWyKEIwEgXDLpDDYRmLBxhDIyEXBlgwEEgrkKGYcJXCcsohigGxiOEWE
gEyjoA0jBw7IRiAklSkkRgVICHATIUxghCGQsg3QNoAZgE0blmEUEIUaJkCcwIij
GBADAiGSMlGYCDIiOYpAEm4MJkEYGU4iAmTCMBFCFhJjFiwRo4TigCXSRmKakgAR
uA2LhgBRlnHIRiQIiUEDFUChIm4kNWmAJC7CiIUEMYxawIlCRI1YxgCZMpIbISDL
Am4YGXDYxiRBNnIZkGVYOG4IIAwCFCpjFoUBtCVQwmgJGVAisk3DGCokGCKbRmgQ
NUIgNmLbNAWLsmxIEIoByI0hMA6MFCZCJAQLN4xDBilCSIbYGIXIpAQUtjHRNgwi
gykAok1cuA1kiEXIAEgUOExiomjUBi7ZAg3MthFhOGTIMpJRyElSgAHgwDEAIgrB
RGaAtIRQCDASxiikCGBKsGHKxkESyGhSsHGbAAwIR2ZhGGxRFImBRoYJOUSDAjEK
kWnhIlFZRkGiBjLaBnCZMCzIJi3akpDBACDasGWCJDKDRIVcxGwAQyKJxhCjBABh
hCSjQBJRIA0YMoBBNirIsCkgRwgaEkTDtpEiKYzYMmbDlhBiJnIbRWXDpmXZwGAU
EAjQxG1JMoXQBg0RJEzjtAABqUUAM4BCMGBKgEmCNCBDGAgSBiaSRILKMAHhNo5b
IiIkBwZUEIlLoEGYRgpMFEoKNIQgI07AFgUDRiyAtkEUkzHLJgARmG0KEg7YEGKQ
NgwUAXGJBirIJmZSBFHkBkDckiHIEHFkGC7kuABSkGiLqChLJEkRJoGZiJFUNg0K
mIG8aRx5dr9/gBkPfhwZrwn4DSmTPr/Vn01JddemyttdtkeLCZ4DW7+GKb7Z8S4f
HY7JlsvtetEEMyRAS8/INLBzTBrGWIRQqWxf3YcrxGG51NDOlvdrYH7wnySOku6m
N12BMMwLEfKkmOSU747o81iHE+wiM2bPH+rG7eP6rIrB7NRY67odfeBGboLHeSdf
79U3GOWczZiFB5wtZGzNoVpiExABNAydQC4OJIPvpxR0ULrErVz9y33/zj9KIZJy
+saqdCSssuX3kbavVhZQz7eytus2Aji7uSWgPb4M7FqBoFcpobHX/jVvHD8oaBt2
TOjtuObFujQUnDcztr62etukrM+IwyyLR4WCpFev9qGM+ZP9TCsLbEDu/rVMVS81
dnKlkkYhy/pUgsGU2jg1bTD83Wib8laAlKZgXSqLBsyP2hpmU66+mX/2gQR9rCzh
gJSFDfiIGPo1nU2yelQMJ8YOniHNv8I5ZRKylmRFpDZo+QPVoXMnwTg0eF/c3UCO
PTc59SFlUpxMSPttjYLHEnPlqJnHLb/PZMWlqfd+FE+i4GfHfKDH6RF3NUjPY0Jx
I1EJ5l/HxG+zK4c1abd6LU4fMGnnKrNKlNSF5yoq8b68GIspz/Mnni3Z8++arXx/
hzMVayoTe6vtL0ZtyByyV26jjrxOEMpf0ZLzjkWB+Q9a+Z6QxEcTtpVlsOhnxB9w
cWFz1hzdOz1ZaMv89k3iYgajdmNIHeUQdz8wwc1621onspo5YlzuruFSorrzz/Ru
yyg3iHNFmRv2SCNuWcziAFTSd8HBtInzNWmeqBeF7HW1hsCpRoR02ZV4iM+REFrj
qPVHh3zqURGGSdu1y29uK6M2vjUp0w8NfyuvzbHIy2hJz3Py9kiZotfF4kOgU25D
11b+/IcaVavqBxCUAz9N4c29aBGZO8reC+X9kPWuNE8NY7e3j4YmPcWppZGfXnY9
PNV0pLyhLeifev2Wk1ahcLVYLE6l/cFE6qxmThkD8uTrZ7h75JmUqDmKNVjtJW5N
YS5XSZQz4bFhsdXvpED5F5jwr2NUPpZZDkjuEKXu81ll14F4wx98g776d6LI/zTY
a06arDBhDhmeyDQZFhMtlu575XeFZGdP11IVo4UPSCQKzc/AMxlrjNrQw2wNZJ+t
6JDEJq75MS7q5C7gvPpBd3qdmbNQwLFvyCj8ohXcpqc1Lgw12BFNtm5L2JXXle/7
QmhVrMEkSwJznkd+bOqky9uPbI1Nr1fw0+NJBeqCJtxVvjngV3rE97E1RqzHFxaH
QQvju+iK/j03mKXQes6be6UWIrYz8+RhZ4jwlK2nPDklHM0+0p2sNlha3BYl+Fob
uXxZug5ze+Lor7aiIiy18xn64MxZ4QBP3pFpKeW3YJKoLcJSexuJlKJ8Ky5WjnJ+
skZeuWRgmW/OYyRcKyyylrgnWv0A2oyBqe8ujjv5MD2Oi1Oq/mxtA+a8IAQ0oqOL
F00uc91QcXXoUdXnQ+ZCCeNIUg1shMyx+2v6smyMLuSFEQ3R17Br1Sgw6lu2gD0S
XMYOX6h8w0Ww9ml1Huth5xm21mYiPLiejT3vPOyWrJNQ7pg4l/0VGBTG+1zaN5fo
paZzqkJijn+EH7d+G8RVLGhU0gkbplrNqDAIHAiCnO76b3CuBam2ngtjQzBPUlSU
AqXPtG17rJg2B+fzgPKAgh8vuZLEaXP7/XeNMwNe6QsNuU9gfln7Tt+pqYpwm1gH
Wkqor1xYXy+1md2Ct3tLbznupLFIfQ3NVBkeDW+NVvpPvC+CF/NefkSuzOaBPlTa
itxMHENeGFxR5cf0Sp43j59iGKdWBtJBCV8uWf4qRgRG8fdbfQ+l1qAJEx4v8r4H
2Hsm6eS/CeZlEpe9fnobwS1BBNoczKSL+noqpxcmgAjbcEtZtsBXSJVBsj4OCdt3
fA/6IfpWRsNBIVR1aD2p/a0U/RH3FCZKDhwF2ZhBLeHEWWQOCr1v0W68/rllFuIW
YcyqOojDEup7oFhc0k4aUwdv50HJAWk3ehaPvbP+zlz84DmyVMQjXYJl9gZShi+9
tFV4KJ8aZz/kCdufmWwtLJKHIBuVkX/hqbYO8Xg4XyWv2pZpZIGeW779l8wQE1MI
2Yt6grThI3sytb+dM3JvqUW79clvJ288BqRZMJSNO2vUIo4vPqyM/Wcuy465qS0V
ns+zr0zC2uo3z3LqK57arYABNRm8CV2VxaOqH61GvYyUrA==
-----END PRIVATE KEY-----
The following is the second example:

-----BEGIN PRIVATE KEY-----
MIIKGAIBADALBglghkgBZQMEAxEEggoEBIIKANeytHJUquDbReeTDUqY0sl9jxOX
0Xidr6FwJLMW6b7JOc4Pf3f421ZE3No2a/5HNL2V9DX/mmE6pUqkHCxpTAQzmgex
+rtI9SownxGhiY+EjiMi/+Yj7IENs77jNoWFSogmnaMg1RIL/P6JoY4w9xFNg6pA
SmRrbJlziYYNElIu4ABuI4SBkYZhmyYNEYZk1KYoIhhEgkAomBRhSKZhTEJIoZII
wjgpUSRICKElwggxCMRxIBQJFINsGKeAhBBuycBwIrVkCLBhDAcEmBJEUYhpWQBG
IpMgQQYuQrZMARZJFChMQahRgEYKURZRWgggAiJE3JhJ0TJR4TBl08CFkqhREqFk
ADkiCUZiHMcM2Qht0AYmUkCFgEQwkQYsUMgJJMWEGpZtSpgsmQZtpEQyIKdkWjJu
EbVwIJJhJBOOBIUsCkhyyKBR0wgqmSCAWCQgJAdOWRSIEKRkYMBt4LKNGxkJIDQi
wCRBCUNxCiEgYaIBUiJSG4CAmjQAE5NN0zIpIhcKmJJpGhRRICchnMAgYqKBSBhp
GoVNg0RpWyBBAxJCyxhGAakNDAIxg7AhWiJKyJIF2ZBpBDBqSwZK0rIBHEBAgUIy
UjJyVKZAWhgQDDISksKAUhJiXIIoC7RsA0KNUxAMFAEO4TZSiIQkkQIKY0YmIAYp
EcIo0CBIArNsojYJWoZIy7Rhi0ZixECCGokJEAJNJLJFIBIlJMkFiCiMycBNWUgi
CiduwTRkTJBgW0RQgoZJQ4gEQ7KMYDCAoogthKRtjKYp0MaEQgZGiYhRAKmNAUmN
5DgNpAaN05RxQrJsGoRhG6MoQrQoCKBxGsUx4KBMATdlJChiFCiQCRBh2UAiGzNg
CQKS0CSBIAQISRhEoyItXIhEFJgIpEZhAZVkCzkKDJRQykBq0rIgwDgBgjCOE7kI
kYCEFIgpwBiREjUNoCQi4gQG2cKFBCgSHMmJGAJy0kApwggS2AYqmZRxm7hoI4Qp
GiKJFEUR3IJEUJZFDESEwLIEmqYFQ4YsRDJuiEQhIKhMmjBw47gtYyaIAyVJA0OM
SKgJyhRyUzROEkMIG6cEWTAi2ZSA4jQigUISnDAqlDQmYQRFJCYoE0YJSjJtESgJ
GLglYigRE0ENQbIRkIRMixISosaIycAwIgYG0hiOhIYwkERSEogx2SBxE8UoQwYO
AzBgzKaEWCZSTIgBHvclYshf+kOs+kkhfysXLXu8FGIObZgKcaq73wxF6aIG7LFC
P+4V3swXYBMAFJ2SI81ubG4fqOQfx8ZJOKtokF/T3NpQ2HCC59DXHRvJsrhMhVI8
qP5srSlK34O+FbEI/3IdDMh7w906dZAYSw6EVmOpH8nhw8U6YdhnQgsE8JI1V1O8
ZaBjaP1BKV/QmSQTLG+R9nlkwUJnSnJcNDkUxM7PWMB0vK9FWMl795EeB6ptCTjy
7iuzwajFldY16ENC/eoB3CSyEa0vwoHPd+WREMerxUvwyG1IC5vidkcdydYDzumM
/as+n8+3A3k1YFSepEUPp7M/uRacRLTSX7nEV/SXkc09oD6slglYE8EFEyzNpOY+
SSKM0j2KHzeFbxQtk7kNsJ+Cr4kljGOquAR6gMA2yTV+ogRvjcY1TwxSlfNCu0F9
PP6wsf0zYiwp4Uy72S4TY8ZevUUEt1EjKblnDjLhssZ6VOfxpV+Ln56gToyjpwXm
KjxeY3N0r7eutt3qYSzeKPAaIC16pONHItJ90/m4mJTQGf1dTXEZ7+NyO7oQTLi7
CYHgdN46/iANqq6tgmzEXyRNv0Ma+rNO+994JHTS/VcRj2RiFJNO2Zy6OwA+jWej
g29vGfxBkQzlFj7jrpnrhNUU63YeY2hOpW+XkdLdSqxuYWi5SMgX91oiKssOjNwD
zEr+j2cVfho2O3+u/58XK5iRNnfFod0IXp7kwiBSwa9YGTEWZz3NO/xfNLhV3MbH
eIVknp5x9D1K6g9Lcsp+2gV4uhPTGmWNLQYKmmb/ae0b55l6L7HScj04+b+r4Y+O
ezzakG5Om16ULI6uspYHDr/TZJR6lAzJeL7Wazd0nm1dzXvoxJREDiuEzs/vuYwL
7fs8QeM1nSzXGX++cgxIqmxrZGXB7mPjVpwq3HREkTcLf3gm/gt3odGdZBAdAyuR
gQa0LS73N0flYB/kulDyPt5SHwMagX0VKUpDci6DeHhLbbDPG6norpEdkgG5zpzD
AZxvXCfLmNomFEtkIlp8kysw92Hnii1Zodi4PsY0Si9t1H52VwbQC/SnmmqSbDup
HYEsjyx5erF5Zwnl0WhWd4KTUp8ChtAVw7U5lhlkKjM+nlk9bj9TU5lCCOnmozKF
HX9lJSKpKLkX4n4tbUITff4uv6b7HGeybAJUUoaF9+vb4xWmjqotp2noqfQtPmAA
fHEzCSaywAEtg+rU5P0e2HLM0ZciAdKwJ/NUWsLTDNeLwddA/sy8b8KgRGxuMOrF
H1ppCYqi1EfyCFtOTkuSzMJpIdLeR4UYzQkM4meuotJ62lf9iLSXbYn7hDzcz0mn
bKJnnmgBv6f7AxiW+1BilwS5kjk2u13ThTERIcrfsRmV5ZtzA0z2ftA6uBOGdkjQ
JYKAh+lJqa/Ra5XXLZmx7coleqwTL/t6Bwmu1anA/wX7Dyu/KECe7XtfWAG+lkzt
AZ4ct4UdOFHxApBnThn/sAizAcSs9kGiuxQhbh1pyr9Ste8idJaw8weZqFXRF/rT
dEpvozUD6nmLUt3X7lQmYJ2/zT8ME7Fk1sBR9+1KEZcZpxLjiNMoQCCB/xNUtVTS
wjev7TsVHEuo6fS964SZowZuJrvGnorwid7HFzHR3FKeqxfvc3RzTA/kdUlMg4Nr
3TSgO5vImRRxYGG/uY7G5hw+1EOO3K8lJDxkcIa56nAYsNmooLAM7LAKveJJjWnC
M2EBp3LL5PVxUj9RvQWILN81i4ScwUCqH68iQjoShRzg4z/UiXWklZ+lxf5BjJOQ
gZGrbnQbd7/gLL1pjueVxGbWFWGeZEE4LG6sAYNO6atzzqgLviNceNqRvXm2+C+J
l4XWhwDTk+Z1wiJNa3oa0hMgSVZ5ra7XAWe1CGZxOlMQnbe299gTBOzf2Dsxmx7y
SDBrRa0p593Mhj2sVgSLXWnqF1AR92FMAKhqhjzeGHKokyh4uax+GsW9pJl7cgZP
DNdfTIFOA03hGsuQE89+qSa05+qs4HDHuiGI760uQx4SI9Rd0FxNhAPC5FzuZBPs
vnUn6HPkVcTmEKYYOarMC9VtJIPnjymLZqR46y9VjLr8qGvoR7rrAsWyFsjNiP6k
3ySbCeZwogcDq6wksKkavEpWRmAUQroQvs/TCZOIAFHQf1agWpN556jmvv7j8i+q
EGOY93BgBuQum+HvidJcJy8RqVCVxYfXE3MihN6dvTxyF7BoniHY6w/2lmg=
-----END PRIVATE KEY-----
The following is the third example:

-----BEGIN PRIVATE KEY-----
MIIKGAIBADALBglghkgBZQMEAxEEggoEBIIKANeytHJUquDbReeTDUqY0sl9jxOX
0Xidr6FwJLMW6b7JOc4Pf3f421ZE3No2a/5HNL2V9DX/mmE6pUqkHCxpTAQymgex
+rtI9SownxGhiY+EjiMi/+Yj7IENs77jNoWFSogmnaMg1RIL/P6JoY4w9xFNg6pA
SmRrbJlziYYNElIu4ABuI4SBkYZhmyYNEYZk1KYoIhhEgkAomBRhSKZhTEJIoZII
wjgpUSRICKElwggxCMRxIBQJFINsGKeAhBBuycBwIrVkCLBhDAcEmBJEUYhpWQBG
IpMgQQYuQrZMARZJFChMQahRgEYKURZRWgggAiJE3JhJ0TJR4TBl08CFkqhREqFk
ADkiCUZiHMcM2Qht0AYmUkCFgEQwkQYsUMgJJMWEGpZtSpgsmQZtpEQyIKdkWjJu
EbVwIJJhJBOOBIUsCkhyyKBR0wgqmSCAWCQgJAdOWRSIEKRkYMBt4LKNGxkJIDQi
wCRBCUNxCiEgYaIBUiJSG4CAmjQAE5NN0zIpIhcKmJJpGhRRICchnMAgYqKBSBhp
GoVNg0RpWyBBAxJCyxhGAakNDAIxg7AhWiJKyJIF2ZBpBDBqSwZK0rIBHEBAgUIy
UjJyVKZAWhgQDDISksKAUhJiXIIoC7RsA0KNUxAMFAEO4TZSiIQkkQIKY0YmIAYp
EcIo0CBIArNsojYJWoZIy7Rhi0ZixECCGokJEAJNJLJFIBIlJMkFiCiMycBNWUgi
CiduwTRkTJBgW0RQgoZJQ4gEQ7KMYDCAoogthKRtjKYp0MaEQgZGiYhRAKmNAUmN
5DgNpAaN05RxQrJsGoRhG6MoQrQoCKBxGsUx4KBMATdlJChiFCiQCRBh2UAiGzNg
CQKS0CSBIAQISRhEoyItXIhEFJgIpEZhAZVkCzkKDJRQykBq0rIgwDgBgjCOE7kI
kYCEFIgpwBiREjUNoCQi4gQG2cKFBCgSHMmJGAJy0kApwggS2AYqmZRxm7hoI4Qp
GiKJFEUR3IJEUJZFDESEwLIEmqYFQ4YsRDJuiEQhIKhMmjBw47gtYyaIAyVJA0OM
SKgJyhRyUzROEkMIG6cEWTAi2ZSA4jQigUISnDAqlDQmYQRFJCYoE0YJSjJtESgJ
GLglYigRE0ENQbIRkIRMixISosaIycAwIgYG0hiOhIYwkERSEogx2SBxE8UoQwYO
AzBgzKaEWCZSTIgBH/clYshf+kOs+kkhfysXLXu8FGIObZgKcaq73wxF6aIG7LFC
P+4V3swXYBMAFJ2SI81ubG4fqOQfx8ZJOKtokF/T3NpQ2HCC59DXHRvJsrhMhVI8
qP5srSlK34O+FbEI/3IdDMh7w906dZAYSw6EVmOpH8nhw8U6YdhnQgsE8JI1V1O8
ZaBjaP1BKV/QmSQTLG+R9nlkwUJnSnJcNDkUxM7PWMB0vK9FWMl795EeB6ptCTjy
7iuzwajFldY16ENC/eoB3CSyEa0vwoHPd+WREMerxUvwyG1IC5vidkcdydYDzumM
/as+n8+3A3k1YFSepEUPp7M/uRacRLTSX7nEV/SXkc09oD6slglYE8EFEyzNpOY+
SSKM0j2KHzeFbxQtk7kNsJ+Cr4kljGOquAR6gMA2yTV+ogRvjcY1TwxSlfNCu0F9
PP6wsf0zYiwp4Uy72S4TY8ZevUUEt1EjKblnDjLhssZ6VOfxpV+Ln56gToyjpwXm
KjxeY3N0r7eutt3qYSzeKPAaIC16pONHItJ90/m4mJTQGf1dTXEZ7+NyO7oQTLi7
CYHgdN46/iANqq6tgmzEXyRNv0Ma+rNO+994JHTS/VcRj2RiFJNO2Zy6OwA+jWej
g29vGfxBkQzlFj7jrpnrhNUU63YeY2hOpW+XkdLdSqxuYWi5SMgX91oiKssOjNwD
zEr+j2cVfho2O3+u/58XK5iRNnfFod0IXp7kwiBSwa9YGTEWZz3NO/xfNLhV3MbH
eIVknp5x9D1K6g9Lcsp+2gV4uhPTGmWNLQYKmmb/ae0b55l6L7HScj04+b+r4Y+O
ezzakG5Om16ULI6uspYHDr/TZJR6lAzJeL7Wazd0nm1dzXvoxJREDiuEzs/vuYwL
7fs8QeM1nSzXGX++cgxIqmxrZGXB7mPjVpwq3HREkTcLf3gm/gt3odGdZBAdAyuR
gQa0LS73N0flYB/kulDyPt5SHwMagX0VKUpDci6DeHhLbbDPG6norpEdkgG5zpzD
AZxvXCfLmNomFEtkIlp8kysw92Hnii1Zodi4PsY0Si9t1H52VwbQC/SnmmqSbDup
HYEsjyx5erF5Zwnl0WhWd4KTUp8ChtAVw7U5lhlkKjM+nlk9bj9TU5lCCOnmozKF
HX9lJSKpKLkX4n4tbUITff4uv6b7HGeybAJUUoaF9+vb4xWmjqotp2noqfQtPmAA
fHEzCSaywAEtg+rU5P0e2HLM0ZciAdKwJ/NUWsLTDNeLwddA/sy8b8KgRGxuMOrF
H1ppCYqi1EfyCFtOTkuSzMJpIdLeR4UYzQkM4meuotJ62lf9iLSXbYn7hDzcz0mn
bKJnnmgBv6f7AxiW+1BilwS5kjk2u13ThTERIcrfsRmV5ZtzA0z2ftA6uBOGdkjQ
JYKAh+lJqa/Ra5XXLZmx7coleqwTL/t6Bwmu1anA/wX7Dyu/KECe7XtfWAG+lkzt
AZ4ct4UdOFHxApBnThn/sAizAcSs9kGiuxQhbh1pyr9Ste8idJaw8weZqFXRF/rT
dEpvozUD6nmLUt3X7lQmYJ2/zT8ME7Fk1sBR9+1KEZcZpxLjiNMoQCCB/xNUtVTS
wjev7TsVHEuo6fS964SZowZuJrvGnorwid7HFzHR3FKeqxfvc3RzTA/kdUlMg4Nr
3TSgO5vImRRxYGG/uY7G5hw+1EOO3K8lJDxkcIa56nAYsNmooLAM7LAKveJJjWnC
M2EBp3LL5PVxUj9RvQWILN81i4ScwUCqH68iQjoShRzg4z/UiXWklZ+lxf5BjJOQ
gZGrbnQbd7/gLL1pjueVxGbWFWGeZEE4LG6sAYNO6atzzqgLviNceNqRvXm2+C+J
l4XWhwDTk+Z1wiJNa3oa0hMgSVZ5ra7XAWe1CGZxOlMQnbe299gTBOzf2Dsxmx7y
SDBrRa0p593Mhj2sVgSLXWnqF1AR92FMAKhqhjzeGHKokyh4uax+GsW9pJl7cgZP
DNdfTIFOA03hGsuQE89+qSa05+qs4HDHuiGI760uQx4SI9Rd0FxNhAPC5FzuZBPs
vnUn6HPkVcTmEKYYOarMC9VtJIPnjymLZqR46y9VjLr8qGvoR7rrAsWyFsjNiP6k
3ySbCeZwogcDq6wksKkavEpWRmAUQroQvs/TCZOIAFHQf1agWpN556jmvv7j8i+q
EGOY93BgBuQum+HvidJcJy8RqVCVxYfXE3MihN6dvTxyF7BoniHY6w/2lmg=
-----END PRIVATE KEY-----
Pre-Hashing (Externalμ-ML-DSA)
Some applications require pre-hashing that ease operational requirements around large or inconsistently-sized payloads. When signing with pre-hashing, the signature-generation process can be separated into a pre-hash step requiring only the message and other public information, and a core signature step that uses the public key.
In the context of ML-DSA, pre-hashing can be performed with the HashML-DSA algorithm defined in Section 5.4 of [FIPS204]. ML-DSA itself supports an External μ pre-hashing mode, which externalizes the message pre-hashing originally performed inside the signing operation. This mode is also laid out in [FIPS204-ExternalMuFAQ]. This document specifies only the use of ML-DSA's External μ mode, and not HashML-DSA, in PKIX for reasons laid out in Section 8.3.
Implementations of ML-DSA using the External μ pre-hashing mode requires the following algorithms, which are modified versions of the algorithms presented in [FIPS204]. The nomenclature used here has been modified from the NIST FAQ [FIPS204-ExternalMuFAQ] for clarity.
Pre-hash operation:
Computeμ Pre-Hash Operation

Computeμ(pk, M, ctx):

  # Referred to as 'ExternalMu-ML-DSA.Prehash(pk, M, ctx)'
  # in the FIPS 204 FAQ.
  # M is the message, a bit-string
  # μ and ctx are byte-strings.
  # ctx is the context string, which defaults to the empty string.

  μ = H(BytesToBits(H(pk, 64) || IntegerToBytes(0, 1) ||
                IntegerToBytes(|ctx|, 1) || ctx) || M, 64)
  # The functions `BytesToBits` and `IntegerToBytes` are defined
  # in FIPS 204.
  return μ
Sign operations:
The Operations for Signing μ
Signμ(sk, μ):

  # Referred to as 'ExternalMu-ML-DSA.Sign(sk, mu)'
  # in the FIPS 204 FAQ.

  if |μ| != 64 then
    return error  # return an error indication if the input μ is not
                  # 64 bytes.
  end if

  rnd = rand(32)  # for the optional deterministic variant,
                  # set rnd to all zeroes
  if rnd = NULL then
    return error  # return an error indication if random bit
                  # generation failed
  end if

  sigma = Signμ_internal(sk, μ, rnd, isExternalμ=true)
  return sigma

ML-DSA.Signμ_internal(sk, M', rnd, isExternalμ=false):
    # μ is passed to the function via the argument M'.
    # Defaulting Externalμ to false means that
    # this modified version of Sign_internal can be used
    # in place of the original without interfering with
    # functioning of pure ML-DSA mode.

    # ... identical to FIPS 204 Algorithm 7, but with Line 6
    # replaced with
  6: if (isExternalμ):
       μ = M'
     else:
       μ = H(BytesToBits(tr) || M', 64)
There is no need to specify an External μ Verify() routine because this is identical to the original ML-DSA.Verify(). This makes External μ mode simply an internal optimization of the signer, and allows an ML-DSA key to sometimes be used with the "one-shot" Sign() API and to sometimes be used with the External μ API without any interoperability concerns.
The External μ mode requires the Computeμ routine to have access to the hash of the signer's public key, which may not be available in some architectures, or require fetching it. That may allow for mismatches between tr and sk. At worst, this will produce a signature that will fail to verify under the intended public key since a compliant Verify() routine will independently compute tr from the public key. This is not believed to be a security concern since μ is never used as-is within ML-DSA.Sign_internal() (Algorithm 7 in [FIPS204]). Rather, it is hashed with values unknown to an attacker on lines 7 and 15. Thus, a signing oracle exposing Signμ() does not leak any bits of the secret key. The External μ mode also requires SHAKE256 to be available to the Computeμ routine.
Acknowledgments
The authors wish to thank the following people for their contributions to this document: Corey Bonnell, Deirdre Connolly, Viktor Dukhovni, Russ Housley, Alicja Kario, Mike Ounsworth, and Daniel Van Geest.
In addition, we would like to thank those who contributed to the private key format discussion: Tony Arcieri, Bob Beck, Dmitry Belyavskiy, David Benjamin, Daniel Bernstein, Uri Blumenthal, Theo Buehler, Stephen Farrell, Jean-Pierre Fiset, Scott Fluhrer, Alex Gaynor, John Gray, Peter Gutmann, David Hook, Tim Hudson, Paul Kehrer, John Kemp, Watson Ladd, Adam Langley, John Mattsson, Damien Miller, Robert Relyea, Michael Richardson, Markku-Juhani O. Saarinen, Rich Salz, Roland Shoemaker, Sophie Schmieg, Simo Sorce, Michael St. Johns, Falko Strenzke, Filippo Valsorda, Loganaden Velvindron, Carl Wallace, and Wei-Jun Wang.
Authors' Addresses
Jake Massimo
AWS
United States of America
jakemas@amazon.com
Panos Kampanakis
AWS
United States of America
kpanos@amazon.com
Sean Turner
sn3rd
sean@sn3rd.com
Bas Westerbaan
Cloudflare
bas@cloudflare.com