```
```USA

```
```jakemas@amazon.com

```
```

```
```
AWS
```
```USA

```
```kpanos@amazon.com

```
```

```
```
sn3rd
sean@sn3rd.com
Cloudflare
bas@westerbaan.name
Security
LAMPS WG
PQ Signatures, post-quantum X.509
Digital signatures are used within X.509 certificates, Certificate Revocation Lists (CRLs),
and to sign messages. This document describes the conventions for using the
Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates
and certificate revocation lists. The conventions for the associated signatures, subject
public keys, and private key are also described.
[EDNOTE: This draft is not expected to be finalized before the NIST PQC Project has standardized
FIPS 204 Module-Lattice-Based Digital Signature Standard. The current FIPS draft was
published August 24, 2023 for public review. Final versions are expected by April 2024. This
specification will use object identifiers for the new algorithms that are assigned by NIST,
and will use placeholders until these are released.]

```
```
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
in . 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.
This specification includes conventions for the signatureAlgorithm, signatureValue,
signature, and subjectPublicKeyInfo fields within Internet X.509 certificates and
CRLs for ML-DSA, like
did for classic cryptography and
did for elliptic curve cryptography.
The private key format is also specified.
ASN.1 Moudule and ML-DSA Identifiers
An ASN.1 module is included for reference purposes. Note that as per ,
certificates use the Distinguished Encoding Rules; see . Also note that NIST
defined the object identifiers for the ML-DSA algorithms in an ASN.1 module; see
(TODO insert reference).
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
when, and only when, they appear in all capitals, as shown here.
Identifiers
The AlgorithmIdentifier type, which is included herein for convenience, is defined 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) TBD }
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) TBD }
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) TBD }
The contents of the parameters component for each algorithm MUST be absent.
ML-DSA Signatures in PKIX
ML-DSA is a digital signature scheme built upon the Fiat-Shamir-with-aborts framework
. The security is based upon
the hardness of lattice problems over module lattices .
ML-DSA provides three parameter sets for the 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
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 ::= SEQUENCE {
tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING }
Signatures are also used in the CRL list ASN.1 representation from
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 ::= SEQUENCE {
tbsCertList TBSCertList,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING }
The identifiers defined in 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,
. The parameters of these signature algorithms MUST be absent,
as explained in .
The signatureValue field contains the corresponding ML-DSA signature computed upon the ASN.1 DER encoded
tbsCertificate/tbsCertList .
Conforming Certification Authority (CA) implementations MUST specify the algorithms explicitly
by using the OIDs specified in
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 .
When the id-ML-DSA identifier appears in the algorithm field as an AlgorithmIdentifier, the encoding MUST
omit the parameters field. That is, the AlgorithmIdentifier SHALL be a SEQUENCE of one component,
the OID id-ML-DSA.
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 ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING
}
The fields in SubjectPublicKeyInfo have the following meanings:
- algorithm is the algorithm identifier and parameters for the public key (see above).
- subjectPublicKey contains the byte stream of the public key. The algorithms defined in this document always encode
the public key as TODO.

