rfc9881.original   rfc9881.txt 
LAMPS WG J. Massimo Internet Engineering Task Force (IETF) J. Massimo
Internet-Draft P. Kampanakis Request for Comments: 9881 P. Kampanakis
Intended status: Standards Track AWS Category: Standards Track AWS
Expires: 3 April 2026 S. Turner ISSN: 2070-1721 S. Turner
sn3rd sn3rd
B. E. Westerbaan B. E. Westerbaan
Cloudflare Cloudflare
30 September 2025 October 2025
Internet X.509 Public Key Infrastructure - Algorithm Identifiers for the Internet X.509 Public Key Infrastructure -- Algorithm Identifiers for
Module-Lattice-Based Digital Signature Algorithm (ML-DSA) the Module-Lattice-Based Digital Signature Algorithm (ML-DSA)
draft-ietf-lamps-dilithium-certificates-13
Abstract Abstract
Digital signatures are used within X.509 certificates, Certificate Digital signatures are used within X.509 certificates and Certificate
Revocation Lists (CRLs), and to sign messages. This document Revocation Lists (CRLs), and to sign messages. This document
specifies the conventions for using FIPS 204, the Module-Lattice- specifies the conventions for using FIPS 204, the Module-Lattice-
Based Digital Signature Algorithm (ML-DSA) in Internet X.509 Based Digital Signature Algorithm (ML-DSA) in Internet X.509
certificates and certificate revocation lists. The conventions for certificates and CRLs. The conventions for the associated
the associated signatures, subject public keys, and private key are signatures, subject public keys, and private key are also described.
also described.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at https://lamps-
wg.github.io/dilithium-certificates/#go.draft-ietf-lamps-dilithium-
certificates.html. Status information for this document may be found
at https://datatracker.ietf.org/doc/draft-ietf-lamps-dilithium-
certificates/.
Discussion of this document takes place on the Limited Additional
Mechanisms for PKIX and SMIME (lamps) Working Group mailing list
(mailto:spasm@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/spasm/. Subscribe at
https://www.ietf.org/mailman/listinfo/spasm/.
Source for this draft and an issue tracker can be found at
https://github.com/lamps-wg/dilithium-certificates.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 3 April 2026. 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 Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language
2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Identifiers
3. ML-DSA Signatures in PKIX . . . . . . . . . . . . . . . . . . 4 3. ML-DSA Signatures in PKIX
4. ML-DSA Public Keys in PKIX . . . . . . . . . . . . . . . . . 6 4. ML-DSA Public Keys in PKIX
5. Key Usage Bits . . . . . . . . . . . . . . . . . . . . . . . 8 5. Key Usage Bits
6. Private Key Format . . . . . . . . . . . . . . . . . . . . . 8 6. Private Key Format
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations
8. Operational Considerations . . . . . . . . . . . . . . . . . 11 8. Operational Considerations
8.1. Private Key Format . . . . . . . . . . . . . . . . . . . 11 8.1. Private Key Format
8.2. Private Key Consistency Testing . . . . . . . . . . . . . 12 8.2. Private Key Consistency Testing
8.3. Rationale for disallowing HashML-DSA . . . . . . . . . . 12 8.3. Rationale for Disallowing HashML-DSA
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. References
10.1. Normative References . . . . . . . . . . . . . . . . . . 14 10.1. Normative References
10.2. Informative References . . . . . . . . . . . . . . . . . 15 10.2. Informative References
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 16 Appendix A. ASN.1 Module
Appendix B. Security Strengths . . . . . . . . . . . . . . . . . 20 Appendix B. Security Strengths
Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 20 Appendix C. Examples
C.1. Example Private Keys . . . . . . . . . . . . . . . . . . 20 C.1. Example Private Keys
C.1.1. ML-DSA-44 Private Key Examples . . . . . . . . . . . 21 C.1.1. ML-DSA-44 Private Key Examples
C.1.2. ML-DSA-65 Private Key Examples . . . . . . . . . . . 27 C.1.2. ML-DSA-65 Private Key Examples
C.1.3. ML-DSA-87 Private Key Examples . . . . . . . . . . . 37 C.1.3. ML-DSA-87 Private Key Examples
C.2. Example Public Keys . . . . . . . . . . . . . . . . . . . 49 C.2. Example Public Keys
C.3. Example Certificates . . . . . . . . . . . . . . . . . . 58 C.3. Example Certificates
C.4. Example Inconsistent Seed and Expanded Private Keys . . . 82 C.4. Example Inconsistent Seed and Expanded Private Keys
Appendix D. Pre-hashing (Externalμ-ML-DSA) . . . . . . . . . . . 87 Appendix D. Pre-Hashing (Externalμ-ML-DSA)
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 89 Acknowledgments
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 89 Authors' Addresses
1. Introduction 1. Introduction
The Module-Lattice-Based Digital Signature Algorithm (ML-DSA) is a The Module-Lattice-Based Digital Signature Algorithm (ML-DSA) is a
quantum-resistant digital signature scheme standardized by the US quantum-resistant digital signature scheme standardized by the US
National Institute of Standards and Technology (NIST) PQC project National Institute of Standards and Technology (NIST) PQC project
[NIST-PQC] in [FIPS204]. This document specifies the use of the ML- [NIST-PQC] in [FIPS204]. This document specifies the use of the ML-
DSA in Public Key Infrastructure X.509 (PKIX) certificates and DSA in Public Key Infrastructure X.509 (PKIX) certificates and
Certificate Revocation Lists (CRLs) at three security levels: ML-DSA- Certificate Revocation Lists (CRLs) at three security levels: ML-DSA-
44, ML-DSA-65, and ML-DSA-87. 44, ML-DSA-65, and ML-DSA-87.
[FIPS204] defines two variants of ML-DSA: a pure and a pre-hash [FIPS204] defines two variants of ML-DSA: pure and pre-hash. Only
variant. Only the former is specified in this document. See the former is specified in this document. See Section 8.3 for the
Section 8.3 for the rationale. The pure variant of ML-DSA supports rationale. The pure variant of ML-DSA supports the typical pre-hash
the typical pre-hash flow. Refer to Appendix D for more details. flow. Refer to Appendix D for more details.
Prior to standardisation, ML-DSA was known as Dilithium. ML-DSA and Prior to standardization, ML-DSA was known as Dilithium. ML-DSA and
Dilithium are not compatible. Dilithium are not compatible.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Identifiers 2. Identifiers
The AlgorithmIdentifier type is defined in [RFC5912] as follows: The AlgorithmIdentifier type is defined in [RFC5912] as follows:
AlgorithmIdentifier{ALGORITHM-TYPE, ALGORITHM-TYPE:AlgorithmSet} ::= AlgorithmIdentifier{ALGORITHM-TYPE, ALGORITHM-TYPE:AlgorithmSet} ::=
SEQUENCE { SEQUENCE {
algorithm ALGORITHM-TYPE.id({AlgorithmSet}), algorithm ALGORITHM-TYPE.&id({AlgorithmSet}),
parameters ALGORITHM-TYPE. parameters ALGORITHM-TYPE.
Params({AlgorithmSet}{@algorithm}) OPTIONAL &Params({AlgorithmSet}{@algorithm}) OPTIONAL
} }
| NOTE: The above syntax is from [RFC5912] and is compatible with | NOTE: The above syntax is from [RFC5912] and is compatible with
| the 2021 ASN.1 syntax [X680]. See [RFC5280] for the 1988 ASN.1 | the 2021 ASN.1 syntax [X680]. See [RFC5280] for the 1988 ASN.1
| syntax. | syntax.
The fields in AlgorithmIdentifier have the following meanings: The fields in AlgorithmIdentifier have the following meanings:
* algorithm identifies the cryptographic algorithm with an object * algorithm identifies the cryptographic algorithm with an object
identifier (OID). identifier (OID).
* parameters, which are optional, are the associated parameters for * parameters, which are optional, are the associated parameters for
the algorithm identifier in the algorithm field. the algorithm identifier in the algorithm field.
The NIST registered OIDs [CSOR] are: The NIST-registered OIDs [CSOR] are:
id-ml-dsa-44 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-ml-dsa-44 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) sigAlgs(3) id-ml-dsa-44(17) } nistAlgorithm(4) sigAlgs(3) id-ml-dsa-44(17) }
id-ml-dsa-65 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-ml-dsa-65 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) sigAlgs(3) id-ml-dsa-65(18) } nistAlgorithm(4) sigAlgs(3) id-ml-dsa-65(18) }
id-ml-dsa-87 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-ml-dsa-87 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
skipping to change at page 4, line 39 skipping to change at line 156
The contents of the parameters component for each algorithm MUST be The contents of the parameters component for each algorithm MUST be
absent. absent.
3. ML-DSA Signatures in PKIX 3. ML-DSA Signatures in PKIX
ML-DSA is a digital signature scheme built upon the Fiat-Shamir-with- ML-DSA is a digital signature scheme built upon the Fiat-Shamir-with-
aborts framework [Fiat-Shamir]. The security is based upon the aborts framework [Fiat-Shamir]. The security is based upon the
hardness of lattice problems over module lattices [Dilithium]. ML- hardness of lattice problems over module lattices [Dilithium]. ML-
DSA provides three parameter sets for the NIST PQC security DSA provides three parameter sets for the NIST PQC security
categories 2, 3 and 5. categories 2, 3, and 5.
Signatures are used in a number of different ASN.1 structures. As 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 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 certificate, a signature is encoded with an algorithm identifier in
the signatureAlgorithm attribute and a signatureValue attribute that the signatureAlgorithm attribute and a signatureValue attribute that
contains the actual signature. contains the actual signature.
Certificate ::= SIGNED{ TBSCertificate } Certificate ::= SIGNED{ TBSCertificate }
SIGNED{ToBeSigned} ::= SEQUENCE { SIGNED{ToBeSigned} ::= SEQUENCE {
toBeSigned ToBeSigned, toBeSigned ToBeSigned,
algorithmIdentifier SEQUENCE { algorithmIdentifier SEQUENCE {
algorithm SIGNATURE-ALGORITHM. algorithm SIGNATURE-ALGORITHM.
skipping to change at page 5, line 22 skipping to change at line 181
parameters SIGNATURE-ALGORITHM. parameters SIGNATURE-ALGORITHM.
&Params({SignatureAlgorithms} &Params({SignatureAlgorithms}
{@algorithmIdentifier.algorithm}) {@algorithmIdentifier.algorithm})
OPTIONAL OPTIONAL
}, },
signature BIT STRING (CONTAINING SIGNATURE-ALGORITHM.&Value( signature BIT STRING (CONTAINING SIGNATURE-ALGORITHM.&Value(
{SignatureAlgorithms} {SignatureAlgorithms}
{@algorithmIdentifier.algorithm})) {@algorithmIdentifier.algorithm}))
} }
Signatures are also used in the CRL list ASN.1 representation from Signatures are also used in the CRL list ASN.1; the representation
[RFC5280] below. In a X.509 CRL, a signature is encoded with an below is equivalent to that in [RFC5280]. In an X.509 CRL, a
algorithm identifier in the signatureAlgorithm attribute and a signature is encoded with an algorithm identifier in the
signatureValue attribute that contains the actual signature. signatureAlgorithm attribute and a signatureValue attribute that
contains the actual signature.
CertificateList ::= SIGNED{ TBSCertList } CertificateList ::= SIGNED{ TBSCertList }
The following SIGNATURE-ALGORITHM ASN.1 classes are for ML-DSA-44, The following SIGNATURE-ALGORITHM ASN.1 classes are for ML-DSA-44,
ML-DSA-65, and ML-DSA-87: ML-DSA-65, and ML-DSA-87:
sa-ml-dsa-44 SIGNATURE-ALGORITHM ::= { sa-ml-dsa-44 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-ml-dsa-44 IDENTIFIER id-ml-dsa-44
PARAMS ARE absent PARAMS ARE absent
PUBLIC-KEYS { pk-ml-dsa-44 } PUBLIC-KEYS { pk-ml-dsa-44 }
skipping to change at page 6, line 11 skipping to change at line 219
PUBLIC-KEYS { pk-ml-dsa-87 } PUBLIC-KEYS { pk-ml-dsa-87 }
SMIME-CAPS { IDENTIFIED BY id-ml-dsa-87 } SMIME-CAPS { IDENTIFIED BY id-ml-dsa-87 }
} }
| NOTE: The above syntax is from [RFC5912] and is compatible with | NOTE: The above syntax is from [RFC5912] and is compatible with
| the 2021 ASN.1 syntax [X680]. See [RFC5280] for the 1988 ASN.1 | the 2021 ASN.1 syntax [X680]. See [RFC5280] for the 1988 ASN.1
| syntax. | syntax.
The identifiers defined in Section 2 can be used as the The identifiers defined in Section 2 can be used as the
AlgorithmIdentifier in the signatureAlgorithm field in the sequence AlgorithmIdentifier in the signatureAlgorithm field in the sequence
Certificate/CertificateList and the signature field in the sequence Certificate/CertificateList and in the signature field in the
TBSCertificate/TBSCertList in certificates and CRLs, respectively, sequence TBSCertificate/TBSCertList in certificates and CRLs,
[RFC5280]. The parameters of these signature algorithms MUST be respectively, [RFC5280]. The parameters of these signature
absent, as explained in Section 2. That is, the AlgorithmIdentifier algorithms MUST be absent, as explained in Section 2. That is, the
SHALL be a SEQUENCE of one component, the OID id-ml-dsa-*, where * is AlgorithmIdentifier SHALL be a SEQUENCE of one component, the OID id-
44, 65, or 87 - see Section 2. ml-dsa-*, where * is 44, 65, or 87 -- see Section 2.
The signatureValue field contains the corresponding ML-DSA signature The signatureValue field contains the corresponding ML-DSA signature
computed upon the ASN.1 DER encoded tbsCertificate/tbsCertList computed upon the ASN.1 DER-encoded TBSCertificate/TBSCertList
[RFC5280]. The optional context string (ctx) parameter as defined in [RFC5280]. The optional context string (ctx) parameter as defined in
Section 5.2 of [FIPS204] is left to its default value: the empty Section 5.2 of [FIPS204] is left to its default value: the empty
string. string.
Conforming Certification Authority (CA) implementations MUST specify Conforming Certification Authority (CA) implementations MUST specify
the algorithms explicitly by using the OIDs specified in Section 2 the algorithms explicitly by using the OIDs specified in Section 2
when encoding ML-DSA signatures in certificates and CRLs. Conforming when encoding ML-DSA signatures in certificates and CRLs. Conforming
client implementations that process certificates and CRLs using ML- client implementations that process certificates and CRLs using ML-
DSA MUST recognize the corresponding OIDs. Encoding rules for ML-DSA DSA MUST recognize the corresponding OIDs. Encoding rules for ML-DSA
signature values are specified in Section 2. signature values are specified in Section 2.
skipping to change at page 8, line 7 skipping to change at line 310
| the 2021 ASN.1 syntax [X680]. See [RFC5280] for the 1988 ASN.1 | the 2021 ASN.1 syntax [X680]. See [RFC5280] for the 1988 ASN.1
| syntax. | syntax.
[RFC5958] specifies the Asymmetric Key Package's OneAsymmetricKey [RFC5958] specifies the Asymmetric Key Package's OneAsymmetricKey
type for encoding asymmetric keypairs. When an ML-DSA private key or type for encoding asymmetric keypairs. When an ML-DSA private key or
keypair is encoded as a OneAsymmetricKey, it follows the description keypair is encoded as a OneAsymmetricKey, it follows the description
in Section 6. in Section 6.
When the ML-DSA private key appears outside of an Asymmetric Key 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 Package in an environment that uses ASN.1 encoding, it can be encoded
using one of the the ML-DSA-PrivateKey CHOICE formats defined in using one of the ML-DSA-PrivateKey CHOICE formats defined in
Section 6. The seed format is RECOMMENDED as it efficiently stores Section 6. The seed format is RECOMMENDED as it efficiently stores
both the private and public key. both the private and public key.
Appendix C contains example ML-DSA public keys encoded using the Appendix C contains example ML-DSA public keys encoded using the
textual encoding defined in [RFC7468]. textual encoding defined in [RFC7468].
5. Key Usage Bits 5. Key Usage Bits
The intended application for the key is indicated in the keyUsage The intended application for the key is indicated in the keyUsage
certificate extension; see Section 4.2.1.3 of [RFC5280]. If the certificate extension; see Section 4.2.1.3 of [RFC5280]. If the
keyUsage extension is present in a certificate that includes id-ml- keyUsage extension is present in a certificate that includes id-ml-
dsa-* (where * is 44, 65, or 87 - see Section 2) in the dsa-* (where * is 44, 65, or 87 -- see Section 2) in the
SubjectPublicKeyInfo, then the subject public key can only be used SubjectPublicKeyInfo, then the subject public key can only be used
for verifying digital signatures on certificates or CRLs, or those for verifying digital signatures on certificates or CRLs, or those
used in an entity authentication service, a data origin used in an entity authentication service, a data origin
authentication service, an integrity service, and/or a non- authentication service, an integrity service, and/or a non-
repudiation service that protects against the signing entity falsely repudiation service that protects against the signing entity falsely
denying some action. This means that the keyUsage extention MUST denying some action. This means that the keyUsage extension MUST
have at least one of the following bits set: have at least one of the following bits set:
digitalSignature * digitalSignature
nonRepudiation
keyCertSign * nonRepudiation
cRLSign
* keyCertSign
* cRLSign
ML-DSA subject public keys cannot be used to establish keys or ML-DSA subject public keys cannot be used to establish keys or
encrypt data, so the keyUsage extention MUST NOT have any of encrypt data, so the keyUsage extension MUST NOT have any of the
following bits set: following bits set:
keyEncipherment, * keyEncipherment
dataEncipherment,
keyAgreement, * dataEncipherment
encipherOnly, and
decipherOnly. * keyAgreement
* encipherOnly
* decipherOnly
Requirements about the keyUsage extension bits defined in [RFC5280] Requirements about the keyUsage extension bits defined in [RFC5280]
still apply. still apply.
6. Private Key Format 6. Private Key Format
[FIPS204] specifies two formats for an ML-DSA private key: a 32-octet [FIPS204] specifies two formats for an ML-DSA private key: a 32-octet
seed (xi) and an (expanded) private key. The expanded private key seed (xi) and an (expanded) private key. The expanded private key
(and public key) is computed from the seed using ML- (and public key) is computed from the seed using ML-
DSA.KeyGen_internal(xi) (algorithm 6). DSA.KeyGen_internal(xi) (algorithm 6).
skipping to change at page 9, line 35 skipping to change at line 393
{@privateKeyAlgorithm.algorithm}) {@privateKeyAlgorithm.algorithm})
OPTIONAL ]], OPTIONAL ]],
... ...
} }
| NOTE: The above syntax is from [RFC5958] and is compatible with | NOTE: The above syntax is from [RFC5958] and is compatible with
| the 2021 ASN.1 syntax [X680]. | the 2021 ASN.1 syntax [X680].
For ML-DSA private keys, the privateKey field in OneAsymmetricKey For ML-DSA private keys, the privateKey field in OneAsymmetricKey
contains one of the following DER-encoded CHOICE structures. The contains one of the following DER-encoded CHOICE structures. The
seed format is a fixed 32 byte OCTET STRING (34 bytes total with 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 0x8020 tag and length) for all security levels, while the expandedKey
and both formats vary in size by security level: and both formats vary in size by security level:
ML-DSA-44-PrivateKey ::= CHOICE { ML-DSA-44-PrivateKey ::= CHOICE {
seed [0] OCTET STRING (SIZE (32)), seed [0] OCTET STRING (SIZE (32)),
expandedKey OCTET STRING (SIZE (2560)), expandedKey OCTET STRING (SIZE (2560)),
both SEQUENCE { both SEQUENCE {
seed OCTET STRING (SIZE (32)), seed OCTET STRING (SIZE (32)),
expandedKey OCTET STRING (SIZE (2560)) expandedKey OCTET STRING (SIZE (2560))
} }
skipping to change at page 10, line 46 skipping to change at line 438
The CHOICE allows three representations of the private key: The CHOICE allows three representations of the private key:
1. The seed format (tag [0]) contains just the 32-byte seed value 1. The seed format (tag [0]) contains just the 32-byte seed value
(xi) from which both the expanded private key and public key can (xi) from which both the expanded private key and public key can
be derived using ML-DSA.KeyGen_internal(xi). be derived using ML-DSA.KeyGen_internal(xi).
2. The expandedKey format contains the expanded private key that was 2. The expandedKey format contains the expanded private key that was
derived from the seed. derived from the seed.
3. The both format contains both the seed and expanded private key, 3. The both format contains both the seed and expanded private key,
allowing for for interoperability; some may want to use and allowing for interoperability; some may want to use and retain
retain the seed and others may only support expanded private the seed and others may only support expanded private keys.
keys.
When encoding an ML-DSA private key in a OneAsymmetricKey object, any When encoding an ML-DSA private key in a OneAsymmetricKey object, any
of these three formats may be used, though the seed format is of these three formats may be used, though the seed format is
RECOMMENDED for storage efficiency. RECOMMENDED for storage efficiency.
The privateKeyAlgorithm field uses the AlgorithmIdentifier structure The privateKeyAlgorithm field uses the AlgorithmIdentifier structure
with the appropriate OID as defined in Section 2. If present, the with the appropriate OID as defined in Section 2. If present, the
publicKey field will hold the encoded public key as defined in publicKey field will hold the encoded public key as defined in
Section 4. Section 4.
NOTE: While the private key can be stored in multiple formats, the | NOTE: While the private key can be stored in multiple formats,
seed-only format is RECOMMENDED as it is the most compact | the seed-only format is RECOMMENDED as it is the most compact
representation. Both the expanded private key and the public key can | representation. Both the expanded private key and the public
be deterministically derived from the seed using ML- | key can be deterministically derived from the seed using ML-
DSA.KeyGen_internal(xi). Alternatively, the public key can be | DSA.KeyGen_internal(xi). Alternatively, the public key can be
generated from the private key. While the publicKey field and | generated from the private key. While the publicKey field and
expandedKey format are technically redundant when using the seed-only | expandedKey format are technically redundant when using the
format, they MAY be included to enable keypair consistency checks | seed-only format, they MAY be included to enable keypair
during import operations. | consistency checks during import operations.
When parsing the private key, the ASN.1 tag explicitly indicates When parsing the private key, the ASN.1 tag explicitly indicates
which variant of CHOICE is present. Implementations should use the which variant of CHOICE is present. Implementations should use the
context-specific tag IMPLICIT [0] (raw value 0x80) for seed, OCTET context-specific tag IMPLICIT [0] (raw value 0x80) for seed, OCTET
STRING (0x04) for expandedKey, and SEQUENCE (0x30) for both to parse STRING (0x04) for expandedKey, and SEQUENCE (0x30) for both to parse
the private key, rather than any other heuristic like length of the the private key, rather than any other heuristic like length of the
enclosing OCTET STRING. enclosing OCTET STRING.
Appendix C contains example ML-DSA private keys encoded using the Appendix C contains example ML-DSA private keys encoded using the
textual encoding defined in [RFC7468]. textual encoding defined in [RFC7468].
7. IANA Considerations 7. IANA Considerations
For the ASN.1 module in Appendix A, IANA is requested to assign an For the ASN.1 module in Appendix A, IANA has assigned the following
object identifier (OID) for the module identifier (TBD1) with a object identifier (OID) in the "SMI Security for PKIX Module
Description of "id-mod-x509-ml-dsa-2025". The OID for the module Identifier" registry (1.3.6.1.5.5.7.0):
should be allocated in the "SMI Security for PKIX Module Identifier"
registry (1.3.6.1.5.5.7.0). +=========+=========================+===========+
| Decimal | Description | Reference |
+=========+=========================+===========+
| 119 | id-mod-x509-ml-dsa-2025 | RFC 9881 |
+---------+-------------------------+-----------+
Table 1: Registered ASN.1 Module
8. Operational Considerations 8. Operational Considerations
8.1. Private Key Format 8.1. Private Key Format
An ML-DSA.KeyGen seed (xi) represents the RECOMMENDED format for An ML-DSA.KeyGen seed (xi) represents the RECOMMENDED format for
storing and transmitting ML-DSA private keys. This format is storing and transmitting ML-DSA private keys. This format is
explicitly permitted by [FIPS204] as an acceptable representation of explicitly permitted by [FIPS204] as an acceptable representation of
a keypair. In particular, generating the seed in one cryptographic a keypair. In particular, generating the seed in one cryptographic
module and then importing or exporting it into another cryptographic module and then importing or exporting it into another cryptographic
module is allowed. The internal key generation function ML- module is allowed. The internal key-generation function ML-
DSA.KeyGen_internal(xi) can be accessed for this purpose. DSA.KeyGen_internal(xi) can be accessed for this purpose.
Note also that unlike other private key compression methods in other Note also that unlike other private key compression methods in other
algorithms, expanding a private key from a seed is a one-way 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 function, meaning that once a full key is expanded from seed and the
seed discarded, the seed cannot be re-created even if the full seed discarded, the seed cannot be recreated, even if the full
expanded private key is available. For this reason it is RECOMMENDED expanded private key is available. For this reason, it is
that implementations retain and export the seed, even when also RECOMMENDED that implementations retain and export the seed, even
exporting the expanded private key. ML-DSA seed extraction can be when also exporting the expanded private key. ML-DSA seed extraction
implemented by including the seed xi randomly generated at line 1 of can be implemented by including the seed xi that is randomly
Algorithm 1 ML-DSA.KeyGen in the returned output. 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 When encoding an ML-DSA private key in a OneAsymmetricKey object, any
of these three formats may be used, though the seed format is of these three formats may be used, though the seed format is
RECOMMENDED for storage efficiency. RECOMMENDED for storage efficiency.
8.2. Private Key Consistency Testing 8.2. Private Key Consistency Testing
When receiving a private key that contains both the seed and the When receiving a private key that contains both the seed and the
expandedKey, the recipient SHOULD perform a seed consistency check to expandedKey, the recipient SHOULD perform a seed consistency check to
ensure that the sender properly generated the private key. ensure that the sender properly generated the private key.
Recipients that do not perform this seed consistency check avoid Recipients that do not perform this seed consistency check avoid
keygen and compare operations, but are unable to ensure that the seed keygen and compare operations, but are unable to ensure that the seed
and expandedKey match. and expandedKey match.
If the check is done and the seed and the expandedKey are not If the check is done and the seed and the expandedKey are not
consistent, the recipient MUST reject the private key as malformed. consistent, the recipient MUST reject the private key as malformed.
The seed consistency check consists of regenerating the expanded form The seed consistency check consists of regenerating the expanded form
from the seed via ML-DSA.KeyGen_internal and ensuring it is bytewise from the seed via ML-DSA.KeyGen_internal, and ensuring it is bytewise
equal to the value presented in the private key. equal to the value presented in the private key.
Appendix C.4 includes some examples of inconsistent seeds and Appendix C.4 includes some examples of inconsistent seeds and
expanded private keys. expanded private keys.
8.3. Rationale for disallowing HashML-DSA 8.3. Rationale for Disallowing HashML-DSA
The HashML-DSA mode defined in Section 5.4 of [FIPS204] MUST NOT be 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- 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, 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, with-sha512 MUST NOT be in X.509 certificates used for CRLs, OCSP,
certificate issuance and related PKIX protocols. This restriction is certificate issuance, and related PKIX protocols. This restriction
primarily to increase interoperability. is primarily to increase interoperability.
ML-DSA and HashML-DSA are incompatible algorithms that require ML-DSA and HashML-DSA are incompatible algorithms that require
different Verify() routines. This introduces the complexity of different Verify() routines. This introduces the complexity of
informing the verifier whether to use ML-DSA.Verify() or HashML- informing the verifier whether to use ML-DSA.Verify() or HashML-
DSA.Verify(). Additionally, since the same OIDs are used to identify DSA.Verify(). Additionally, since the same OIDs are used to identify
the ML-DSA public keys and ML-DSA signature algorithms, an the ML-DSA public keys and ML-DSA signature algorithms, an
implementation would need to commit a given public key to be either 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. of type ML-DSA or HashML-DSA at the time of certificate creation.
This is anticipated to cause operational issues in contexts where the This is anticipated to cause operational issues in contexts where the
operator does not know whether the key will need to produce pure or operator does not know whether the key will need to produce pure or
pre-hashed signatures at key generation time. The External μ (mu) pre-hashed signatures at key-generation time. The External "μ"
mode described in Appendix D avoids all of these operational (GREEK SMALL LETTER MU, U+03BC) mode described in Appendix D avoids
concerns. all of these operational concerns.
A minor security reason for disallowing HashML-DSA is that the design A minor security reason for disallowing HashML-DSA is that the design
of the ML-DSA algorithm provides enhanced resistance against of the ML-DSA algorithm provides enhanced resistance against
collision attacks, compared with HashML-DSA or conventional RSA or collision attacks, compared with HashML-DSA or conventional RSA or
ECDSA signature algorithms. Specifically, ML-DSA prepends the ECDSA signature algorithms. Specifically, ML-DSA prepends the
SHAKE256 hash of the public key (tr) to the message to-be-signed 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]. prior to hashing, as described in line 6 of Algorithm 7 of [FIPS204].
This means that in the unlikely discovery of a collision attack This means that in the unlikely discovery of a collision attack
against the SHA-3 family, an attacker would have to perform a public- against the SHA-3 family, an attacker would have to perform a public-
key-specific collision search in order to find message pairs such 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) = 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 = H(m2) will not suffice. HashML-DSA removes this enhanced security
property. In spite of its lack of targeted collision protection, the property. In spite of its lack of targeted collision protection, the
practical security risk of using HashML-DSA in X.509 signatures would practical security risk of using HashML-DSA in X.509 signatures would
be immaterial. That is because a hash of the issuing CA's public key be immaterial. This is because a hash of the issuing CA's public key
is already included in the Authority Key Identifier (AKI) extension is already included in the Authority Key Identifier (AKI) extension,
which is signed as part of the tbsCertificate structure. Even when 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 it is a SHA-1 hash, general second pre-images against the AKI hash of
existing issuing CAs would be impractical. existing issuing CAs would be impractical.
9. Security Considerations 9. Security Considerations
The Security Considerations section of [RFC5280] applies to this The Security Considerations section of [RFC5280] applies to this
specification as well. specification as well.
The ML-DSA signature scheme is strongly unforgeable under chosen The ML-DSA signature scheme is strongly unforgeable under chosen
message attacks (SUF-CMA). For the purpose of estimating security message attacks (SUF-CMA). For the purpose of estimating security
strength, it has been assumed that the attacker has access to strength, it has been assumed that the attacker has access to
signatures for no more than 2^{64} chosen messages. signatures for no more than 2^{64} chosen messages.
ML-DSA depends on high quality random numbers that are suitable for ML-DSA depends on high quality random numbers that are suitable for
use in cryptography. The use of inadequate pseudo-random number use in cryptography. The use of inadequate pseudo-random number
generators (PRNGs) to generate such values can significantly generators (PRNGs) to generate such values can significantly
undermine various security properties. For instance, using an undermine various security properties. For instance, using an
inadequate PRNG for key generation, might allow an attacker to inadequate PRNG for key generation might allow an attacker to
efficiently recover the private key by trying a small set of efficiently recover the private key by trying a small set of
possibilities, rather than brute force search the whole keyspace. possibilities, rather than brute-force searching the whole keyspace.
The generation of random numbers of a sufficient level of quality for 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 use in cryptography is difficult; see Section 3.6.1 of [FIPS204] for
some additional information. some additional information.
In the design of ML-DSA, care has been taken to make side-channel 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 resilience easier to achieve. For instance, ML-DSA does not depend
on Gaussian sampling. Implementations must still take great care not on Gaussian sampling. Implementations must still take great care not
to leak information via various side channels. While deliberate to leak information via various side channels. While deliberate
design decisions such as these can help to deliver a greater ease of design decisions such as these can help to deliver a secure
secure implementation - particularly against side-channel attacks - implementation with greater ease -- particularly against side-channel
it does not necessarily provide resistance to more powerful attacks attacks -- it does not necessarily provide resistance to more
such as differential power analysis. Some amount of side-channel powerful attacks such as differential power analysis. Some amount of
leakage has been demonstrated in parts of the signing algorithm side-channel leakage has been demonstrated in parts of the signing
(specifically the bit-unpacking function), from which a demonstration algorithm (specifically the bit-unpacking function), from which a
of key recovery has been made over a large sample of signatures. demonstration of key recovery has been made over a large sample of
Masking countermeasures exist for ML-DSA, but come with a performance signatures. Masking countermeasures exist for ML-DSA, but comes with
overhead. performance overhead.
ML-DSA offers both deterministic and randomized signing. Signatures ML-DSA offers both deterministic and randomized signing. Signatures
generated with either mode are compatible and a verifyer can't tell generated with either mode are compatible and a verifier cannot tell
them apart. In the deterministic case, a signature only depends on them apart. In the deterministic case, a signature only depends on
the private key and the message to be signed. This makes the the private key and the message to be signed. This makes the
implementation easier to test and does not require a randomness implementation easier to test and does not require a randomness
source during signing. In the randomized case, signing mixes in a source during signing. In the randomized case, signing mixes in a
256-bit random string from an approved random bit generator (RBG). 256-bit random string from an approved random bit generator (RBG).
When randomized, ML-DSA is easier to harden against fault and When randomized, ML-DSA is easier to harden against fault and
hardware side-channel attacks. hardware side-channel attacks.
A security property also associated with digital signatures is non- A security property that is also associated with digital signatures
repudiation. Non-repudiation refers to the assurance that the owner is non-repudiation. Non-repudiation refers to the assurance that the
of a signature key pair that was capable of generating an existing owner of a signature keypair that was capable of generating an
signature corresponding to certain data cannot convincingly deny existing signature corresponding to certain data cannot convincingly
having signed the data, unless its private key was compromised. The deny having signed the data, unless its private key was compromised.
digital signature scheme ML-DSA possess three security properties The digital signature scheme ML-DSA possesses three security
beyond unforgeability, that are associated with non-repudiation. properties beyond unforgeability, that are associated with non-
These are exclusive ownership, message-bound signatures, and non- repudiation. These are exclusive ownership, message-bound
resignability. These properties are based tightly on the assumed signatures, and non-resignability. These properties are based
collision resistance of the hash function used (in this case SHAKE- tightly on the assumed collision resistance of the hash function used
256). A full discussion of these properties in ML-DSA can be found (in this case SHAKE-256). A full discussion of these properties in
at [CDFFJ21]. ML-DSA can be found at [CDFFJ21].
10. References 10. References
10.1. Normative References 10.1. Normative References
[CSOR] NIST, "Computer Security Objects Register", 20 August [CSOR] NIST, "Computer Security Objects Register (CSOR)", 13 June
2024, <https://csrc.nist.gov/projects/computer-security- 2025, <https://csrc.nist.gov/projects/computer-security-
objects-register/algorithm-registration>. objects-register/algorithm-registration>.
[FIPS204] "Module-lattice-based digital signature standard", [FIPS204] NIST, "Module-Lattice-Based Digital Signature Standard",
National Institute of Standards and Technology (U.S.), NIST FIPS 204, DOI 10.6028/NIST.FIPS.204, 13 August 2024,
DOI 10.6028/nist.fips.204, August 2024, <https://nvlpubs.nist.gov/nistpubs/FIPS/
<https://doi.org/10.6028/nist.fips.204>. NIST.FIPS.204.pdf>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
DOI 10.17487/RFC5912, June 2010, DOI 10.17487/RFC5912, June 2010,
<https://www.rfc-editor.org/rfc/rfc5912>. <https://www.rfc-editor.org/info/rfc5912>.
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958,
DOI 10.17487/RFC5958, August 2010, DOI 10.17487/RFC5958, August 2010,
<https://www.rfc-editor.org/rfc/rfc5958>. <https://www.rfc-editor.org/info/rfc5958>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[X680] ITU-T, "Information Technology -- Abstract Syntax Notation [X680] ITU-T, "Information Technology -- Abstract Syntax Notation
One (ASN.1): Specification of basic notation", ITU-T One (ASN.1): Specification of basic notation", ITU-T
Recommendation X.680, ISO/IEC 8824-1:2021, February 2021, Recommendation X.680, ISO/IEC 8824-1:2021, February 2021,
<https://www.itu.int/rec/T-REC-X.680>. <https://www.itu.int/rec/T-REC-X.680>.
[X690] ITU-T, "Information Technology -- Abstract Syntax Notation [X690] ITU-T, "Information Technology -- ASN.1 encoding rules:
One (ASN.1): ASN.1 encoding rules: Specification of Basic Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (BER), Canonical Encoding Rules (CER) and Encoding Rules (CER) and Distinguished Encoding Rules
Distinguished Encoding Rules (DER)", ITU-T (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1:2021,
Recommendation X.690, ISO/IEC 8825-1:2021, February 2021, February 2021, <https://www.itu.int/rec/T-REC-X.690>.
<https://www.itu.int/rec/T-REC-X.690>.
10.2. Informative References 10.2. Informative References
[CDFFJ21] Cremers, C., Düzlü, S., Fiedler, R., Fischlin, M., and C. [CDFFJ21] Cremers, C., Düzlü, S., Fiedler, R., Fischlin, M., and C.
Janson, "BUFFing signature schemes beyond unforgeability Janson, "BUFFing signature schemes beyond unforgeability
and the case of post-quantum signatures", In Proceedings and the case of post-quantum signatures", Cryptology
of the 42nd IEEE Symposium on Security and Privacy , 2021, ePrint Archive, Paper 2020/1525, October 2023,
<https://eprint.iacr.org/2020/1525.pdf>. <https://eprint.iacr.org/
archive/2020/1525/20231023:114351>.
[Dilithium] [Dilithium]
Bai, S., Ducas, L., Lepoint, T., Lyubashevsky, V., Bai, S., Ducas, L., Kiltz, E., Lepoint, T., Lyubashevsky,
Schwabe, P., Seiler, G., and D. Stehlé, "CRYSTALS- V., Schwabe, P., Seiler, G., and D. Stehlé, "CRYSTALS-
Dilithium Algorithm Specifications and Supporting Dilithium Algorithm Specifications and Supporting
Documentation", 2021, <https://pq- Documentation (Version 3.1)", 8 February 2021,
crystals.org/dilithium/data/dilithium-specification- <https://pq-crystals.org/dilithium/data/dilithium-
round3-20210208.pdf>. specification-round3-20210208.pdf>.
[Fiat-Shamir] [Fiat-Shamir]
Lyubashevsky, V., "Fiat-Shamir with aborts: Applications Lyubashevsky, V., "Fiat-Shamir with aborts: Applications
to lattice and factoring-based signatures", International to lattice and factoring-based signatures", International
Conference on the Theory and Application of Cryptology and Conference on the Theory and Application of Cryptology and
Information Security , 2009, Information Security, 2009, <https://www.iacr.org/archive/
<https://www.iacr.org/archive/
asiacrypt2009/59120596/59120596.pdf>. asiacrypt2009/59120596/59120596.pdf>.
[FIPS204-ExternalMuFAQ] [FIPS204-ExternalMuFAQ]
National Institute of Standards and Technology (NIST), NIST, "FIPS 204 Section 6 FAQ", 2025,
"FIPS 204 Section 6 FAQ", 2025,
<https://csrc.nist.gov/csrc/media/Projects/post-quantum- <https://csrc.nist.gov/csrc/media/Projects/post-quantum-
cryptography/documents/faq/fips204-sec6-03192025.pdf>. cryptography/documents/faq/fips204-sec6-03192025.pdf>.
[NIST-PQC] National Institute of Standards and Technology (NIST), [NIST-PQC] NIST, "Post-Quantum Cryptography (PQC)", 28 July 2025,
"Post-Quantum Cryptography Project", 20 December 2016,
<https://csrc.nist.gov/Projects/post-quantum- <https://csrc.nist.gov/Projects/post-quantum-
cryptography>. cryptography>.
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
Wu, "Internet X.509 Public Key Infrastructure Certificate Wu, "Internet X.509 Public Key Infrastructure Certificate
Policy and Certification Practices Framework", RFC 3647, Policy and Certification Practices Framework", RFC 3647,
DOI 10.17487/RFC3647, November 2003, DOI 10.17487/RFC3647, November 2003,
<https://www.rfc-editor.org/rfc/rfc3647>. <https://www.rfc-editor.org/info/rfc3647>.
[RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX,
PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468,
April 2015, <https://www.rfc-editor.org/rfc/rfc7468>. April 2015, <https://www.rfc-editor.org/info/rfc7468>.
Appendix A. ASN.1 Module Appendix A. ASN.1 Module
This appendix includes the ASN.1 module [X680] for the ML-DSA. Note This appendix includes the ASN.1 module [X680] for the ML-DSA. Note
that as per [RFC5280], certificates use the Distinguished Encoding that as per [RFC5280], certificates use the Distinguished Encoding
Rules; see [X690]. This module imports objects from [RFC5912]. Rules; see [X690]. This module imports objects from [RFC5912].
<CODE BEGINS> <CODE BEGINS>
X509-ML-DSA-2025 X509-ML-DSA-2025
{ iso(1) identified-organization(3) dod(6) { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-x509-ml-dsa-2025(TBD1) } id-mod-x509-ml-dsa-2025(119) }
DEFINITIONS IMPLICIT TAGS ::= BEGIN DEFINITIONS IMPLICIT TAGS ::= BEGIN
EXPORTS ALL; EXPORTS ALL;
IMPORTS IMPORTS
PUBLIC-KEY, SIGNATURE-ALGORITHM PUBLIC-KEY, SIGNATURE-ALGORITHM
FROM AlgorithmInformation-2009 -- [RFC 5912] FROM AlgorithmInformation-2009 -- [RFC 5912]
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58) } ; id-mod-algorithmInformation-02(58) } ;
-- --
-- ML-DSA Identifiers -- ML-DSA Identifiers
skipping to change at page 19, line 41 skipping to change at line 871
PUBLIC-KEYS { pk-ml-dsa-65 } PUBLIC-KEYS { pk-ml-dsa-65 }
SMIME-CAPS { IDENTIFIED BY id-ml-dsa-65 } SMIME-CAPS { IDENTIFIED BY id-ml-dsa-65 }
} }
sa-ml-dsa-87 SIGNATURE-ALGORITHM ::= { sa-ml-dsa-87 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-ml-dsa-87 IDENTIFIER id-ml-dsa-87
PARAMS ARE absent PARAMS ARE absent
PUBLIC-KEYS { pk-ml-dsa-87 } PUBLIC-KEYS { pk-ml-dsa-87 }
SMIME-CAPS { IDENTIFIED BY id-ml-dsa-87 } SMIME-CAPS { IDENTIFIED BY id-ml-dsa-87 }
} }
END END
<CODE ENDS> <CODE ENDS>
Appendix B. Security Strengths Appendix B. Security Strengths
Instead of defining the strength of a quantum algorithm in a Instead of defining the strength of a quantum algorithm using the
traditional manner using the imprecise notion of bits of security, common but imprecise notion of bits of security, NIST has instead
NIST has instead elected to define security levels by picking a elected to define security levels by picking a reference scheme,
reference scheme, which NIST expects to offer notable levels of which NIST expects to offer notable levels of resistance to both
resistance to both quantum and classical attack. To wit, an quantum and classical attacks. To wit, an algorithm that achieves
algorithm that achieves NIST PQC security level 1 must require NIST PQC security level 1 must require computational resources to
computational resources to break the relevant security property, break the relevant security property, which are greater than those
which are greater than those required for a brute-force key search on required for a brute-force key search on AES-128. Levels 3 and 5 use
AES-128. Levels 3 and 5 use AES-192 and AES-256 as reference AES-192 and AES-256 as references, respectively. Levels 2 and 4 use
respectively. Levels 2 and 4 use collision search for SHA-256 and collision search for SHA-256 and SHA-384 as references.
SHA-384 as reference.
The parameter sets defined for NIST security levels 2, 3 and 5 are The parameter sets defined for NIST security levels 2, 3, and 5 are
listed in the Figure 1, along with the resulting signature size, listed in Figure 1, along with the resulting signature size, public
public key, and private key sizes in bytes. Note that these are the key, and private key sizes in bytes. Note that these are the sizes
sizes of the raw keys, not including ASN.1 encoding overhead from of the raw keys, not including ASN.1 encoding overhead from
OneAsymmetricKey and SubjectPublicKeyInfo wrappers. Private key OneAsymmetricKey and SubjectPublicKeyInfo wrappers. Private key
sizes are shown for both the seed format and expanded format. sizes are shown for both the seed format and expanded format.
|=======+=======+=====+========+========+==========+==========| +=======+=======+=====+==========+========+=========+===========+
| Level | (k,l) | eta | Sig. | Public | Private | Private | | Level | (k,l) | eta | Sig. (B) | Public | Private | Private |
| | | | (B) | Key(B) | Seed(B) | Expand(B)| | | | | | Key(B) | Seed(B) | Expand(B) |
|=======+=======+=====+========+========+==========+==========| +=======+=======+=====+==========+========+=========+===========+
| 2 | (4,4) | 2 | 2420 | 1312 | 32 | 2560 | | 2 | (4,4) | 2 | 2420 | 1312 | 32 | 2560 |
| 3 | (6,5) | 4 | 3309 | 1952 | 32 | 4032 | +-------+-------+-----+----------+--------+---------+-----------+
| 5 | (8,7) | 2 | 4627 | 2592 | 32 | 4896 | | 3 | (6,5) | 4 | 3309 | 1952 | 32 | 4032 |
|=======+=======+=====+========+========+==========+==========| +-------+-------+-----+----------+--------+---------+-----------+
| 5 | (8,7) | 2 | 4627 | 2592 | 32 | 4896 |
+-------+-------+-----+----------+--------+---------+-----------+
Figure 1: ML-DSA Parameters Table 2: ML-DSA Parameters
Appendix C. Examples Appendix C. Examples
This appendix contains examples of ML-DSA private keys, public keys, This appendix contains examples of ML-DSA private keys, public keys,
certificates, and inconsistent seed and expanded private keys. certificates, and inconsistent seed and expanded private keys.
C.1. Example Private Keys C.1. Example Private Keys
The following examples show ML-DSA private keys in different formats, The following examples show ML-DSA private keys in different formats,
all derived from the same seed 000102...1e1f. For each security all derived from the same seed 000102...1e1f. For each security
level, we show the seed-only format (using a context-specific [0] level, we show the seed-only format (using a context-specific [0]
primitive tag with an implicit encoding of OCTET STRING), the primitive tag with an implicit encoding of OCTET STRING), the
expanded format, and both formats together. expanded format, and both formats together.
NOTE: All examples use the same seed value, showing how the same seed | NOTE: All examples use the same seed value, showing how the
produces different expanded private keys for each security level. | same seed produces different expanded private keys for each
| security level.
C.1.1. ML-DSA-44 Private Key Examples C.1.1. ML-DSA-44 Private Key Examples
Each of the examples includes the textual encoding [RFC7468] followed Each of the examples includes the textual encoding [RFC7468] followed
by the so-called "pretty print"; the private keys are the same. by the so-called "pretty print"; the private keys are the same.
C.1.1.1. Seed Format C.1.1.1. Seed Format
-----BEGIN PRIVATE KEY----- -----BEGIN PRIVATE KEY-----
MDQCAQAwCwYJYIZIAWUDBAMRBCKAIAABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZ MDQCAQAwCwYJYIZIAWUDBAMRBCKAIAABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZ
skipping to change at page 82, line 38 skipping to change at line 3814
8c60f8ed3bf2766de6374342014c5d8c72a9a9d981ce6c7069f75f843fb97819 8c60f8ed3bf2766de6374342014c5d8c72a9a9d981ce6c7069f75f843fb97819
d104a584f12b1a3b480b9fd774052b698259368ea5bb7af675809421fa3ac6e9 d104a584f12b1a3b480b9fd774052b698259368ea5bb7af675809421fa3ac6e9
feebe427a13ece5e96fe85cd382b2e10607ab911877ad07e74a200621d3cc2d9 feebe427a13ece5e96fe85cd382b2e10607ab911877ad07e74a200621d3cc2d9
02dca836e92b8ae754b483a8a91b80a0b0c113c48b0f1253c599bb9cf01bdca0 02dca836e92b8ae754b483a8a91b80a0b0c113c48b0f1253c599bb9cf01bdca0
5112c6378a1b2de49053c507c82b5e11b6e91abb2d5e90000000000000000000 5112c6378a1b2de49053c507c82b5e11b6e91abb2d5e90000000000000000000
0000000000000000000000000000000000000000000040c12151d1e252c` } 0000000000000000000000000000000000000000000040c12151d1e252c` }
} }
C.4. Example Inconsistent Seed and Expanded Private Keys C.4. Example Inconsistent Seed and Expanded Private Keys
| WARNING: These private keys are purposely bad do not use them | WARNING: These private keys are purposely bad; do not use them
| in production systems. | in production systems.
The following examples demonstrate inconsistent seed and expanded The following examples demonstrate inconsistent seed and expanded
private keys. private keys.
Three ML-DSA-44-PrivateKey examples of inconsistent seed and expanded Three ML-DSA-44-PrivateKey examples of inconsistent seed and expanded
private keys follow: private keys follow:
1. The first ML-DSA-PrivateKey example includes the both CHOICE , 1. The first ML-DSA-PrivateKey example includes the both CHOICE ,
i.e., both seed and expandedKey are included. The seed and i.e., both seed and expandedKey are included. The seed and
expanded values can be checked for inconsistencies. expandedKey values can be checked for inconsistencies.
2. The second ML-DSA-PrivateKey example includes only expandedKey. 2. The second ML-DSA-PrivateKey example includes only expandedKey.
The public key fails to match the tr hash value in the private The public key fails to match the tr hash value in the private
key. key.
3. The third ML-DSA-PrivateKey example also includes only 3. The third ML-DSA-PrivateKey example also includes only
expandedKey. The private s_1 and s_2 vectors imply a t vector 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 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 private key (its high bits t_1 are the primary content of the
public key). public key).
The second and third examples would not be detected by The second and third examples would not be detected by
implementations that do not regenerate the public key from the implementations that do not regenerate the public key from the
private key, or neglect to then check consistency of tr or t_0. private key or, when they do, they neglect to check consistency of tr
and t_0.
The following is the first example: The following is the first example:
-----BEGIN PRIVATE KEY----- -----BEGIN PRIVATE KEY-----
MIIKPgIBADALBglghkgBZQMEAxEEggoqMIIKJgQgAAECAwQFBgcICQoLDA0ODxAR MIIKPgIBADALBglghkgBZQMEAxEEggoqMIIKJgQgAAECAwQFBgcICQoLDA0ODxAR
EhMUFRYXGBkaGxwdHh8EggoAUQyb/R3XN09Oiucd1YKBEGqTQS7Y+jV/dLu0Zh7L EhMUFRYXGBkaGxwdHh8EggoAUQyb/R3XN09Oiucd1YKBEGqTQS7Y+jV/dLu0Zh7L
GSHTp1/JO4jvDmqbhRvs7BmZm+gQaMhZ1t8RXGCMFQEXDrbAVcIvYlWSSXbYlaX1 GSHTp1/JO4jvDmqbhRvs7BmZm+gQaMhZ1t8RXGCMFQEXDrbAVcIvYlWSSXbYlaX1
TSw4WWxAPM72+XPiKl+MfCuoNjNEcJCniyK7Qc/e2vvLLt7PkHDM5hLkKrCh8T65 TSw4WWxAPM72+XPiKl+MfCuoNjNEcJCniyK7Qc/e2vvLLt7PkHDM5hLkKrCh8T65
3DwUkDGJwoHgsDHalISCEgijtDDSKEoEByDDRELgQC5EoHEBqSwDJmQSQSQYMiQA 3DwUkDGJwoHgsDHalISCEgijtDDSKEoEByDDRELgQC5EoHEBqSwDJmQSQSQYMiQA
Ii5KlmALGZAiMyBShkUbCEyTGIQZAG1TgAwQpChQBgogBgwjETLSxEDSEgIENIYj Ii5KlmALGZAiMyBShkUbCEyTGIQZAG1TgAwQpChQBgogBgwjETLSxEDSEgIENIYj
skipping to change at page 87, line 5 skipping to change at line 4020
M2EBp3LL5PVxUj9RvQWILN81i4ScwUCqH68iQjoShRzg4z/UiXWklZ+lxf5BjJOQ M2EBp3LL5PVxUj9RvQWILN81i4ScwUCqH68iQjoShRzg4z/UiXWklZ+lxf5BjJOQ
gZGrbnQbd7/gLL1pjueVxGbWFWGeZEE4LG6sAYNO6atzzqgLviNceNqRvXm2+C+J gZGrbnQbd7/gLL1pjueVxGbWFWGeZEE4LG6sAYNO6atzzqgLviNceNqRvXm2+C+J
l4XWhwDTk+Z1wiJNa3oa0hMgSVZ5ra7XAWe1CGZxOlMQnbe299gTBOzf2Dsxmx7y l4XWhwDTk+Z1wiJNa3oa0hMgSVZ5ra7XAWe1CGZxOlMQnbe299gTBOzf2Dsxmx7y
SDBrRa0p593Mhj2sVgSLXWnqF1AR92FMAKhqhjzeGHKokyh4uax+GsW9pJl7cgZP SDBrRa0p593Mhj2sVgSLXWnqF1AR92FMAKhqhjzeGHKokyh4uax+GsW9pJl7cgZP
DNdfTIFOA03hGsuQE89+qSa05+qs4HDHuiGI760uQx4SI9Rd0FxNhAPC5FzuZBPs DNdfTIFOA03hGsuQE89+qSa05+qs4HDHuiGI760uQx4SI9Rd0FxNhAPC5FzuZBPs
vnUn6HPkVcTmEKYYOarMC9VtJIPnjymLZqR46y9VjLr8qGvoR7rrAsWyFsjNiP6k vnUn6HPkVcTmEKYYOarMC9VtJIPnjymLZqR46y9VjLr8qGvoR7rrAsWyFsjNiP6k
3ySbCeZwogcDq6wksKkavEpWRmAUQroQvs/TCZOIAFHQf1agWpN556jmvv7j8i+q 3ySbCeZwogcDq6wksKkavEpWRmAUQroQvs/TCZOIAFHQf1agWpN556jmvv7j8i+q
EGOY93BgBuQum+HvidJcJy8RqVCVxYfXE3MihN6dvTxyF7BoniHY6w/2lmg= EGOY93BgBuQum+HvidJcJy8RqVCVxYfXE3MihN6dvTxyF7BoniHY6w/2lmg=
-----END PRIVATE KEY----- -----END PRIVATE KEY-----
Appendix D. Pre-hashing (Externalμ-ML-DSA) Appendix D. Pre-Hashing (Externalμ-ML-DSA)
Some applications require pre-hashing that ease operational Some applications require pre-hashing that ease operational
requirements around large or inconsistently-sized payloads. When requirements around large or inconsistently-sized payloads. When
signing with pre-hashing, the signature generation process can be signing with pre-hashing, the signature-generation process can be
separated into a pre-hash step requiring only the message and other separated into a pre-hash step requiring only the message and other
public information, and a core signature step which uses the public public information, and a core signature step that uses the public
key. key.
In the context of ML-DSA, pre-hashing can be performed with the 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 HashML-DSA algorithm defined in Section 5.4 of [FIPS204]. ML-DSA
itself supports a External μ pre-hashing mode which externalizes the itself supports an External μ pre-hashing mode, which externalizes
message pre-hashing originally performed inside the signing the message pre-hashing originally performed inside the signing
operation. This mode is also laid out in [FIPS204-ExternalMuFAQ]. operation. This mode is also laid out in [FIPS204-ExternalMuFAQ].
This document specifies only the use of ML-DSA's External μ mode, and 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. not HashML-DSA, in PKIX for reasons laid out in Section 8.3.
Implementations of ML-DSA using the External μ pre-hashing mode Implementations of ML-DSA using the External μ pre-hashing mode
requires the following algorithms, which are modified versions of the requires the following algorithms, which are modified versions of the
algorithms presented in [FIPS204]. The nomenclature used here has algorithms presented in [FIPS204]. The nomenclature used here has
been modified from the NIST FAQ [FIPS204-ExternalMuFAQ] for clarity. been modified from the NIST FAQ [FIPS204-ExternalMuFAQ] for clarity.
Pre-hash operation: Pre-hash operation:
Computeμ(pk, M, ctx): Computeμ(pk, M, ctx):
# Referred to as 'Externalμ-ML-DSA.Prehash(pk, M, ctx)' # Referred to as 'ExternalMu-ML-DSA.Prehash(pk, M, ctx)'
# in the FIPS 204 FAQ. # in the FIPS 204 FAQ.
# M is the message, a bit-string # M is the message, a bit-string
# μ and ctx are byte-strings. # μ and ctx are byte-strings.
# ctx is the context string, which defaults to the empy string. # ctx is the context string, which defaults to the empty string.
μ = H(BytesToBits(H(pk, 64) || IntegerToBytes(0, 1) || μ = H(BytesToBits(H(pk, 64) || IntegerToBytes(0, 1) ||
IntegerToBytes(|ctx|, 1) || ctx) || M, 64) IntegerToBytes(|ctx|, 1) || ctx) || M, 64)
# The functions `BytesToBits` and `IntegerToBytes` are defined in FIPS 204. # The functions `BytesToBits` and `IntegerToBytes` are defined
return μ # in FIPS 204.
return μ
Figure 2: Computeμ prehash operation Figure 1: Computeμ Pre-Hash Operation
Sign operations: Sign operations:
Signμ(sk, μ): Signμ(sk, μ):
# Referred to as 'Externalμ-ML-DSA.Sign(sk, μ)' # Referred to as 'ExternalMu-ML-DSA.Sign(sk, mu)'
# in the FIPS 204 FAQ. # in the FIPS 204 FAQ.
if |μ| != 64 then if |μ| != 64 then
return error # return an error indication if the input μ is not return error # return an error indication if the input μ is not
# 64 bytes. # 64 bytes.
end if end if
rnd = rand(32) # for the optional deterministic variant, rnd = rand(32) # for the optional deterministic variant,
# set rnd to all zeroes # set rnd to all zeroes
if rnd = NULL then if rnd = NULL then
return error # return an error indication if random bit return error # return an error indication if random bit
# generation failed # generation failed
end if end if
sigma = Signμ_internal(sk, μ, rnd, isExternalμ=true) sigma = Signμ_internal(sk, μ, rnd, isExternalμ=true)
return sigma return sigma
ML-DSA.Signμ_internal(sk, M', rnd, isExternalμ=false): ML-DSA.Signμ_internal(sk, M', rnd, isExternalμ=false):
# μ can be passed as an argument instead of M' # μ is passed to the function via the argument M'.
# defaulting is Externalμ to false means that # Defaulting Externalμ to false means that
# this modified version of Sign_internal can be used # this modified version of Sign_internal can be used
# in place of the original without interfering with # in place of the original without interfering with
# functioning of pure ML-DSA mode. # 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)
Figure 3: The operations for signing μ # ... identical to FIPS 204 Algorithm 7, but with Line 6
# replaced with
6: if (isExternalμ):
μ = M'
else:
μ = H(BytesToBits(tr) || M', 64)
Figure 2: The Operations for Signing μ
There is no need to specify an External μ Verify() routine because There is no need to specify an External μ Verify() routine because
this is identical to the original ML-DSA.Verify(). This makes this is identical to the original ML-DSA.Verify(). This makes
External μ mode simply an internal optimization of the signer, and External μ mode simply an internal optimization of the signer, and
allows an ML-DSA key to sometimes be used with the "one-shot" Sign() allows an ML-DSA key to sometimes be used with the "one-shot" Sign()
API and sometimes the External μ API without any interoperability API and to sometimes be used with the External μ API without any
concens. interoperability concerns.
The External μ mode requires the Computeμ routine to have access to 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 the hash of the signer's public key, which may not be available in
some architectures, or require fetching it. That may allow for some architectures, or require fetching it. That may allow for
mismatches between tr and sk. At worst, this will produce a mismatches between tr and sk. At worst, this will produce a
signature which will fail to verify under the intended public key signature that will fail to verify under the intended public key
since a compliant Verify() routine will independently compute tr from since a compliant Verify() routine will independently compute tr from
the public key. That is not believed to be a security concern since 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 μ is never used as-is within ML-DSA.Sign_internal() (Algorithm 7 in
[FIPS204]). Rather, it is hashed with values unknown to an attacker [FIPS204]). Rather, it is hashed with values unknown to an attacker
on lines 7 and 15. Thus, a signing oracle exposing Signμ() does not 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 leak any bits of the secret key. The External μ mode also requires
SHAKE256 to be available to the Computeμ routine. SHAKE256 to be available to the Computeμ routine.
Acknowledgments Acknowledgments
The authors wish to thank the following people for their The authors wish to thank the following people for their
contributions to this document: Corey Bonnell, Dierdre Connolly, contributions to this document: Corey Bonnell, Dierdre Connolly,
Viktor Dukhovni, Russ Housley, Alicja Kario, Mike Ounsworth, and Viktor Dukhovni, Russ Housley, Alicja Kario, Mike Ounsworth, and
Daniel Van Geest. Daniel Van Geest.
In addition, we would like to thank those who contributed to the In addition, we would like to thank those who contributed to the
private key format discussion: Tony Arcieri, Bob Beck, Dmitry private key format discussion: Tony Arcieri, Bob Beck, Dmitry
Belyavskiy, David Benjamin, Daniel Bernstein, Uri Blumenthal, Theo Belyavskiy, David Benjamin, Daniel Bernstein, Uri Blumenthal, Theo
Buehler, Stephen Farrell, Jean-Pierre Fiset, Scott Fluhrer, Alex Buehler, Stephen Farrell, Jean-Pierre Fiset, Scott Fluhrer, Alex
Gaynor, John Gray, Peter Gutmann, David Hook, Tim Hudson, Paul Gaynor, John Gray, Peter Gutmann, David Hook, Tim Hudson, Paul
Kehrer, John Kemp, Watson Ladd, Adam Langley, John Mattsson, Damien Kehrer, John Kemp, Watson Ladd, Adam Langley, John Mattsson, Damien
Miller, Robert Relyea, Michael Richardson, Markku-Juhani O. Miller, Robert Relyea, Michael Richardson, Markku-Juhani O. Saarinen,
Saarinen, Rich Salz, Roland Shoemaker, Sophie Schmieg, Simo Sorce, Rich Salz, Roland Shoemaker, Sophie Schmieg, Simo Sorce, Michael
Michael St. Johns, Falko Strenzke, Filippo Valsorda, Loganaden St. Johns, Falko Strenzke, Filippo Valsorda, Loganaden Velvindron,
Velvindron, Carl Wallace, and Wei-Jun Wang. Carl Wallace, and Wei-Jun Wang.
Authors' Addresses Authors' Addresses
Jake Massimo Jake Massimo
AWS AWS
United States of America United States of America
Email: jakemas@amazon.com Email: jakemas@amazon.com
Panos Kampanakis Panos Kampanakis
AWS AWS
 End of changes. 89 change blocks. 
294 lines changed or deleted 289 lines changed or added

This html diff was produced by rfcdiff 1.48.