Internet X.509 Public Key Infrastructure: Algorithm Identifiers for ML-DSA

Internet-Draft	ML-DSA in Certificates	January 2025
Massimo, et al.	Expires 19 July 2025	[Page]

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 19 July 2025.¶

Copyright Notice

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.¶

1. 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: a pure and a prehash variant. Only the former is specified in this document. See Section 8.1 for the rationale. The pure variant of ML-DSA supports the typical prehash flow, see Appendix D. In short: one cryptographic module can compute the hash mu on line 6 of algorithm 7 of [FIPS204] and pass it to a second module to finish the signature. The first module only needs access to the full message and the public key, whereas the second module only needs access to hash mu and the private key.¶

Prior to standardisation, ML-DSA was known as Dilithium. ML-DSA and Dilithium are not compatible.¶

1.1. 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.¶

2. 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
     }

The fields in AlgorithmIdentifier have the following meanings:¶

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

The OIDs are:¶

   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. The ctx value used in the ML-DSA signing and verification [FIPS204] of ML-DSA signatures defined in this specification (X.509 certificates, CRLs) is the empty string.¶

3. 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 representation from [RFC5280] below, in an X.509 certificate, a signature is encoded with an algorithm identifier in the signatureAlgorithm attribute and a signatureValue attribute that contains the actual signature.¶

  Certificate  ::=  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 representation from [RFC5280] below. In a X.509 CRL, a signature is encoded with an algorithm identifier in the signatureAlgorithm attribute and a signatureValue attribute that contains the actual signature.¶

   CertificateList  ::=  SIGNED{ TBSCertList }

The identifiers defined in Section 2 can be used as the AlgorithmIdentifier in the signatureAlgorithm field in the sequence Certificate/CertificateList and the signature field in the sequence TBSCertificate/TBSCertList in certificates and CRLs, respectively, [RFC5280]. The parameters of these signature algorithms MUST be absent, as explained in Section 2. That is, the AlgorithmIdentifier SHALL be a SEQUENCE of one component, the OID id-ml-dsa-*.¶

The signatureValue field contains the corresponding ML-DSA signature computed upon the ASN.1 DER encoded tbsCertificate/tbsCertList [RFC5280].¶

Conforming Certification Authority (CA) implementations MUST specify the algorithms explicitly by using the OIDs specified in Section 2 when encoding ML-DSA signatures in certificates and CRLs. Conforming client implementations that process certificates and CRLs using ML-DSA MUST recognize the corresponding OIDs. Encoding rules for ML-DSA signature values are specified Section 2.¶

4. 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
  }

The fields in SubjectPublicKeyInfo have the following meaning:¶

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

[I-D.ietf-lamps-cms-ml-dsa] defines the following public key identifiers for ML-DSA:¶

  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 no ASN.1 wrapping -- }

  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 no ASN.1 wrapping -- }

  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 no ASN.1 wrapping -- }

  ML-DSA-PublicKey ::= OCTET STRING (SIZE (1312 | 1952 | 2592))

  ML-DSA-PrivateKey ::= OCTET STRING (SIZE (32))

An ML-DSA public key is encoded in an X.509 certificate's SubjectPublicKeyInfo type as described in Section 3 of [I-D.ietf-lamps-cms-ml-dsa].¶

Section 3 of [I-D.ietf-lamps-cms-ml-dsa] also defines the ML-DSA-Public and ML-DSA-PrivateKey for when the ML-DSA pubic key appears outside of a SubjectPublicKeyInfo type and for when the ML-DSA private key appears outside of an Asymmetric Key Package [RFC5958], respectively.¶

Appendix C contains example ML-DSA public keys encoded using the textual encoding defined in [RFC7468].¶

5. 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 indicates id-ml-dsa-* in the SubjectPublicKeyInfo, then the at least one of following MUST be present:¶

  digitalSignature; or
  nonRepudiation; or
  keyCertSign; or
  cRLSign.

If the keyUsage extension is present in a certificate that indicates id-ml-dsa-* in the SubjectPublicKeyInfo, then the following MUST NOT be present:¶

   keyEncipherment; or
   dataEncipherment; or
   keyAgreement; or
   encipherOnly; or
   decipherOnly.

Requirements about the keyUsage extension bits defined in [RFC5280] still apply.¶

6. Private Key Format

An ML-DSA private key is encoded by storing its 32-octet seed in the privateKey field as follows.¶

[FIPS204] specifies two formats for an ML-DSA private key: a 32-octet seed (xi) and an (expanded) private key. The expanded private key (and public key) is computed from the seed using ML-DSA.KeyGen_internal(xi) (algorithm 6).¶