The public parameters for ML-DSA are based upon a polynomial ring R_q for prime q. A (k*l) public matrix A is produced,
consisting of polynomials whose coefficients are sampled uniformly at random from the integers modulo q. This
sampling is performed by expanding a nonce (rho) using an XOF.
The ML-DSA public key MUST be encoded using the ASN.1 type MLDSAPublicKey:
MLDSAPublicKey ::= OCTET STRING
where MLDSAPublicKey is a concatenation of rho and t1. Here, rho is the nonce used to seed the XOF to produce the
matrix A, and t1 is a vector encoded in 320*k bytes where k is the rank of the vector over the polynomial ring
R_q. These parameters MUST be encoded as a single OCTET STRING. The size required to hold a
MLDSAPublicKey public key element is therefore 32+320*k bytes.
The id-ML-DSA identifier defined in MUST be used as the algorithm field in the
SubjectPublicKeyInfo sequence to identify a ML-DSA public key.
The ML-DSA public key (a concatenation of rho and t1 that is an OCTET STRING) is mapped to a subjectPublicKey (a value
of type BIT STRING) as follows: the most significant bit of the OCTET STRING value becomes the most significant
bit of the BIT STRING value, and so on; the least significant bit of the OCTET STRING becomes the least significant
bit of the BIT STRING.
The following is an example of a ML-DSA-44 public key encoded using the textual encoding defined in
.
-----BEGIN PUBLIC KEY-----
MIIHtDANBgsrBgEEAQKCCwcGBQOCB6EAFyP2dnbMELz5lkTFG7YvOdqVF5km835e
UHXNaynmIrWHeKMla2gHZTCAwgLWIr9RAh1K11KRvFf+HYMs3ykOrd4xQ2vgLsjP
jU0bup+rgRK5gvm3Z37rm2jAXDzJNxeM5lEDTklz9BQwOdQGm1rI/MXeMGssnOG4
a9QvNPERdcG7VpTAEEevuTWmOeiKK3+kNCpoMRZr4WkgeInRyVUZXUvbYKkbm1Yj
2Mn2ZhgqFW4M1IJwq3LPDCAXZU9R0dTQCt9Ns04HQHNylARZya6TdW+F2k+pfZ3U
BRGbdI0MbVkOxqgRTfdWLlcXCfPn9/qdbz2K18QKdEuBBtPdZxiwTePDS6XvXjEp
KZg9bukd7Yxqhg+DPGQp+yQLW4H3lkOkq6mCNW2z86OVnja7xHYL8vAU8xDZ9IeL
oAIJm37X+qLOMIrT7qJE6zx2k+cJBnxBMSErEmOGOHb+dMvZyn8O77EyOSJS5pyn
70quzO8k+VieM8jc7ZJan3NUeC7F3Os45uAJzEa1ssKwMx+f4Dtz8GkSjjwCIdFA
fp6MNzek90lPKqJuxL37NGDB9scH6nLQOKpikaYkBYxD/huNtAe/e9MEHFlD1/Uz
bSWTN2qQ4UmdV7iJKtIvesDrzx7D6v5EUh9QGdt4D3dNI7NvdyOGrQXwMz8M1EOB
RX7QbAySLAkpGtpjcqkyiW0nOmslMtgI1JPM0bSzx1DuIaWjG/jf6HKpu2Ev2UlN
pYs8cMoFeHmJpzGUkGlFwE+nGysZOx708p98yDRrQyY/Fw6Qg1xzFle14CTqW86h
sD4K0scryDnETg3ZXpwhfQncYfxBbnIIyvxn2AnyGjy6h2r0b1SC8xzxWP7tGaSX
0H4sdGPvv1AIc6id4VhtrKZgau7JK24c4lqun3WgmZH3+/wyDeyf+Zrb8/DPK3N3
ZI4R+xkZDzSkuFWLh5om8MykaFT6TNmc5Hc1kO039tgz0vqXpsQHir+EiFPbugEp
JLoxmoCgdxy9RLvDkSjnDwyI4Hg1djp9nRhpTVjvMdoIw6dSyO11ilEwppm+dNIn
Gxd6iO7yaE2tJ6UjIc+7tuKoZkzmsO6p4hN8VKhzXcVjnRr6xox4sD5u3esqtJly
9lsMU0qZnqJU4jbBS3SQloj3m8pl4cdf/j6ZHNiAAnfX6hhUGZDetTEv7MICeSW0
b77XO5i4udTcYQtLvdo7mmyzG/N8NNR1T9pw89GYJ1maJhC2JyYx3Qwedppk0xac
BwWednYgQMMNEUKmAGoZxytTHtFfPhGQ4s7gZ6zw2CTiqAEGLfGj6lrwuBgXXAn+
S8B7UwF4b4ReCpwdYO1N5AyWXAax5T67H5a/5VkiX8zT5lX6+/bAqT8waLIImE3Q
bEK74kOgQvULbzLzVjqJYPiAF8RwPIWRxH8ocOAM+NG0pREiEgDlO0xrcW26PeIo
pGEsxOfiZRq1CLIRFn2FyczJQ8xFwC7fWio3q91+RGr+hzgBE69HuT8C/Z/pBT/x
Im+D4lM1l++Xyn1RAoHyfnZy+nQK9i4hZ3eGyvpYfjfNGN5S+cBHY7/pKcr/EFaE
WgN97C4eTLD/SDxCoS9K25XEVFECHNfgY5NS3sfizlVrQqRIecoSLUhyqswlXYF8
xgi58ZRh0oCGv6/4oyNROhwBi/aJYL0RRSYd5ZuARcs/aZ+QhdMOkprdzZSh4wDX
n3Vw1Rm1GAJEDVEojLoFtpWroe4YdsFHDmkJodZl3PHZIOuwHRr8YsqcHwuXM5nW
iGZRw+PoJP6gri+ev62U0jW5k7t7v35aF4ccBhwg4AVT2odFnj72hwD6df29LMIa
Zebj4iagOADfdVJhNUis9YseJwJtmlCJqUAB/6BQsCqeleD9LldTMutN/mq67DSe
z33nzBeLs0PnhtYiX2z3yjw4s+6/c4Q0o+fikm4t23A1Px8sDi72yplLRl67L6L8
I4zXOW4eA9PFQFndAhDblmceVOoCmRuncXte56/8trdyGepF7+tm+79zKXeDkVkf
XmyHbcipFPHg00EUDgt2Wovq63obQXHP9f1KWon8YGOmW5MJbBNWiu83RZvwX7YW
6Z+STzC7aMzmQECmKEuiW1Zx6kcZnXFYDrlEiyit+lCiUyjqVbEJb3GJnOJM7Lmj
WEhutG6MSdJFuP/LHc0xxjxrQeG776skEujPcIt+kWqYXpdKTthWbfiuqCKbs+Qa
cGz3tRhyH2urDZC0LuZHF15AyQmSmRP4FcC9aMn6q4alx/+LUZwGvrjb4xJNAtqC
aapC8vTyNxKBJhawlkSewVoI3c7ra0WKYJ7YGaHct1VeH9u47a7pu/hYC1dAPWd8
kajqEv2JJyWk0rrCi5OzrIfxE9Bl9C4nFWCPsd61qGLmi7u+1MrdN3k6dk6TG/y5
Qkn9iw7wFyoaq6p6RFtFFPnAJJDiHEMp/ZFfY9Rxquvb4EK6FjAHAtKejzEMte4x
zXK4C4pBZTy+RTMvu7j0CGVlKRgSyj05LX2c22NY6YB1ZSoe9r8NFeRSOQ0ojHBf
afbiN3jcuOA/nB1MHq6ll/VpLR9NIAJyC4Xh+isdDK4JIXesSD9iNA5CIVXMUlE4
x5AXF2HOm4o=
-----END PUBLIC KEY-----
Conforming CA implementations MUST specify the X.509 public key algorithm explicitly by using
the OIDs specified in when using ML-DSA public keys in certificates and CRLs.
Conforming client implementations that process ML-DSA public keys when processing certificates and CRLs
MUST recognize the corresponding OIDs.
Key Usage Bits
The intended application for the key is indicated in the keyUsage certificate extension; see
. 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:
If the keyUsage extension is present in a certificate that indicates id-ML-DSA in the SubjectPublicKeyInfo, then the following MUST NOT be present:
Requirements about the keyUsage extension bits defined in still apply.
ML-DSA Private Keys
A ML-DSA private key is encoded as MLDSAPrivateKey in the privateKey field as an OCTET STRING. ML-DSA public keys are
optionally distributed in the publicKey field of the MLDSAPrivateKey structure. This follows the OneAsymmetricKey
syntax.
The ASN.1 encoding for a ML-DSA private key is as follows:
MLDSAPrivateKey ::= SEQUENCE {
version Version,
privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,
privateKey OCTET STRING,
publicKey [1] MLDSAPublicKey OPTIONAL
}
A fully populated ML-DSA private key consists of 6 parameters. The size necessary to hold all private key elements
is 32+32+32+32*[(k+l)*ceiling(log(2*eta+1))+13*k] bytes. The description of k, l, and eta as well as public
key and secret key sizes for security levels 2, 3, and 5 can be found in Figure 1 of the Appendix.
ASN.1 Module
This section includes the ASN.1 module for the ML-DSA signature algorithm. This module does not come from any previously
existing RFC. This module references .
[ EDNOTE: Add ASN.1 here ]
PKIX1-PQ-Algorithms { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-PQ-algorithms(X) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL;
IMPORTS
-- FROM RFC 5912
PUBLIC-KEY, SIGNATURE-ALGORITHM, DIGEST-ALGORITHM, SMIME-CAPS
FROM AlgorithmInformation-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58) }
--
-- Public Key (pk-) Algorithms
--
PublicKeys PUBLIC-KEY ::= {
-- This expands PublicKeys from RFC 5912
pk-MLDSATBD |
pk-TBD-TBD,
...
}
-- The hashAlgorithm is mda-shake256
-- The XOF seed rho is 32 bytes
-- The vector t1 is 320*k bytes
-- These are encoded as a single string
pk-MLDSA PUBLIC-KEY ::= {
IDENTIFIER id-MLDSA
-- KEY no ASN.1 wrapping --
PARAMS ARE absent
CERT-KEY-USAGE { nonRepudiation, digitalSignature,
keyCertSign, cRLSign }
--- PRIVATE-KEY no ASN.1 wrapping --
}
END
IANA Considerations
Extensions in certificates and CRLs are identified using object Identifiers (OIDs). The creation and delegation of these
arcs is to be determined.
IANA is requested to register the id-mod-pkix1-PQ-algorithms OID for the ASN.1 module identifier found in Section 5 in
the "SMI Security for PKIX Module Identifier" registry.
Security Considerations
The Security Considerations section of 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.
EDNOTE: Discuss implications of not hash-then-sign. Implications in performance too.
Within the hash-then-sign paradigm, hash functions are used as a domain restrictor over the message to be signed. By
pre-hashing, the onus of resistance to existential forgeries becomes heavily reliant on the collision-resistance
of the hash function in use. As well as this security goal, the hash-then-sign paradigm also has the ability to
improve performance by reducing the size of signed messages. As a corollary, hashing remains mandatory even for
short messages and assigns a further computational requirement onto the verifier. This makes the performance of
hash-then-sign schemes more consistent, but not necessarily more efficient. ML-DSA diverges from the hash-then-sign
paradigm by hashing the message
during the signing procedure (at the point in which the challenge polynomial). However, due to the fact that ML-DSA
signatures may require the signing procedure to be repeated several times for a signature to be produced, ML-DSA
implementations can make use of pre-hashing the message to prevent rehashing with each attempt.
EDNOTE: Discuss deterministic vs randomized signing and the impact on security.
ML-DSA offers both deterministic and randomized signing. By default ML-DSA signatures are non-deterministic, the private
random seed rho' 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.
EDNOTE: Discuss side-channels for ML-DSA.
ML-DSA has been designed to provide side-channel resilience by eliminating a reliance on Gaussian sampling. 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
.
These properties are dependent, in part, on unambiguous public key serialization. It for this reason the public key
structure defined in is intentionally encoded as a single
OCTET STRING.
References
Normative References
DRAFT FIPS 204 (Initial Public Draft): Module-Lattice-Based Digital Signature Standard
National Institute of Standards and Technology
Information Technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation. ITU-T Recommendation X.680 (2021) | ISO/IEC 8824-1:2021.
ITU-T
Information technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER). ITU-T Recommendation X.690 (2021) | ISO/IEC 8825-1:2021.
ITU-T
Informative References
CRYSTALS-Dilithium Algorithm Specifications and Supporting Documentation
Fiat-Shamir with aborts: Applications to lattice and factoring-based signatures
International Conference on the Theory and Application of Cryptology and Information Security
BUFFing signature schemes beyond unforgeability and the case of post-quantum signatures
In Proceedings of the 42nd IEEE Symposium on Security and Privacy
Post-Quantum Cryptography Project
Acknowledgements
We would like to thank ... for their insightful comments.
Security Strengths
Instead of defining the strength of a quantum algorithm in a traditional manner using precise estimates of the number
of bits of security, NIST has instead elected to define a collection of broad security strength categories. Each
category is defined by a comparatively easy-to-analyze reference primitive that cover a range of security strengths
offered by existing NIST standards in symmetric cryptography, which NIST expects to offer significant resistance
to quantum cryptanalysis. These categories describe any attack that breaks the relevant security definition that
must require computational resources comparable to or greater than those required for: Level 1 - key search on a
block cipher with a 128-bit key (e.g., AES128), Level 2 - collision search on a 256-bit hash function (e.g.,
SHA256/ SHA3-256), Level 3 - key search on a block cipher with a 192-bit key (e.g., AES192), Level 4 - collision
search on a 384-bit hash function (e.g. SHA384/ SHA3-384), Level 5 - key search on a block cipher with a 256-bit
key (e.g., AES 256).
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.

```
```