rfc9935.original   rfc9935.txt 
LAMPS S. Turner Internet Engineering Task Force (IETF) S. Turner
Internet-Draft sn3rd Request for Comments: 9935 sn3rd
Intended status: Standards Track P. Kampanakis Category: Standards Track P. Kampanakis
Expires: 23 January 2026 J. Massimo ISSN: 2070-1721 J. Massimo
AWS AWS
B. E. Westerbaan B. E. Westerbaan
Cloudflare Cloudflare
22 July 2025 February 2026
Internet X.509 Public Key Infrastructure - Algorithm Identifiers for the Internet X.509 Public Key Infrastructure - Algorithm Identifiers for the
Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM)
draft-ietf-lamps-kyber-certificates-11
Abstract Abstract
The Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a The Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a
quantum-resistant key-encapsulation mechanism (KEM). This document quantum-resistant Key Encapsulation Mechanism (KEM). This document
specifies the conventions for using the ML-KEM in X.509 Public Key specifies the conventions for using the ML-KEM in X.509 Public Key
Infrastructure. The conventions for the subject public keys and Infrastructure. The conventions for the subject public keys and
private keys are also specified. private keys are also specified.
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/kyber-certificates/#go.draft-ietf-lamps-kyber-
certificates.html. Status information for this document may be found
at https://datatracker.ietf.org/doc/draft-ietf-lamps-kyber-
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/kyber-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 23 January 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/rfc9935.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2026 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 1. Introduction
1.1. Applicability Statement 1.1. Applicability Statement
2. Conventions and Definitions 2. Conventions and Definitions
3. Algorithm Identifiers 3. Algorithm Identifiers
4. Subject Public Key Fields 4. Subject Public Key Fields
5. Key Usage Bits 5. Key Usage Bits
6. Private Key Format 6. Private Key Format
skipping to change at line 106 skipping to change at line 84
C.2. Example Public Keys C.2. Example Public Keys
C.3. Example Certificates C.3. Example Certificates
C.4. Examples of Bad Private Keys C.4. Examples of Bad Private Keys
C.4.1. ML-KEM Inconsistent Seed and Expanded Private Keys C.4.1. ML-KEM Inconsistent Seed and Expanded Private Keys
Acknowledgments Acknowledgments
Authors' Addresses Authors' Addresses
1. Introduction 1. Introduction
The Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) The Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM)
standardized in [FIPS203] is a quantum-resistant key-encapsulation standardized in [FIPS203] is a quantum-resistant Key Encapsulation
mechanism (KEM) standardized by the US National Institute of Mechanism (KEM) standardized by the US National Institute of
Standards and Technology (NIST) PQC Project [NIST-PQC]. Prior to Standards and Technology (NIST) Post-Quantum Cryptography (PQC)
standardization, the earlier versions of the mechanism were known as Project [NIST-PQC]. Prior to standardization, versions of the
Kyber. ML-KEM and Kyber are not compatible. This document specifies mechanism were known as Kyber. ML-KEM and Kyber are not compatible.
the use of ML-KEM in Public Key Infrastructure X.509 (PKIX) This document specifies the use of ML-KEM in Public Key
certificates [RFC5280] at three security levels: ML-KEM-512, ML-KEM- Infrastructure using X.509 (PKIX) certificates [RFC5280] at three
768, and ML-KEM-1024, using object identifiers assigned by NIST. The security levels: ML-KEM-512, ML-KEM-768, and ML-KEM-1024, using
private key format is also specified. object identifiers (OIDs) assigned by NIST. The private key format
is also specified.
1.1. Applicability Statement 1.1. Applicability Statement
ML-KEM certificates are used in protocols where the public key is ML-KEM certificates are used in protocols where the public key is
used to generate and encapsulate a shared secret used to derive a used to generate and encapsulate a shared secret used to derive a
symmetric key used to encrypt a payload; see symmetric key used to encrypt a payload; see [RFC9936]. To be used
[I-D.ietf-lamps-cms-kyber]. To be used in TLS, ML-KEM certificates in TLS, ML-KEM certificates could only be used as end-entity identity
could only be used as end-entity identity certificates and would certificates and would require significant updates to the protocol;
require significant updates to the protocol; see, for example, for example, see [KEM-TLS].
[I-D.celi-wiggers-tls-authkem].
2. Conventions and Definitions 2. Conventions and Definitions
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.
3. Algorithm Identifiers 3. Algorithm Identifiers
skipping to change at line 151 skipping to change at line 129
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 OID.
identifier.
* 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 AlgorithmIdentifier for an ML-KEM public key MUST use one of the The AlgorithmIdentifier for an ML-KEM public key MUST use one of the
id-alg-ml-kem object identifiers (OID) from NIST [CSOR] listed below, id-alg-ml-kem OIDs from NIST [CSOR] listed below, based on the
based on the security level. The parameters field of the security level. The parameters field of the AlgorithmIdentifier for
AlgorithmIdentifier for the ML-KEM public key MUST be absent. the ML-KEM public key MUST be absent.
nistAlgorithms OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) nistAlgorithms OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
country(16) us(840) organization(1) gov(101) csor(3) country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) } nistAlgorithm(4) }
kems OBJECT IDENTIFIER ::= { nistAlgorithms 4 } kems OBJECT IDENTIFIER ::= { nistAlgorithms 4 }
id-alg-ml-kem-512 OBJECT IDENTIFIER ::= { kems 1 } id-alg-ml-kem-512 OBJECT IDENTIFIER ::= { kems 1 }
id-alg-ml-kem-768 OBJECT IDENTIFIER ::= { kems 2 } id-alg-ml-kem-768 OBJECT IDENTIFIER ::= { kems 2 }
skipping to change at line 191 skipping to change at line 168
subjectPublicKey BIT STRING subjectPublicKey BIT STRING
} }
The fields in SubjectPublicKeyInfo have the following meaning: The fields in SubjectPublicKeyInfo have the following meaning:
* algorithm is the algorithm identifier and parameters for the * algorithm is the algorithm identifier and parameters for the
public key (see above). public key (see above).
* subjectPublicKey contains the byte stream of the public key. * subjectPublicKey contains the byte stream of the public key.
For each ML-KEM parameter set, see Table 1, we define a PUBLIC-KEY For each ML-KEM parameter set (see Table 1), we define a PUBLIC-KEY
ASN.1 type as follows. ASN.1 type as follows:
pk-ml-kem-512 PUBLIC-KEY ::= { pk-ml-kem-512 PUBLIC-KEY ::= {
IDENTIFIER id-alg-ml-kem-512 IDENTIFIER id-alg-ml-kem-512
-- KEY no ASN.1 wrapping; 800 octets -- -- KEY no ASN.1 wrapping; 800 octets --
PARAMS ARE absent PARAMS ARE absent
CERT-KEY-USAGE { keyEncipherment } CERT-KEY-USAGE { keyEncipherment }
PRIVATE-KEY ML-KEM-512-PrivateKey -- defined in Section 6 PRIVATE-KEY ML-KEM-512-PrivateKey -- defined in Section 6
} }
pk-ml-kem-768 PUBLIC-KEY ::= { pk-ml-kem-768 PUBLIC-KEY ::= {
skipping to change at line 231 skipping to change at line 208
ML-KEM-1024-PublicKey ::= OCTET STRING (SIZE (1568)) ML-KEM-1024-PublicKey ::= OCTET STRING (SIZE (1568))
When an ML-KEM public key appears outside of a SubjectPublicKeyInfo When an ML-KEM public key appears outside of a SubjectPublicKeyInfo
type in an environment that uses ASN.1 encoding, it can be encoded as type in an environment that uses ASN.1 encoding, it can be encoded as
an OCTET STRING by using the ML-KEM-512-PublicKey, ML-KEM- an OCTET STRING by using the ML-KEM-512-PublicKey, ML-KEM-
768-PublicKey, and ML-KEM-1024-PublicKey types corresponding to the 768-PublicKey, and ML-KEM-1024-PublicKey types corresponding to the
correct key size. correct key size.
[RFC5958] describes the Asymmetric Key Package's OneAsymmetricKey [RFC5958] describes the Asymmetric Key Package's OneAsymmetricKey
type for encoding asymmetric keypairs. When an ML-KEM private key or type for encoding asymmetric key pairs. When an ML-KEM private key
keypair is encoded as a OneAsymmetricKey, it follows the description or key pair is encoded as a OneAsymmetricKey, it follows the
in Section 6. description in Section 6.
When the ML-KEM private key appears outside of an Asymmetric Key When the ML-KEM 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 ML-KEM-PrivateKey CHOICE formats defined in using one of the ML-KEM-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.2 contains examples for ML-KEM public keys encoded using Appendix C.2 contains examples for ML-KEM public keys encoded using
the textual encoding defined in [RFC7468]. the 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 certificates, then keyEncipherement keyUsage extension is present in certificates, then keyEncipherement
MUST be the only key usage set for certificates that indicate id-alg- MUST be the only key usage set for certificates that indicate id-alg-
ml-kem-* in SubjectPublicKeyInfo, (with * either 512, 768, or 1024.) ml-kem-* in SubjectPublicKeyInfo, (with * being one of 512, 768, or
1024.)
6. Private Key Format 6. Private Key Format
[FIPS203] specifies two formats for an ML-KEM private key: a 64-octet [FIPS203] specifies two formats for an ML-KEM private key: a 64-octet
seed and an (expanded) private key, which is referred to as the seed and an (expanded) private key, which is referred to as the
decapsulation key. The expanded private key (and public key) is decapsulation key. The expanded private key (and public key) is
computed from the seed using ML-KEM.KeyGen_internal(d,z) (algorithm computed from the seed using ML-KEM.KeyGen_internal(d,z) (algorithm
16) using the first 32 octets as _d_ and the remaining 32 octets as 16) using the first 32 octets as _d_ and the remaining 32 octets as
_z_. If the expanded private key is generated without exporting the _z_. If the expanded private key is generated without exporting the
seed, ML-KEM.KeyGen() (algorithm 19), which combines seed generation seed, ML-KEM.KeyGen() (algorithm 19) is used; it combines seed
with ML-KEM.KeyGen_internal(d,z), is used. generation with ML-KEM.KeyGen_internal(d,z).
A keypair is generated by sampling 64 octets uniformly at random for A key pair is generated by sampling 64 octets uniformly at random for
the seed (private key) from a cryptographically secure pseudorandom the seed (private key) from a cryptographically secure pseudorandom
number generator (CSPRNGs). The public key can then be computed number generator (CSPRNG). The public key can then be computed using
using ML-KEM.KeyGen_internal(d,z) as described earlier. ML-KEM.KeyGen_internal(d,z) as described earlier.
"Asymmetric Key Packages" [RFC5958] describes how to encode a private "Asymmetric Key Packages" [RFC5958] describes how to encode a private
key in a structure that both identifies which algorithm the private key in a structure that both identifies which algorithm the private
key is for and allows for the public key and additional attributes 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 about the key to be included as well. For illustration, the ASN.1
structure OneAsymmetricKey is replicated below. structure OneAsymmetricKey is replicated below.
OneAsymmetricKey ::= SEQUENCE { OneAsymmetricKey ::= SEQUENCE {
version Version, version Version,
privateKeyAlgorithm SEQUENCE { privateKeyAlgorithm SEQUENCE {
skipping to change at line 350 skipping to change at line 328
seed and others may only support expanded private keys. seed and others may only support expanded private keys.
The privateKeyAlgorithm field uses the AlgorithmIdentifier structure The privateKeyAlgorithm field uses the AlgorithmIdentifier structure
with the appropriate OID as defined in Section 3. with the appropriate OID as defined in Section 3.
The publicKey field contains the byte stream of the public key. If The publicKey field contains the byte stream of the public key. If
present, the publicKey field will hold the encoded public key as present, the publicKey field will hold the encoded public key as
defined in Section 4. defined in 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, the
seed-only format is RECOMMENDED as it is the most compact 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 key can
be deterministically derived from the seed using ML- be deterministically derived from the seed using ML-
KEM.KeyGen_internal(d,z) (algorithm 16) using the first 32 octets as KEM.KeyGen_internal(d,z) (algorithm 16) using the first 32 octets as
_d_ and the remaining 32 octets as _z_. Alternatively, the public _d_ and the remaining 32 octets as _z_. Alternatively, the public
key can be extracted from the expanded private key. While the key can be extracted from the expanded private key. While the
publicKey field and expandedKey format are technically redundant when publicKey field and expandedKey format are technically redundant when
using the seed-only format, they MAY be included to enable keypair using the seed-only format, they MAY be included to enable key pair
consistency checks 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.1 contains examples for ML-KEM private keys encoded using Appendix C.1 contains examples for ML-KEM private keys encoded using
the textual encoding defined in [RFC7468]. the textual encoding defined in [RFC7468].
7. Implementation Considerations 7. Implementation Considerations
Though section 7.1 of [FIPS203] mentions the potential to save seed Though Section 7.1 of [FIPS203] mentions the potential to save seed
values for future expansion, Algorithm 19 does not make the seed values for future expansion, Algorithm 19 does not make the seed
values available to a caller for serialization. Similarly, the values available to a caller for serialization. Similarly, the
algorithm that expands seed values is not listed as one of the "main algorithm that expands seed values is not listed as one of the "main
algorithms" and features "internal" in the name even though it is algorithms" and features "internal" in the name even though it is
clear that it is allowed to be exposed externally for the purposes of clear that it is allowed to be exposed externally for the purposes of
expanding a key from a seed. Below are possible ways to extend the expanding a key from a seed. Below are possible ways to extend the
APIs defined in [FIPS203] to support serialization of seed values as APIs defined in [FIPS203] to support serialization of seed values as
private keys. private keys.
To support serialization of seed values as private keys, let To support serialization of seed values as private keys, let
Algorithm 19b denote the same procedure as Algorithm 19 in [FIPS203] Algorithm 19b denote the same procedure as Algorithm 19 in [FIPS203],
except it returns (ek, dk, d, z) on line 7. Additionally, Algorithm except it returns (ek, dk, d, z) on line 7. Additionally, Algorithm
16 should be promoted to be a "main algorithm" for external use in 16 should be promoted to be a "main algorithm" for external use in
expanding seed values. expanding seed values.
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 a seed and
seed discarded, the seed cannot be re-created even if the full the 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. when also exporting the expanded private key.
8. Private Key Consistency Testing 8. 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 they are unable to ensure that the
and expandedKey match. seed 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.
When receiving a private key that contains an expandedKey, [FIPS203] When receiving a private key that contains an expandedKey, [FIPS203]
stipulates in section 7.3 that before use, a "hash check" MUST be stipulates in Section 7.3 that before use, a "hash check" MUST be
performed. That section stipulates two other checks on the type and performed. That section stipulates two other checks on the type and
length of the expandedKey which are ensured by this standard. length of the expandedKey, which are ensured by this standard.
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-KEM.KeyGen_internal(d,z) (algorithm 16) using from the seed via ML-KEM.KeyGen_internal(d,z) (algorithm 16) using
the first 32 octets as _d_ and the remaining 32 octets as _z_ and the first 32 octets as _d_ and the remaining 32 octets as _z_ and
ensuring it is bytewise equal to the value presented in the private ensuring it is bytewise equal to the value presented in the private
key. 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.
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.
Protection of the private-key information, i.e., the seed, is vital Protection of the private key information, i.e., the seed, is vital
to public-key cryptography. Disclosure of the private-key material to public key cryptography. Disclosure of the private key material
to another entity can lead to masquerades. to another entity can lead to masquerades.
The generation of private keys relies on random numbers. The use of The generation of private keys relies on random numbers. The use of
inadequate pseudo-random number generators (PRNGs) to generate these inadequate pseudorandom number generators (PRNGs) to generate these
values can result in little or no security. An attacker may find it values can result in little or no security. An attacker may find it
much easier to reproduce the PRNG environment that produced the keys, much easier to reproduce the PRNG environment that produced the keys,
searching the resulting small set of possibilities, rather than brute searching the resulting small set of possibilities, rather than brute
force searching the whole key space. The generation of quality force searching the whole key space. The generation of quality
random numbers is difficult. ML-KEM key generation has specific random numbers is difficult. ML-KEM key generation has specific
requirements around randomness generation as described in section 3.3 requirements around randomness generation as described in Section 3.3
of [FIPS203]. of [FIPS203].
Many protocols only rely on the IND-CCA security of a KEM. Some Many protocols only rely on the IND-CCA security of a KEM. Some
(implicitly) require further binding properties, formalized in (implicitly) require further binding properties, formalized in
[CDM23]. The private key format influences these binding properties. [CDM23]. The private key format influences these binding properties.
Per [KEMMY24], ML-KEM is LEAK-BIND-K-PK-secure and LEAK-BIND-K-CT- Per [KEMMY24], ML-KEM is LEAK-BIND-K-PK-secure and LEAK-BIND-K-CT-
secure when using the expanded private key format, but not MAL-BIND- secure when using the expanded private key format, but not MAL-BIND-
K-CT nor MAL-BIND-K-PK. Using the 64-byte seed format provides a K-CT nor MAL-BIND-K-PK secure. Using the 64-byte seed format
step up in binding security, additionally providing MAL-BIND-K-CT provides a step up in binding security, and additionally provides
security, but still not MAL-BIND-K-PK. MAL-BIND-K-CT security (but still does not provide security for MAL-
BIND-K-PK).
For more detailed ML-KEM specific security considerations regarding For more detailed ML-KEM specific security considerations regarding
this, randomness, misbinding properties, decapsulation failures, key this, randomness, misbinding properties, decapsulation failures, key
reuse, and key checks, refer to reuse, and key checks, refer to [ML-KEM-SEC-CONS].
[I-D.sfluhrer-cfrg-ml-kem-security-considerations].
10. IANA Considerations 10. 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 an OID for the
object identifier (OID) for the module identifier (TBD) with a module identifier (121) with a description of "id-mod-x509-ml-kem-
Description of "id-mod-x509-ml-kem-2025". The OID for the module 2025" in the "SMI Security for PKIX Module Identifier" registry
should be allocated in the "SMI Security for PKIX Module Identifier" (1.3.6.1.5.5.7.0).
registry (1.3.6.1.5.5.7.0).
11. References 11. References
11.1. Normative References 11.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>.
[FIPS203] "Module-lattice-based key-encapsulation mechanism [FIPS203] NIST, "Module-Lattice-Based Key-Encapsulation Mechanism
standard", National Institute of Standards and Technology Standard", NIST FIPS 203, DOI 10.6028/NIST.FIPS.203,
(U.S.), DOI 10.6028/nist.fips.203, August 2024, August 2024, <https://nvlpubs.nist.gov/nistpubs/FIPS/
<https://doi.org/10.6028/nist.fips.203>. NIST.FIPS.203.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>.
[RFC9629] Housley, R., Gray, J., and T. Okubo, "Using Key [RFC9629] Housley, R., Gray, J., and T. Okubo, "Using Key
Encapsulation Mechanism (KEM) Algorithms in the Encapsulation Mechanism (KEM) Algorithms in the
Cryptographic Message Syntax (CMS)", RFC 9629, Cryptographic Message Syntax (CMS)", RFC 9629,
DOI 10.17487/RFC9629, August 2024, DOI 10.17487/RFC9629, August 2024,
<https://www.rfc-editor.org/rfc/rfc9629>. <https://www.rfc-editor.org/info/rfc9629>.
[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>.
11.2. Informative References 11.2. Informative References
[CDM23] Cremers, C., Dax, A., and N. Medinger, "Keeping Up with [CDM23] Cremers, C., Dax, A., and N. Medinger, "Keeping Up with
the KEMs: Stronger Security Notions for KEMs and automated the KEMs: Stronger Security Notions for KEMs and automated
analysis of KEM-based protocols", 2023, analysis of KEM-based protocols", Cryptology ePrint
Archive, Paper 2023/1933, 2023,
<https://eprint.iacr.org/2023/1933.pdf>. <https://eprint.iacr.org/2023/1933.pdf>.
[I-D.celi-wiggers-tls-authkem] [KEM-TLS] Wiggers, T., Celi, S., Schwabe, P., Stebila, D., and N.
Wiggers, T., Celi, S., Schwabe, P., Stebila, D., and N.
Sullivan, "KEM-based Authentication for TLS 1.3", Work in Sullivan, "KEM-based Authentication for TLS 1.3", Work in
Progress, Internet-Draft, draft-celi-wiggers-tls-authkem- Progress, Internet-Draft, draft-celi-wiggers-tls-authkem-
05, 22 April 2025, <https://datatracker.ietf.org/doc/html/ 06, 4 November 2025,
draft-celi-wiggers-tls-authkem-05>. <https://datatracker.ietf.org/doc/html/draft-celi-wiggers-
tls-authkem-06>.
[I-D.ietf-lamps-cms-kyber]
Prat, J., Ounsworth, M., and D. Van Geest, "Use of ML-KEM
in the Cryptographic Message Syntax (CMS)", Work in
Progress, Internet-Draft, draft-ietf-lamps-cms-kyber-11, 1
July 2025, <https://datatracker.ietf.org/doc/html/draft-
ietf-lamps-cms-kyber-11>.
[I-D.ietf-lamps-dilithium-certificates] [KEMMY24] Schmieg, S., "Unbindable Kemmy Schmidt: ML-KEM is neither
Massimo, J., Kampanakis, P., Turner, S., and B. MAL-BIND-K-CT nor MAL-BIND-K-PK", Cryptology ePrint
Westerbaan, "Internet X.509 Public Key Infrastructure - Archive, Paper 2024/523, 2024,
Algorithm Identifiers for the Module-Lattice-Based Digital <https://eprint.iacr.org/2024/523.pdf>.
Signature Algorithm (ML-DSA)", Work in Progress, Internet-
Draft, draft-ietf-lamps-dilithium-certificates-12, 26 June
2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
lamps-dilithium-certificates-12>.
[I-D.sfluhrer-cfrg-ml-kem-security-considerations] [ML-KEM-SEC-CONS]
Fluhrer, S., Dang, Q., Mattsson, J. P., Milner, K., and D. Fluhrer, S., Dang, Q., Mattsson, J. P., Milner, K., and D.
Shiu, "ML-KEM Security Considerations", Work in Progress, Shiu, "ML-KEM Security Considerations", Work in Progress,
Internet-Draft, draft-sfluhrer-cfrg-ml-kem-security- Internet-Draft, draft-sfluhrer-cfrg-ml-kem-security-
considerations-03, 15 May 2025, considerations-04, 17 November 2025,
<https://datatracker.ietf.org/doc/html/draft-sfluhrer- <https://datatracker.ietf.org/doc/html/draft-sfluhrer-
cfrg-ml-kem-security-considerations-03>. cfrg-ml-kem-security-considerations-04>.
[KEMMY24] Schmieg, S., "Unbindable Kemmy Schmidt: ML-KEM is neither
MAL-BIND-K-CT nor MAL-BIND-K-PK", 2024,
<https://eprint.iacr.org/2024/523.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>.
[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>.
[RFC9881] Massimo, J., Kampanakis, P., Turner, S., and B. E.
Westerbaan, "Internet X.509 Public Key Infrastructure --
Algorithm Identifiers for the Module-Lattice-Based Digital
Signature Algorithm (ML-DSA)", RFC 9881,
DOI 10.17487/RFC9881, October 2025,
<https://www.rfc-editor.org/info/rfc9881>.
[RFC9936] Prat, J., Ounsworth, M., and D. Van Geest, "Use of ML-KEM
in the Cryptographic Message Syntax (CMS)", RFC 9936,
DOI 10.17487/RFC9936, February 2026,
<https://www.rfc-editor.org/info/rfc9936>.
Appendix A. ASN.1 Module Appendix A. ASN.1 Module
This appendix includes the ASN.1 module [X680] for the ML-KEM. Note This appendix includes the ASN.1 module [X680] for the ML-KEM. 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] and Rules; see [X690]. This module imports objects from [RFC5912] and
[RFC9629]. [RFC9629].
<CODE BEGINS> <CODE BEGINS>
X509-ML-KEM-2025 X509-ML-KEM-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-kem-2025(TBD) } id-mod-x509-ml-kem-2025(121) }
DEFINITIONS IMPLICIT TAGS ::= BEGIN DEFINITIONS IMPLICIT TAGS ::= BEGIN
EXPORTS ALL; EXPORTS ALL;
IMPORTS IMPORTS
PUBLIC-KEY PUBLIC-KEY
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)
skipping to change at line 697 skipping to change at line 670
ML-KEM-1024-PublicKey ::= OCTET STRING (SIZE (1568)) ML-KEM-1024-PublicKey ::= OCTET STRING (SIZE (1568))
END END
<CODE ENDS> <CODE ENDS>
Appendix B. Parameter Set Security and Sizes Appendix B. Parameter Set Security and Sizes
Instead of defining the strength of a quantum algorithm in a Instead of defining the strength of a quantum algorithm in a
traditional manner using the imprecise notion of bits of security, traditional manner using the imprecise notion of bits of security,
NIST has defined security levels by picking a reference scheme, which NIST has defined security levels by picking a reference scheme, which
NIST expects to offer notable levels of resistance to both quantum is expected to offer notable levels of resistance to both quantum and
and classical attack. To wit, a KEM algorithm that achieves NIST PQC classical attacks. To wit, a KEM algorithm that achieves NIST PQC
security must require computational resources to break IND-CCA security must require computational resources to break IND-CCA
security comparable or greater than that required for key search on security comparable or greater than that required for key search on
AES-128, AES-192, and AES-256 for Levels 1, 3, and 5, respectively. AES-128, AES-192, and AES-256 for Levels 1, 3, and 5, respectively.
Levels 2 and 4 use collision search for SHA-256 and SHA-384 as Levels 2 and 4 use collision search for SHA-256 and SHA-384 as
reference. reference.
+=======+===============+========+========+============+========+ +=======+===============+========+========+============+========+
| Level | Parameter Set | Encap. | Decap. | Ciphertext | Secret | | Level | Parameter Set | Encap. | Decap. | Ciphertext | Secret |
| | | Key | Key | | | | | | Key | Key | | |
+=======+===============+========+========+============+========+ +=======+===============+========+========+============+========+
| 1 | ML-KEM-512 | 800 | 1632 | 768 | 32 | | 1 | ML-KEM-512 | 800 | 1632 | 768 | 32 |
+-------+---------------+--------+--------+------------+--------+ +-------+---------------+--------+--------+------------+--------+
| 3 | ML-KEM-768 | 1184 | 2400 | 1088 | 32 | | 3 | ML-KEM-768 | 1184 | 2400 | 1088 | 32 |
+-------+---------------+--------+--------+------------+--------+ +-------+---------------+--------+--------+------------+--------+
| 5 | ML-KEM-1024 | 1568 | 3168 | 1568 | 32 | | 5 | ML-KEM-1024 | 1568 | 3168 | 1568 | 32 |
+-------+---------------+--------+--------+------------+--------+ +-------+---------------+--------+--------+------------+--------+
Table 1: Mapping between NIST Security Level, ML-KEM Table 1: Mapping Between NIST Security Level, ML-KEM
parameter set, and sizes in bytes Parameter Sets, and Sizes in Bytes
Appendix C. Examples Appendix C. Examples
This appendix contains examples of ML-KEM public keys, private keys, This appendix contains examples of ML-KEM public keys, private 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-KEM private keys in different formats, The following examples show ML-KEM 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
skipping to change at line 1912 skipping to change at line 1885
4f732ca27da82b19b5dc0cc7f8885714910888b2310c4f9319d410b34e6433b9 4f732ca27da82b19b5dc0cc7f8885714910888b2310c4f9319d410b34e6433b9
003e2176bb995257456106e8952163b8ba592530cc5aa0aeb43ad398fe9e97ba 003e2176bb995257456106e8952163b8ba592530cc5aa0aeb43ad398fe9e97ba
a523d7a4431677c3d3af0719e475db85ca95af5089beabeb05b2faab4896ba60 a523d7a4431677c3d3af0719e475db85ca95af5089beabeb05b2faab4896ba60
f81c88472a57b46a828826a0cdfb446f8189182d2bf5eac4ec1cc5deaf599c8a f81c88472a57b46a828826a0cdfb446f8189182d2bf5eac4ec1cc5deaf599c8a
13e48235406d17ffddc8344b6c66984a868aa92fa02227a086950eb0c8701ed5 13e48235406d17ffddc8344b6c66984a868aa92fa02227a086950eb0c8701ed5
8dc628776b983882e1175` } 8dc628776b983882e1175` }
} }
C.3. Example Certificates C.3. Example Certificates
| RFC EDITOR: Please replace the following reference to The following is the ML-KEM-512 certificate corresponding to the
| [I-D.ietf-lamps-dilithium-certificates] with a reference to the
| published RFC.
The following is the ML-KEM-512 certificate that corresponding to the
public key in the previous section signed with the ML-DSA-44 private public key in the previous section signed with the ML-DSA-44 private
key from [I-D.ietf-lamps-dilithium-certificates]. The textual key from [RFC9881]. The textual encoding [RFC7468] is followed by
encoding [RFC7468] is followed by the so-called "pretty print"; the the so-called "pretty print"; the certificates are the same.
certificates are the same.
-----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
MIINpDCCBBqgAwIBAgIUFZ/+byL9XMQsUk32/V4o0N44808wCwYJYIZIAWUDBAMR MIINpDCCBBqgAwIBAgIUFZ/+byL9XMQsUk32/V4o0N44808wCwYJYIZIAWUDBAMR
MCIxDTALBgNVBAoTBElFVEYxETAPBgNVBAMTCExBTVBTIFdHMB4XDTIwMDIwMzA0 MCIxDTALBgNVBAoTBElFVEYxETAPBgNVBAMTCExBTVBTIFdHMB4XDTIwMDIwMzA0
MzIxMFoXDTQwMDEyOTA0MzIxMFowIjENMAsGA1UEChMESUVURjERMA8GA1UEAxMI MzIxMFoXDTQwMDEyOTA0MzIxMFowIjENMAsGA1UEChMESUVURjERMA8GA1UEAxMI
TEFNUFMgV0cwggMyMAsGCWCGSAFlAwQEAQOCAyEAOZWBXll9EENVzymqUzPJMlGG TEFNUFMgV0cwggMyMAsGCWCGSAFlAwQEAQOCAyEAOZWBXll9EENVzymqUzPJMlGG
nVvNvkhxJPYCuLambBbEdhZIrXZc9dgAa1FekFp/CsB2sMYu+jKBU+fKVwFpnxMF nVvNvkhxJPYCuLambBbEdhZIrXZc9dgAa1FekFp/CsB2sMYu+jKBU+fKVwFpnxMF
8ea8b5Cw5JtpNRK2zpkqi4AW3fwaZix+P5YZy9hp3Xca8wiWzNWRisbLd0ZsXneZ 8ea8b5Cw5JtpNRK2zpkqi4AW3fwaZix+P5YZy9hp3Xca8wiWzNWRisbLd0ZsXneZ
ltZ/+aq8l1A/LHt+LQANhkUPsYB8pMq9pGWCWjHHiaG3pJGrOHJ2XTINC3GSD6IT ltZ/+aq8l1A/LHt+LQANhkUPsYB8pMq9pGWCWjHHiaG3pJGrOHJ2XTINC3GSD6IT
yUCTQWuDuBJOafZeYstQANzDeqmg//c5cMR3LzV9JBicpvUwVWjA4jdqN2KmjGBe yUCTQWuDuBJOafZeYstQANzDeqmg//c5cMR3LzV9JBicpvUwVWjA4jdqN2KmjGBe
skipping to change at line 2186 skipping to change at line 2154
fc424b8bd79c6b13192ae2e34fdb05b4da3cbaf13f9b5d697f86c69c65e00444 fc424b8bd79c6b13192ae2e34fdb05b4da3cbaf13f9b5d697f86c69c65e00444
46a59b2a9e6f893710c34db0f55a7b5d3e9c9e17cffa89777f78d8876e857cdf 46a59b2a9e6f893710c34db0f55a7b5d3e9c9e17cffa89777f78d8876e857cdf
43a58f475727861b4eb4017166df51e67cfbc8062746e0b2132d3c2ace75854c 43a58f475727861b4eb4017166df51e67cfbc8062746e0b2132d3c2ace75854c
01f59f72eec3c858b4b5076d4b5a66a390a8f8ec0bc5e2322a0c252183a08421 01f59f72eec3c858b4b5076d4b5a66a390a8f8ec0bc5e2322a0c252183a08421
37afa4810abc74fac4cfd2c8b157945e7eed89201923a32c0f6af98adfed74f6 37afa4810abc74fac4cfd2c8b157945e7eed89201923a32c0f6af98adfed74f6
5d45d019334937d0d6903010d1b1d282d515d6470757f80929596a2abc4deec0 5d45d019334937d0d6903010d1b1d282d515d6470757f80929596a2abc4deec0
b4e7d7e90b5b6b8c3c6cfd7e8f6152542586b788284afb3b4c0c1cad1d5daeff b4e7d7e90b5b6b8c3c6cfd7e8f6152542586b788284afb3b4c0c1cad1d5daeff
41462687daacad9ebf0f70000000000000000000000000000000015233640` } 41462687daacad9ebf0f70000000000000000000000000000000015233640` }
} }
| RFC EDITOR: Please replace the following reference to The following is the ML-KEM-768 certificate corresponding to the
| [I-D.ietf-lamps-dilithium-certificates] with a reference to the
| published RFC.
The following is the ML-KEM-768 certificate that corresponding to the
public key in the previous section signed with the ML-DSA-65 private public key in the previous section signed with the ML-DSA-65 private
key from [I-D.ietf-lamps-dilithium-certificates]. The textual key from [RFC9881]. The textual encoding [RFC7468] is followed by
encoding [RFC7468] is followed by the so-called "pretty print"; the the so-called "pretty print"; the certificates are the same.
certificates are the same.
-----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
MIISnTCCBZqgAwIBAgIUFZ/+byL9XMQsUk32/V4o0N44808wCwYJYIZIAWUDBAMS MIISnTCCBZqgAwIBAgIUFZ/+byL9XMQsUk32/V4o0N44808wCwYJYIZIAWUDBAMS
MCIxDTALBgNVBAoTBElFVEYxETAPBgNVBAMTCExBTVBTIFdHMB4XDTIwMDIwMzA0 MCIxDTALBgNVBAoTBElFVEYxETAPBgNVBAMTCExBTVBTIFdHMB4XDTIwMDIwMzA0
MzIxMFoXDTQwMDEyOTA0MzIxMFowIjENMAsGA1UEChMESUVURjERMA8GA1UEAxMI MzIxMFoXDTQwMDEyOTA0MzIxMFowIjENMAsGA1UEChMESUVURjERMA8GA1UEAxMI
TEFNUFMgV0cwggSyMAsGCWCGSAFlAwQEAgOCBKEAKYqhDUI8jdoGnQK8WebN8DoJ TEFNUFMgV0cwggSyMAsGCWCGSAFlAwQEAgOCBKEAKYqhDUI8jdoGnQK8WebN8DoJ
a4s9pMq5uAykoUkHZyzO8exPryNKC8W36dRz8rMTOzsmodF1y2engFkZaZwC92Ux a4s9pMq5uAykoUkHZyzO8exPryNKC8W36dRz8rMTOzsmodF1y2engFkZaZwC92Ux
uZxfiRgHBLtMpFNcW4lyZ5xmCgfF5RS4cAnIYuuPUVdpXvs/xAqd72uBwcwCokmu uZxfiRgHBLtMpFNcW4lyZ5xmCgfF5RS4cAnIYuuPUVdpXvs/xAqd72uBwcwCokmu
TwlK0Nm9NIXBwcaAgFIKfIxjIDLO5zgVTlxRdsB9pWAkd2pDD+durPZlo/e4MhAi TwlK0Nm9NIXBwcaAgFIKfIxjIDLO5zgVTlxRdsB9pWAkd2pDD+durPZlo/e4MhAi
FbyC8Qk5yDVXBDNqj6wdgeS7BIWqXXx01rWbvlxelyoNi6xBG1W11VV81oChqPcb FbyC8Qk5yDVXBDNqj6wdgeS7BIWqXXx01rWbvlxelyoNi6xBG1W11VV81oChqPcb
skipping to change at line 2527 skipping to change at line 2490
e2dda62c654f5cc9fc61ec071b2927d09514952828faa34050dd9be604f3cebd e2dda62c654f5cc9fc61ec071b2927d09514952828faa34050dd9be604f3cebd
cb146d4539a2816008f3ac7bad1fbe72a11043bdcc49ee53744e6dc40f903411 cb146d4539a2816008f3ac7bad1fbe72a11043bdcc49ee53744e6dc40f903411
98c4373a189b886cce10e694e8f084549dcff8dfa5266ff433694d69881a92cd 98c4373a189b886cce10e694e8f084549dcff8dfa5266ff433694d69881a92cd
2498aa187449a92dd99d19208207a1c9fa7208970a1daccd302bd49952a91dfa 2498aa187449a92dd99d19208207a1c9fa7208970a1daccd302bd49952a91dfa
41681af19fefe5e416f9a525b1a7e1409a68739468366c14132201c30001c3ef 41681af19fefe5e416f9a525b1a7e1409a68739468366c14132201c30001c3ef
f4520cf80f4d2236c2da299dd1325ffad2dfead2c0e8f8051edcd317dcae2fc1 f4520cf80f4d2236c2da299dd1325ffad2dfead2c0e8f8051edcd317dcae2fc1
5223e6db2ebf60a343c6d929ea3cce114216b8b363a83afb4d9102364a6beed0 5223e6db2ebf60a343c6d929ea3cce114216b8b363a83afb4d9102364a6beed0
00000000000000000000000000000000000050c15191f25` } 00000000000000000000000000000000000050c15191f25` }
} }
| RFC EDITOR: Please replace the following reference to The following is the ML-KEM-1024 certificate corresponding to the
| [I-D.ietf-lamps-dilithium-certificates] with a reference to the public key in the previous section signed with the ML-DSA-87 private
| published RFC. key from [RFC9881]. The textual encoding [RFC7468] is followed by
the so-called "pretty print"; the certificates are the same.
The following is the ML-KEM-1024 certificate that corresponding to
the public key in the previous section signed with the ML-DSA-87
private key from [I-D.ietf-lamps-dilithium-certificates]. The
textual encoding [RFC7468] is followed by the so-called "pretty
print"; the certificates are the same.
-----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
MIIZQzCCBxqgAwIBAgIUFZ/+byL9XMQsUk32/V4o0N44808wCwYJYIZIAWUDBAMT MIIZQzCCBxqgAwIBAgIUFZ/+byL9XMQsUk32/V4o0N44808wCwYJYIZIAWUDBAMT
MCIxDTALBgNVBAoTBElFVEYxETAPBgNVBAMTCExBTVBTIFdHMB4XDTIwMDIwMzA0 MCIxDTALBgNVBAoTBElFVEYxETAPBgNVBAMTCExBTVBTIFdHMB4XDTIwMDIwMzA0
MzIxMFoXDTQwMDEyOTA0MzIxMFowIjENMAsGA1UEChMESUVURjERMA8GA1UEAxMI MzIxMFoXDTQwMDEyOTA0MzIxMFowIjENMAsGA1UEChMESUVURjERMA8GA1UEAxMI
TEFNUFMgV0cwggYyMAsGCWCGSAFlAwQEAwOCBiEAS5TClFAREZGCOzUUyaweo9mC TEFNUFMgV0cwggYyMAsGCWCGSAFlAwQEAwOCBiEAS5TClFAREZGCOzUUyaweo9mC
XMuGOTot+wRlT6IZLTe/rRxJfGUC7uXKgKc7/OC69aVKiFhaQBOXo9Iy9Canr7CC XMuGOTot+wRlT6IZLTe/rRxJfGUC7uXKgKc7/OC69aVKiFhaQBOXo9Iy9Canr7CC
vCGkQxcJDqrHWSwuqIplPESR6hk5MTNfUumJo8TMVtnFU3MtV8Rw+0GrdZtl0tBE vCGkQxcJDqrHWSwuqIplPESR6hk5MTNfUumJo8TMVtnFU3MtV8Rw+0GrdZtl0tBE
RTgvzZxONEoRKPqeEeBDWOGS7QFLIyMqfuKyLiNxf0QRHuM1dTmcN2RtqYE+ybIS RTgvzZxONEoRKPqeEeBDWOGS7QFLIyMqfuKyLiNxf0QRHuM1dTmcN2RtqYE+ybIS
r+lOXcXCMwpylMwfQjSm0/u08WhauIksBKyxfNHBcNewYRtqcXbHlMyMZ/VfySPC r+lOXcXCMwpylMwfQjSm0/u08WhauIksBKyxfNHBcNewYRtqcXbHlMyMZ/VfySPC
skipping to change at line 2958 skipping to change at line 2916
65bd5eec1849404fa11ae674858a4180bcfcc0f93ed64ca94a041af1e5ea3169 65bd5eec1849404fa11ae674858a4180bcfcc0f93ed64ca94a041af1e5ea3169
7db3baf913fa35a92903eab84e5e31b8337278aa8e743f7e5dd13769c591febf 7db3baf913fa35a92903eab84e5e31b8337278aa8e743f7e5dd13769c591febf
89b1e8ab7066810c39298c1125718819b8b7ea2abc75f86e62eadea05a8a5c36 89b1e8ab7066810c39298c1125718819b8b7ea2abc75f86e62eadea05a8a5c36
d2e655cb805af1d54fce7838890d214a2a7e7112383adccdbdc2e648c9db7d1d d2e655cb805af1d54fce7838890d214a2a7e7112383adccdbdc2e648c9db7d1d
7f8575e7aa8c6c9070c1c245b737f939bc8edf272777f90d820229e000000000 7f8575e7aa8c6c9070c1c245b737f939bc8edf272777f90d820229e000000000
000000000000000000000000000000000000000000004080f171d292e31` } 000000000000000000000000000000000000000000004080f171d292e31` }
} }
C.4. Examples of Bad Private Keys C.4. Examples of Bad 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.
C.4.1. ML-KEM Inconsistent Seed and Expanded Private Keys C.4.1. ML-KEM Inconsistent Seed and Expanded Private Keys
Four ML-KEM-512-PrivateKey examples of inconsistent seed and expanded Four ML-KEM-512-PrivateKey examples of inconsistent seed and expanded
private keys follow: private keys are shown as follows:
1. The first ML-KEM-512-PrivateKey example includes the both CHOICE 1. The first ML-KEM-512-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. expanded values can be checked for inconsistencies.
2. The second ML-KEM-512-PrivateKey example includes only 2. The second ML-KEM-512-PrivateKey example includes only
expandedKey. The expanded private key has a mutated s_0 and a expandedKey. The expanded private key has a mutated s_0 and a
valid public key hash, but a pairwise consistency check would valid public key hash, but a pairwise consistency check would
find that the public key fails to match private. find that the public key fails to match private.
3. The third ML-KEM-512-PrivateKey example includes only 3. The third ML-KEM-512-PrivateKey example includes only
expandedKey. The expanded private key has a mutated H(ek); both expandedKey. The expanded private key has a mutated H(ek); both
a public key digest check and a pairwise consistency check should a public key digest check and a pairwise consistency check should
fail. fail.
4. The fourth ML-KEM-512-PrivateKey example includes the both CHOICE 4. The fourth ML-KEM-512-PrivateKey example includes the both
, i.e., both seed and expandedKey are included. There is CHOICE, i.e., both seed and expandedKey are included. There is
mismatch of the seed and expanded private key in only the z mismatch of the seed and expanded private key in only the z
implicit rejection secret; here the private and public vectors implicit rejection secret; here, the private and public vectors
match and the pairwise consistency check passes, but z is match and the pairwise consistency check passes, but z is
different. different.
The following is the first example: The following is the first example:
-----BEGIN PRIVATE KEY----- -----BEGIN PRIVATE KEY-----
MIIGvgIBADALBglghkgBZQMEBAEEggaqMIIGpgRAAAECAwQFBgcICQoLDA0ODxAR MIIGvgIBADALBglghkgBZQMEBAEEggaqMIIGpgRAAAECAwQFBgcICQoLDA0ODxAR
EhMUFRYXGBkaGxwdHh8hIiMkJSYnKCkqKywtLi8wMTIzNDU2Nzg5Ojs8PT4/QASC EhMUFRYXGBkaGxwdHh8hIiMkJSYnKCkqKywtLi8wMTIzNDU2Nzg5Ojs8PT4/QASC
BmDvsn6JOEO1+bZhFYaTegU33BzhWY5u8TDVVBiwaUFnGLk3E4KY1lkkOQvUIErq BmDvsn6JOEO1+bZhFYaTegU33BzhWY5u8TDVVBiwaUFnGLk3E4KY1lkkOQvUIErq
c6VzJCCGVwzLkAdwiCoTOZIeHEYlqwgwpJUosrxyCyFgSFL9d57oFT3+QyRXG5tG c6VzJCCGVwzLkAdwiCoTOZIeHEYlqwgwpJUosrxyCyFgSFL9d57oFT3+QyRXG5tG
skipping to change at line 3167 skipping to change at line 3125
contributions to this document: Corey Bonnell, Deirdre Connolly, contributions to this document: Corey Bonnell, Deirdre Connolly,
Viktor Dukhovni, Alicja Kario, Russ Housley, Mike Ounsworth, Daniel Viktor Dukhovni, Alicja Kario, Russ Housley, Mike Ounsworth, Daniel
Van Geest, Thom Wiggers, and Carl Wallace. Van Geest, Thom Wiggers, and Carl Wallace.
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, and Wei-Jun St. Johns, Falko Strenzke, Filippo Valsorda, and Wei-Jun Wang.
Wang.
Authors' Addresses Authors' Addresses
Sean Turner Sean Turner
sn3rd sn3rd
Email: sean@sn3rd.com Email: sean@sn3rd.com
Panos Kampanakis Panos Kampanakis
AWS AWS
Email: kpanos@amazon.com Email: kpanos@amazon.com
 End of changes. 67 change blocks. 
193 lines changed or deleted 150 lines changed or added

This html diff was produced by rfcdiff 1.48.