"Asymmetric Key Packages" [RFC5958] describes how to encode a private key in a structure that both identifies what algorithm the private key is for and allows for the public key and additional attributes about the key to be included as well. For illustration, the ASN.1 structure OneAsymmetricKey is replicated below.¶

  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,
    ...
  }

When used in a OneAsymmetricKey type, the privateKey OCTET STRING contains the raw octet string encoding of the 32-octet seed. The publicKey field SHOULD be omitted because the public key can be computed as noted earlier in this section.¶

Appendix C contains example ML-DSA private keys encoded using the textual encoding defined in [RFC7468].¶

7. IANA Considerations

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

8. Security Considerations

The Security Considerations section of [RFC5280] applies to this specification as well.¶

The digital signature scheme defined within this document are modeled under strongly existentially unforgeable under chosen message attack (SUF-CMA). For the purpose of estimating security strength, it has been assumed that the attacker has access to signatures for no more than 2^{64} chosen messages.¶

ML-DSA offers both deterministic and randomized signing. By default ML-DSA signatures are non-deterministic. The private random seed (rho') for the signature is pseudorandomly derived from the signer’s private key, the message, and a 256-bit string, rnd - where rnd should be generated by an approved RBG. In the deterministic version, rng is instead a 256-bit constant string. The source of randomness in the randomized mode has been "hedged" against sources of poor entropy, by including the signers private key and message into the derivation. The primary purpose of rnd is to facilitate countermeasures to side-channel attacks and fault attacks on deterministic signatures.¶

In the design of ML-DSA, care has been taken to make side-channel resilience easier to achieve. For instance, ML-DSA does not depend on Gaussian sampling. Implementations must still take great care not to leak information via various side channels. While deliberate design decisions such as these can help to deliver a greater ease of secure implementation - particularly against side-channel attacks - it does not necessarily provide resistance to more powerful attacks such as differential power analysis. Some amount of side-channel leakage has been demonstrated in parts of the signing algorithm (specifically the bit-unpacking function), from which a demonstration of key recovery has been made over a large sample of signatures. Masking countermeasures exist for ML-DSA, but come with a performance overhead.¶

A fundamental security property also associated with digital signatures is non-repudiation. Non-repudiation refers to the assurance that the owner of a signature key pair that was capable of generating an existing signature corresponding to certain data cannot convincingly deny having signed the data. The digital signature scheme ML-DSA possess three security properties beyond unforgeability, that are associated with non-repudiation. These are exclusive ownership, message-bound signatures, and non-resignability. These properties are based tightly on the assumed collision resistance of the hash function used (in this case SHAKE-256).¶

Exclusive ownership is a property in which a signature sigma uniquely determines the public key and message for which it is valid. Message-bound signatures is the property that a valid signature uniquely determines the message for which it is valid, but not necessarily the public key. Non-resignability is the property in which one cannot produce a valid signature under another key given a signature sigma for some unknown message m. These properties are not provided by classical signature schemes such as DSA or ECDSA, and have led to a variety of attacks such as Duplicate-Signature Key Selection (DSKS) attacks , and attacks on the protocols for secure routing. A full discussion of these properties in ML-DSA can be found at [CDFFJ21].¶

These properties are dependent, in part, on unambiguous public key serialization. It for this reason the public key structure defined in Section 4 is intentionally encoded as a single OCTET STRING.¶

8.1. 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 (e.g. TLS). The use of HashML-DSA public keys within end entity certificates is not prohibited, but conventions for doing so are outside the scope of this document.¶

This restriction is for both implementation and security reasons.¶

The implementation reason for disallowing HashML-DSA stems from the fact that ML-DSA and HashML-DSA are incompatible algorithms that require different Verify() routines. This forwards to the protocol the complexity of informing the client whether to use ML-DSA.Verify() or HashML-DSA.Verify() along with the hash algorithm to use. Additionally, since the same OIDs are used to identify the ML-DSA public keys and ML-DSA signature algorithms, an implementation would need to commit a given public key to be either of type ML-DSA or HashML-DSA at the time of certificate creation. This is anticipated to cause operational issues in contexts where the operator does not know at key generation time whether the key will need to produce pure or pre-hashed signatures. ExternalMu-ML-DSA avoids all of these operational concerns by virtue of having keys and signatures that are indistinguishable from ML-DSA (i.e., ML-DSA and ExternalMu-ML-DSA are mathematically equivalent algorithms). The difference between ML-DSA and ExternalMu-ML-DSA is merely an internal implementation detail of the signer and has no impact on the verifier or network protocol.¶

The security reason for disallowing HashML-DSA is that the design of the ML-DSA algorithm provides enhanced resistance against signature collision attacks, compared with conventional RSA or ECDSA signature algorithms. Specifically, ML-DSA binds the hash of the public key tr to the message to-be-signed prior to hashing, as described in line 6 of Algorithm 7 of [FIPS204]. In practice, this provides binding to the indended verification public key, preventing some attacks that would otherwise allow a signature to be successfully verified against a non-intended public key. Also, this unlikely, theoretical binding means that in the unlikely discovery of a collision attack against SHA-3, an attacker would have to perform a public-key-specific collision search in order to find message pairs such that H(tr || m1) = H(tr || m2) since a direct hash collision H(m1) = H(m2) will not suffice. HashML-DSA removes both of these enhanced security properties.¶

9. References

9.1. Normative References

[FIPS204]: National Institute of Standards and Technology (NIST), "Module-Lattice-based Digital Signature Standard", FIPS PUB 204, August 2023, <https://csrc.nist.gov/projects/post-quantum-cryptography>.
[I-D.ietf-lamps-cms-ml-dsa]: S, B., R, A., and D. Van Geest, "Use of the ML-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS)", Work in Progress, Internet-Draft, draft-ietf-lamps-cms-ml-dsa-01, 22 November 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-ml-dsa-01>.
[RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC5280]: Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/rfc/rfc5280>.
[RFC5912]: Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10.17487/RFC5912, June 2010, <https://www.rfc-editor.org/rfc/rfc5912>.
[RFC5958]: Turner, S., "Asymmetric Key Packages", RFC 5958, DOI 10.17487/RFC5958, August 2010, <https://www.rfc-editor.org/rfc/rfc5958>.
[RFC8174]: Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[X680]: ITU-T, "Information Technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, ISO/IEC 8824-1:2021, February 2021, <https://www.itu.int/rec/T-REC-X.680>.
[X690]: ITU-T, "Information Technology -- Abstract Syntax Notation One (ASN.1): ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1:2021, February 2021, <https://www.itu.int/rec/T-REC-X.690>.

9.2. Informative References

[CDFFJ21]: Cremers, C., Düzlü, S., Fiedler, R., Fischlin, M., and C. Janson, "BUFFing signature schemes beyond unforgeability and the case of post-quantum signatures", In Proceedings of the 42nd IEEE Symposium on Security and Privacy , 2021, <https://eprint.iacr.org/2020/1525.pdf>.
[Dilithium]: Bai, S., Ducas, L., Lepoint, T., Lyubashevsky, V., Schwabe, P., Seiler, G., and D. Stehlé, "CRYSTALS-Dilithium Algorithm Specifications and Supporting Documentation", 2021, <https://pq-crystals.org/dilithium/data/dilithium-specification-round3-20210208.pdf>.
[Fiat-Shamir]: Lyubashevsky, V., "Fiat-Shamir with aborts: Applications to lattice and factoring-based signatures", International Conference on the Theory and Application of Cryptology and Information Security , 2009, <https://www.iacr.org/archive/asiacrypt2009/59120596/59120596.pdf>.
[NIST-PQC]: National Institute of Standards and Technology (NIST), "Post-Quantum Cryptography Project", 20 December 2016, <https://csrc.nist.gov/Projects/post-quantum-cryptography>.
[RFC7468]: Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, April 2015, <https://www.rfc-editor.org/rfc/rfc7468>.

Appendix A. 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] and [I-D.ietf-lamps-cms-ml-dsa].¶

<CODE BEGINS>
X509-ML-DSA-2024
{ iso(1) identified-organization(3) dod(6)
  internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
  id-mod-x509-ml-dsa-2024(TBD1) }

DEFINITIONS IMPLICIT TAGS ::=

BEGIN

-- EXPORTS ALL;

IMPORTS

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

sa-ml-dsa-44, sa-ml-dsa-65, sa-ml-dsa-87,
pk-ml-dsa-44, pk-ml-dsa-65, pk-ml-dsa-87,
ML-DSA-PublicKey, ML-DSA-PrivateKey
  FROM ML-DSA-Module-2024 -- From [I-D.ietf-lamps-cms-ml-dsa]
     { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
       id-smime(16) id-mod(0) id-mod-ml-dsa-2024(TBD2) } ;

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

--
-- Expand SignatureAlgorithms from RFC 5912
--
PublicKeys PUBLIC-KEY ::= {
  pk-ml-dsa-44 |
  pk-ml-dsa-65 |
  pk-ml-dsa-87,
  ...
}

END

<CODE ENDS>

Appendix B. Security Strengths

Instead of defining the strength of a quantum algorithm in a traditional manner using the imprecise notion of bits of security, NIST has instead elected to define security levels by picking a reference scheme, which NIST expects to offer notable levels of resistance to both quantum and classical attack. To wit, an algorithm that achieves NIST PQC security level 1 must require computational resources to break the relevant security property, which are greater than those required for a brute-force key search on AES-128. Levels 3 and 5 use AES-192 and AES-256 as reference respectively. Levels 2 and 4 use collision search for SHA-256 and SHA-384 as reference.¶

The parameter sets defined for NIST security levels 2, 3 and 5 are listed in the Figure 1, along with the resulting signature size, public key, and private key sizes in bytes. Note that these are the sizes of the plain private and public keys; and not the sizes of the resultant OneAsymmetricKey and SubjectPublicKeyInfo objects in which they are wrapped.¶

|=======+=======+=====+========+========+========|
| Level | (k,l) | eta |  Sig.  | Public | Private|
|       |       |     |  (B)   | Key(B) | Key(B) |
|=======+=======+=====+========+========+========|
|   2   | (4,4) |  2  |  2420  |  1312  |  32    |
|   3   | (6,5) |  4  |  3309  |  1952  |  32    |
|   5   | (8,7) |  2  |  4627  |  2592  |  32    |
|=======+=======+=====+========+========+========|

Figure 1: ML-DSA Parameters

Appendix C. Examples

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

C.1. Example Private Key

The following is an example of a ML-DSA-44 private key with hex seed 000102…1e1f:¶

-----BEGIN PRIVATE KEY-----
MDICAQAwCwYJYIZIAWUDBAMRBCAAAQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRob
HB0eHw==
-----END PRIVATE KEY-----

SEQUENCE {
  INTEGER { 0 }
  SEQUENCE {
    OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.3.17 }
  }
  OCTET_STRING { `000102030405060708090a0b0c0d0e0f10111213141516
1718191a1b1c1d1e1f` }
}

The following is an example of a ML-DSA-65 private key with hex seed 000102…1e1f:¶

-----BEGIN PRIVATE KEY-----
MDICAQAwCwYJYIZIAWUDBAMSBCAAAQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRob
HB0eHw==
-----END PRIVATE KEY-----

SEQUENCE {
  INTEGER { 0 }
  SEQUENCE {
    OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.3.18 }
  }
  OCTET_STRING { `000102030405060708090a0b0c0d0e0f10111213141516
1718191a1b1c1d1e1f` }
}

The following is an example of a ML-DSA-87 private key with hex seed 000102…1e1f:¶

-----BEGIN PRIVATE KEY-----
MDICAQAwCwYJYIZIAWUDBAMTBCAAAQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRob
HB0eHw==
-----END PRIVATE KEY-----

SEQUENCE {
  INTEGER { 0 }
  SEQUENCE {
    OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.3.19 }
  }
  OCTET_STRING { `000102030405060708090a0b0c0d0e0f10111213141516
1718191a1b1c1d1e1f` }
}

NOTE: The private key is the seed and all three examples keys use the same seed; therefore, the private above are the same except for the OID used to represent the ML-DSA algorithm's security strength.¶

C.2. Example Public Key

The following is the ML-DSA-44 public key corresponding to the private key in the previous section.¶

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.¶

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.¶

SEQUENCE {
  SEQUENCE {
    OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.3.19 }
  }
  BIT_STRING { `00` `9792bcec2f2430686a82fccf3c2f5ff665e771d7ab4
1b90258cfa7e90ec97124a73b323b9ba21ab64d767c433f5a521effe18f86e46
a188952c4467e048b729e7fc4d115e7e48da1896d5fe119b10dcddef62cb3079
54074b42336e52836de61da941f8d37ea68ac8106fabe19070679af600853712
0f70793b8ea9cc0e6e7b7b4c9a5c7421c60f24451ba1e933db1a2ee16c79559f
21b3d1b8305850aa42afbb13f1f4d5b9f4835f9d87dfceb162d0ef4a7fdc4cba
1743cd1c87bb4967da16cc8764b6569df8ee5bdcbffe9a4e05748e6fdf225af9
e4eeb7773b62e8f85f9b56b548945551844fbd89806a4ac369bed2d256100f68
8a6ad5e0a709826dc4449e91e23c5506e642361ef5a313712f79bc4b3186861c
a85a4bab17e7f943d1b8a333aa3ae7ce16b440d6018f9e04daf5725c7f1a93fa
d1a5a27b67895bd249aa91685de20af32c8b7e268c7f96877d0c85001135a4f0
a8f1b8264fa6ebe5a349d8aecad1a16299ccf2fd9c7b85bace2ced3aa1276ba6
1ee78ed7e5ca5b67cdd458a9354030e6abbbabf56a0a2316fec9dba83b51d42f
d3167f1e0f90855d5c66509b210265dc1e54ec44b43ba7cf9aef118b44d80912
ce75166a6651e116cebe49229a7062c09931f71abd2293f76f7efc3215ba9780
0037e58e470bdbbb43c1b0439eaf79c54d93b44aac9efe9fbe151874cfb2a64c
bee28cc4c0fe7775e5d870f1c02e5b2e3c5004c995f24c9b779cb753a277d0e7
1fd425eb6bc2ca56ce129db51f70740f31e63976b50c7312e9797d78c5b1ac24
a5fa347cc916e0a83f5c3b675cd30b81e3fa10b93444e07397571cce98b28da5
1db9056bc728c5b0b1181e2fbd387b4c79ab1a5fefece37167af772ddad14eb4
c3982da5a59d0e9eb173ec6315091170027a3ab5ef6aa129cb8585727b9358a2
8501d713a72f3f1db31714286f9b6408013af06045d75592fc0b7dd47c73ed9c
75b11e9d7c69f7cadfc3280a9062c5273c43be1c34f87448864cea7b5c97d6d3
2f59bd5f25384653bb5c4faa45bea8b89402843e645b6b9269e2bd988ddacb03
3328ffb060450f7df080053e6969b251e875ecec32cfc592840d69ab69a75e06
b379c535d95266b082f4f09c93162b33b0d9f7307a4eaaa52104437fed66f8ee
3eabbd45d67b25a8133f496468b52baffdbfad93eef1a9818b5e42ec722788a3
d8d3529fc777d2ba570801dfae01ec88302837c1fb9e0355727645ee1046c3f9
15f6ae82dad4fb6b0356a46518ffc834155c3b4fe6dafa6cc8a5ccf53c73a084
9d8d44f7dcf72754e70e1b7dfb447bb4ef49d1a718f6171bbce200950e0ce926
106b151a3e871d5ce49731bd6650a9b0ca972da1c5f136d44820ea6383c08f3b
384cf2338e789c513f618cc5694a6f0cee104511e1ed7c5f23a1ebfd8a0db842
4553240156dbf622831b0c643d1c551b6f3f7a98d29b85c2de05a65fa615eee1
6495bd90737672115b53e91c5d90028cf3f1a93953a153de53b44084e9ccff6b
736693926daefebb2d77aa5ad689b92f31686669df16d1715cc58f7a2cfb72dd
1a51e92f825993a74022be7e9eb6054654457094d14928f20215e7b222ac56b5
1adbec8d8bdb6983979a7e3a21b44b5d1518ca97d0b5195f51ed6a24350c8974
7e1edea51b448e3e9147054ce927873c90db394d86888e07dff177593d6f79e1
52302204aeb03be2386af3e24078bd028b1689f5e147c9f452c8ceb02ec59cc9
db63a03576ceeafe98239023897da0236630a53c0de7f435a19869792fab36e7
b9e635760f09069e6432e700035ac2a02879fff0a1e1bec522047193d94eb5df
1efd53eea1144ca78940852f5ec9727904b366ede4f5e2d331fad5fc282ea2c4
7e923142771c3dd75a87357487def99e5f18e9d9ed623c175d02888c51f82c07
a80d54716b3c3c2bdbe2e9f0a9bbaaebeb4d52936876406f5c00e8e4bbd0a5ec
05797e6207c5ab6c88f1a688421bd05a114f4d7de2ac241fa0e8bedff47f762d
dcbeaa91004f8d31e85095c81054994ad3826e344ba96040810fc0b2ad1de48c
fade002c62e5a49a0731ab38344bc1636df16bf607d56855e56d684003c718e4
bad9e5a099979fcddeeb1c4a7776cd37a3417cb0e184e29ef9bc0e87475ba663
be09e00ab562eb7c0f7165f969a9b42414198ccf1bff2a2c8d689a414ece7662
927665689e94db961ebaec5615cbc1a7895c6851ac961432ff1118d4607d32ef
9dc732d51333be4b4d0e30ddea784eca8be47e741be9c19631dc470a52ef4dc1
3a4f3633fd434d787c170977b417df598e1d0dde506bb71d6f0bc17ec70e3b03
cdc1965cb36993f633b0472e50d0923ac6c66fdf1d3e6459cc121f0f5f94d09e
9dbcf5d690e23233838a0bacb7c638d1b2650a4308cd171b6855126d1da672a6
ed85a8d78c286fb56f4ab3d21497528045c63262c8a42af2f9802c53b7bb8be2
8e78fe0b5ce45fbb7a1af1a3b28a8d94b7890e3c882e39bc98e9f0ad76025bf0
dd2f00298e7141a226b3d7cee414f604d1e0ba54d11d5fe58bccea6ad77ad2e8
c1caacf32459014b7b91001b1efa8ad172a523fb8e365b577121bf9fd88a2c60
c21e821d7b6acb47a5a995e40caced5c223b8fe6de5e18e9d2e5893aefebb7aa
e7ff1a146260e2f110e939528213a0025a38ec79aabc861b25ebc509a4674c13
2aaacb7e0146f14efd11cfcaf4caa4f775a716ce325e0a435a4d349d720bcf13
7450afc45046fc1a1f83a9d329777a7084e4aadae7122ce97005930528eb3c7f
7f1129b372887a371155a3ba201a25cbf1dcb64e7cdee092c3141fb5550fe3d0
dd82e870e578b2b46500818113b8f6569773c677385b69a42b77dcba7acffd95
fd4452e23aaa1d37e1da2151ea658d40a3596b27ac9f8129dc6cf0643772624b
59f4f461230df471ca26087c3942d5c6687df6082835935a3f87cb762b0c3b1d
0dda4a6533965bef1b7b8292e254c014d090fed857c44c1839c694c0a64e3fad
90a11f534722b6ee1574f2e149d55d744de4887024e08511431c062750e16c74
ab9f3242f2db3ffb12a8d6107faa229d6f6373b07f36d3932b3bdb04c19dd64e
add7f93c3c564c358a1c81dcf1c9c31e5b06568f97544c17dc15698c5cb38983
a9afc42783faa773a52c9d8260690be9e3156aa5bc1509dea3f69587695cd6ff
172ba83e6a6d8a7d6bbebbbcda3672731983f89bc5831dc37c3f3c5c56facc69
7f3cb20bd5dbadbd702e54844ac2f626901fe159db93dfd4773d8fe73562b846
c1fc856d1802762840ebc72d7988bde75cbca70d319d32ce0cc0253bb2ad4557
23ee0c7f4736ce6e6665c5aca32a481c53839bc259167b013d0423395eeb9aaa
ee3206149a7d550d67fc5fdfe4a8a5c35d2510b664379ab8f72855a2af47abce
2a632048eaf89e5cb4a88debc53a595103acce4f1cff18acff07afe1eb5716aa
1e40b63134c3a3ae9579fa87f515be093c2d29db6d6b65c93661e00636b59270
4d093cc6716c2342eb1853d48c85c63ac8a2854462c7b77e7e3bd1eac5bca28f
faa00b5d349f8a547ad875b96a8c2b2910c9301309a3f9138a5693111f55b3c0
09ca947c39dfc82d98eb1caa4a9cbe885f786fa86e55be062222f8ba90a97407
3326b31212aece0a34a60` }
}

C.3. Example Certificate

The following is a self-signed certificate for the ML-DSA-44 public key in the previous section.¶

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
2fdeb72fa8e1a030061677b84cd275597d83154195966b141670cb0e88113460
d978a1a7a3895c11ca41995775c09d64ddeb47bc87c4e8bf1c9327fc4afd5c37
86553e17d629b0f27142765481432b5e7ccd0ba61e51cad3dd8f95938c235ebe
ceeaf8b16ae3366f300c5358ec7be9eb23a1ea1a3da58686704f0483f968a6e4
b1f89670a0134b36a18d6c727dc9b027b12794793a48c7ab66edf57ac1811391
4c00d0a11b65a652f47771337bf743666fca95bcbd39121ae0750bec55ad5a8c
bce98e538ae523947d6929976330fca3fc95c01d1403b49e5cba81812f43650d
d01310934279ecd07ccab34c2ca30a7d3dd5092e1630e1423cc9fac43a1b4db0
e3d970f0aa66d404ae87b04b4cf72ecfb67eacba4d8cd8e65baeeb47afa11cc2
b8ef8992288667b8edef54a9e2767b632e1498735b28c6f60f08b5969e5e26dd
7ca396b9e5cc3e12a1e73623602328d64a08ef4a29af35711cc870d26373bb1b
9eb2effe12973544c44a7e2cdf203244f53b37a6d523237d89f06f6f5534ed63
113c8f00eff7fdcd509a2d8c7cef29bd3fb186a4c8c362b3d442939a29076ee3
2716b8fae5100d81a07215cdb1c79bddfbdc14f52e37318d1e526db84d160fb8
da1c06dbce15955cdc2d6fd78a2a5a58df239ce366c6d90b32e8bd47fc1fd130
9e86294c0c3b51ce77e6dfb6f6722e68f4c3ff2eb4c346931506e743bb021998
b80f43f6e3d3c9fe54777c0f65800e947f9043290e14b01b63f8e26c30138094
2866c74b4a902ce491c0c950544cf0c6938eacb32eb30266ce82c4d0a36c511e
a8ff7c409549a3a8264ca983d8c6d5e035f244243a775758aac992b58844b711
0d3f87c9bba19dd8a8d2ab1294e0555ec4995a548dc56cce35a05dc48aca7555
b1641dde3d197fcdf35d12f09aaf3e6a72775cd18249a21e70edac6710db6a21
e1c0561192dd0119133640cfff20f3187978516bfd6cbe66ce1071b1246f4ba9
37df901b3ed35069eebdfff65459fb9b777ae9298a7a49ac24f4020795de5dee
8dbcf20a241b6e814368f4b8fa42af8be892d9e1e38ae4bf5a47cfd46a398e4b
3186471e24534fb139860b25c63f2dbf85a53d86488c83dff09ae20a9bf83145
f20187f0e822bd475998d3b967011964eed8db9778054efcc6ccb69074bba996
624b4741c5710362de9d4f8de4b10f6db1e9f8098f4024593ea073893cb1fe7b
959c50fefc401b3cacdea8c2a17135ba9df90ab7f31de339a2d6f856c71edcfb
00e5a3d73201fbec4b4a79b9728ad70cda0b898121574f60d959b408c108af1a
b0aa47dff372609f3186c063c572cb89089f2a218ea402cb072fcbc895a6a384
78ce402d5082c3e0572c2322cc20996ca968da35d7b2edbc0623be6165090120
5f10271155b539f81d006db8d7b67a4edeef677e6dac9c789be55001574eeea8
797f7f52e4bb021b98e2088dcc8d6934e80dc165d1c714449b0bcfaf325ab596
7b7307ec2937b3492425bf63b8abbd3ed97da1d15b5483fa64cf71a49c4d3b4b
78200d1f509206f2c104bfe3696e3c80036db00a5e11da05a5ff4da0ffb99567
f81399e6ca969b111b6c7b6fce549e6b4d89d459381ea9166e9bb3072089db94
ae0d1afe5f29fce190e77adba643494191cdaba3ead9297c3c606332b74697f1
9c09c4be2a341fd6145129ae856c3abbbc1bb8b05e0b7840ff164414a9da44e5
4146cd4c5de0c4e4ecb2591412b4e7bdc450d06a4ad3a0d1406f306e381ec291
f2c3b3bc49f8b7e048c0ce2734830b48a79d35fcc5a62a9454800a30f4b3eb7a
268bab64c12100d712151bf5f12163bed029e8abf1ca6e7b7b1286a733f532da
e511091aab0fffcfd4464ee5663888f9859b44ba765360ffff434f12af1fc6bc
cdb5a71947149dc7689dff24d6ba6b63e6cc23140e32934b6e9da765b4332011
8b8a811f89c3d1b7ff21530e77a91cae3557ac7c784ff8263500bc82560030d6
c6e74eee817fc2c63402752e59ef43916d3d83c21686436e9034dda6c974f210
8b174eaa1f73121c9add500cecd8618b302bedad72b62f793bd0f70ba8c5e16c
f4abeddd51196816d019517d1e25fb62c9f79d9232fdf1ceec604f8dda5f7145
541c5793b9c5ae1589588a49a6e6174614ea012933a192b3b084725b465bb1a2
2ccb4b60cf3ca142f7683a8267fb6b0a8dc0b3a5f63ab60443f6c7ee70e9b5b0
67adfdc33960f88961e8b6a8a31e61cbc0096888f06346637ecece196291b95e
3b8c579df27010e631eba3634c766a933d7f4e20811946bb87e97f7e7bade957
e4c52d72676af91ac771ec351f36411e2b2cc8327611037cf0df4e3b947a87ef
5e2b57955b137c981105af76d6251cc14cdb3f430ed6b9f514404ce7a69bb000
d5f62c7e876b57f40f262e6a3e6be91ed0af7c8b5b74b160f3c661d735799d5f
b47685135c5551f69a09444f5f01295f539a8227d271e4849fbc8906cf57e67e
a5e150df5f13b0b412f97b21840b82e4d71739d1bec5ef9e58b047d52dfe0f39
26d5d48a4bb81764e10813070436e8bfaa75dbc90ffb6ecb0604a1338206f347
25c689fcb1687acb444b533d4c4da9846192825c03d9cc9a1685bcdd367b3f41
3b2334ff3096ebc146d7646fac3856b9ba18ed815d8ea941404f7280eeca6021
7c017d4f1467f3ad0e41e31c4ff351b14f59ffc9d19f3dca6c0b8c4d8b10eaa6
e3b8b4c3c1f17d0786f86140d0476db3f3097308d2f3830165192235db185fdd
e8d19708c664927fd75529e2911e8114bf73e2e2d8e52f42bf49c62f17188744
2596354fca15a730c97f70b6f60a40456483017ac59f49606479ea17279b782d
6e0d6f2bff01ad626236102e77f8594e179005707fb72f339b6737abab0ae8af
850c380f81e5c40c539bc3bf52c57162f3bc91cc5c97c21cbe67552ba45c231a
c2bf836de2a3ae4b1e1b4517d20a546d0cb4bc7207d4ada0783db1ca5dd327c8
c268a3b16ff1eef8a7e4bed382b21d3b4c0f9c9d357558747beecbd470c12bcc
75d63859bcf94a2621700b3b51220dba6edfc8044512e40bce1e32144142329c
76695c045b268a5b7771f2287f2a6e84c4622058c891ed34cb618475056c6460
3f2d7d4720ba83e1d1050c3408d8b3ef086e6a7b6f074df5aca73b2a2bde0844
44b39be566769223373913cab3c8d3ac8cbf168719a8f052d2d6091789386fee
5e1b306d7ec4be2558caa091e2fcc32c355702e971a3f3ac1da421317f3160e2
d7a27b71ed2342065bbf104070c3942494a5257607798a0afb6c3c6cbd9eaf1f
2ff070d233637454762767b839294a6d612282f3e3f496d939ba0b6bbd2dae5e
beeef101f232d6e97c2c4dff3f40000000000000000000000000017263843` }
}

Appendix D. Pre-hashing (ExternalMu-ML-DSA)

Some applications require pre-hashing, where the signature generation process can be separated into a pre-hash step and a core signature step in order to ease operational requirements around large or inconsistently-sized payloads. Pre-hashing can be performed at the protocol layer, but not all protocols support it. Examples in [RFC5280] are certificates and CRLs; these do not include message digesting before signing. This can make signing large CRLs or a high volume of certificates with large public keys challenging.¶

As mentioned in the introduction, pure ML-DSA signing itself supports a pre-hashing flow by splitting the operation over two modules. In this section, we make this "ExternalMu-ML-DSA" more explicit.¶

There are two steps. First an ExternalMu-ML-DSA.Prehash() followed by ExternalMu-ML-DSA.Sign(). Together these are functionally equivalent to ML-DSA.Sign() from [FIPS204] in that used in sequence they create exactly the same signatures as regular pure ML-DSA, which can be verified by the unmodified ML-DSA.Verify().¶

An ML-DSA key and certificate can be used with either ML-DSA or ExternalMu-ML-DSA interchangeably. Note that ExternalMu-ML-DSA describes a different signature API from ML-DSA and therefore might require explicit support from hardware or software cryptographic modules.¶

Note that the signing mode defined here is different from HashML-DSA defined in Section 5.4 of [FIPS204]. This specification uses exclusively ExternalMu-ML-DSA for pre-hashed use cases. See Section 8.1 for additional discussion of why HashML-DSA is disallowed in PKIX.¶

All functions and notation used in Figure 2 and Figure 3 are defined in [FIPS204].¶

External operations:¶

ExternalMu-ML-DSA.Prehash(pk, M, ctx):

  if |ctx| > 255 then
    return error  # return an error indication if the context string is
                  # too long
  end if

  M' = BytesToBits(IntegerToBytes(0, 1) ∥ IntegerToBytes(|ctx|, 1)
                                                        || ctx) || M
  mu = H(BytesToBits(H(pk, 64)) || M', 64)
  return mu

Figure 2: External steps of ExternalMu-ML-DSA

Internal operations:¶

ExternalMu-ML-DSA.Sign(sk, mu):

  if |mu| != 512 then
    return error  # return an error indication if the input mu is not
                  # 64 bytes (512 bits).
  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 = ExternalMu-ML-DSA.Sign_internal(sk, mu, rnd)
  return sigma

ExternalMu-ML-DSA.Sign_internal(sk, mu, rnd): # mu is passed as argument instead of M'
   ... identical to FIPS 204 Algorithm 7, but with Line 6 removed.

Figure 3: Internal steps of ExternalMu-ML-DSA

ExternalMu-ML-DSA requires the public key, or its prehash, as input to the pre-digesting function. This assumes the signer generating the pre-hash is in possession of the public key before signing and is different from conventional pre-hashing which only requires the message and the hash function as input.¶

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

Acknowledgments

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

Authors' Addresses

Jake Massimo

AWS

United States of America

Email: jakemas@amazon.com

Panos Kampanakis

AWS