Internet DRAFT - draft-ietf-lamps-cms-kyber
draft-ietf-lamps-cms-kyber
LAMPS J. Prat
Internet-Draft CryptoNext Security
Intended status: Standards Track M. Ounsworth
Expires: 3 September 2024 Entrust
D. Van Geest
CryptoNext Security
2 March 2024
Use of ML-KEM in the Cryptographic Message Syntax (CMS)
draft-ietf-lamps-cms-kyber-03
Abstract
The Module-Lattice-based Key-Encapsulation Mechanism (ML-KEM)
Algorithm is a one-pass (store-and-forward) cryptographic mechanism
for an originator to securely send keying material to a recipient
using the recipient's ML-KEM public key. Three parameters sets for
the ML-KEM Algorithm are specified by NIST in [FIPS203-ipd] [EDNOTE:
Change to [FIPS203] when it is published]. In order of increasing
security strength (and decreasing performance), these parameter sets
are ML-KEM-512, ML-KEM-768, and ML-KEM-1024. This document specifies
the conventions for using ML-KEM with the Cryptographic Message
Syntax (CMS) using KEMRecipientInfo as specified in
[I-D.ietf-lamps-cms-kemri].
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-kyber/.
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
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Prat, et al. Expires 3 September 2024 [Page 1]
Internet-Draft ML-KEM in CMS March 2024
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 3 September 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3
1.2. KEMs . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. ML-KEM . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. CMS KEMRecipientInfo Processing Summary . . . . . . . . . 5
2. Use of the ML-KEM Algorithm in CMS . . . . . . . . . . . . . 6
2.1. RecipientInfo Conventions . . . . . . . . . . . . . . . . 6
2.2. Underlying Components . . . . . . . . . . . . . . . . . . 7
2.2.1. KDF . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.2. Components for ML-KEM in CMS . . . . . . . . . . . . 7
2.3. Certificate Conventions . . . . . . . . . . . . . . . . . 8
2.4. SMIME Capabilities Attribute Conventions . . . . . . . . 9
3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 14
Prat, et al. Expires 3 September 2024 [Page 2]
Internet-Draft ML-KEM in CMS March 2024
A.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 14
Appendix B. Revision History . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
ML-KEM is an IND-CCA2-secure key-encapsulation mechanism (KEM)
standardized in [FIPS203] by the US NIST PQC Project [NIST-PQ].
Native support for Key Encapsulation Mechanisms (KEMs) was added to
CMS in [I-D.ietf-lamps-cms-kemri], which defines the KEMRecipientInfo
structure for the use of KEM algorithms for the CMS enveloped-data
content type, the CMS authenticated-data content type, and the CMS
authenticated-enveloped-data content type. This document specifies
the direct use of ML-KEM in the KEMRecipientInfo structure in CMS
using each of the three parameter sets from [FIPS203], namely MK-KEM-
512, ML-KEM-768, and ML-KEM-1024. It does not address or preclude
the use of ML-KEM as part of any hybrid scheme.
1.1. Conventions and Terminology
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
BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.2. KEMs
All KEM algorithms provides three functions: KeyGen(), Encapsulate(),
and Decapsulate():
KeyGen() -> (pk, sk):
Generate the public key (pk) and a private key (sk).
Encapsulate(pk) -> (ct, ss):
Given the recipient's public key (pk), produce a ciphertext (ct)
to be passed to the recipient and a shared secret (ss) for use by
the originator.
Decapsulate(sk, ct) -> ss:
Given the private key (sk) and the ciphertext (ct), produce the
shared secret (ss) for the recipient.
Prat, et al. Expires 3 September 2024 [Page 3]
Internet-Draft ML-KEM in CMS March 2024
The main security property for KEMs standardized in the NIST Post-
Quantum Cryptography Standardization Project [NIST-PQ] is
indistinguishability under adaptive chosen ciphertext attacks (IND-
CCA2), which means that shared secret values should be
indistinguishable from random strings even given the ability to have
arbitrary ciphertexts decapsulated. IND-CCA2 corresponds to security
against an active attacker, and the public key / secret key pair can
be treated as a long-term key or reused. A weaker security notion is
indistinguishability under chosen plaintext attacks (IND-CPA), which
means that the shared secret values should be indistinguishable from
random strings given a copy of the public key. IND-CPA roughly
corresponds to security against a passive attacker, and sometimes
corresponds to one-time key exchange.
IND-CCA2 is a desirable property of encryption mechanisms for CMS
since encryption public keys are often long-term -- for example
contained within X.509 certificates [RFC5280] -- and certain uses of
CMS could allow for the type of decryption oracle that forms the
basis of an adaptive ciphertext attack.
1.3. ML-KEM
ML-KEM is a lattice-based key encapsulation mechanism defined in
[FIPS203]. [EDNOTE: Not actually standardized yet, but will be by
publication]
ML-KEM is using Module Learning with Errors as its underlying
primitive which is a structured lattices variant that offers good
performance and relatively small and balanced key and ciphertext
sizes. ML-KEM was standardized with three parameter sets: ML-KEM-
512, ML-KEM-768, and ML-KEM-1024. These were mapped by NIST to the
three security levels defined in the NIST PQC Project, Level 1, 3,
and 5. These levels correspond to the hardness of breaking AES-128,
AES-192 and AES-256 respectively.
The KEM functions defined above correspond to the following functions
in [FIPS203]:
KeyGen(): ML-KEM.KeyGen() from section 6.1.
Encapsulate(): ML-KEM.Encaps() from section 6.2.
Decapsulate(): ML-KEM.Decaps() from section 6.3.
All security levels of ML-KEM use SHA3-256, SHA3-512, SHAKE256, and
SHAKE512 internally. This informs the choice of KDF within this
document.
Prat, et al. Expires 3 September 2024 [Page 4]
Internet-Draft ML-KEM in CMS March 2024
1.4. CMS KEMRecipientInfo Processing Summary
Processing ML-KEM with KEMRecipientInfo follows the same steps as
Section 2 of [I-D.ietf-lamps-cms-kemri].
To support the ML-KEM algorithm, the CMS originator MUST implement
Encapsulate().
Given a content-encryption key CEK, the ML-KEM Algorithm processing
by the originator to produce the values that are carried in the CMS
KEMRecipientInfo can be summarized as:
1. Obtain the shared secret and ciphertext using the
Encapsulate() function of the ML-KEM algorithm and the recipient's
ML-KEM public key:
(ct, ss) = Encapsulate(pk)
2. Derive a key-encryption key KEK from the shared secret:
KEK = KDF(ss)
3. Wrap the CEK with the KEK to obtain wrapped keying material
WK:
WK = WRAP(KEK, CEK)
4. The originator sends the ciphertext and WK to the recipient in
the CMS KEMRecipientInfo structure.
To support the ML-KEM algorithm, the CMS recipient MUST implement
Decapsulate().
The ML-KEM algorithm recipient processing of the values obtained from
the KEMRecipientInfo structure can be summarized as:
1. Obtain the shared secret using the Decapsulate() function of
the ML-KEM algorithm and the recipient's ML-KEM private key:
ss = Decapsulate(sk, ct)
2. Derive a key-encryption key KEK from the shared secret:
KEK = KDF(ss)
3. Unwrap the WK with the KEK to obtain content-encryption key
CEK:
Prat, et al. Expires 3 September 2024 [Page 5]
Internet-Draft ML-KEM in CMS March 2024
CEK = UNWRAP(KEK, WK)
Note that the KDF used to process the KEMRecipientInfo structure MAY
be different from the KDF used in the ML-KEM algorithm.
2. Use of the ML-KEM Algorithm in CMS
The ML-KEM Algorithm MAY be employed for one or more recipients in
the CMS enveloped-data content type [RFC5652], the CMS authenticated-
data content type [RFC5652], or the CMS authenticated-enveloped-data
content type [RFC5083]. In each case, the KEMRecipientInfo
[I-D.ietf-lamps-cms-kemri] is used with with the ML-KEM Algorithm to
securely transfer the content-encryption key from the originator to
the recipient.
2.1. RecipientInfo Conventions
When the ML-KEM Algorithm is employed for a recipient, the
RecipientInfo alternative for that recipient MUST be
OtherRecipientInfo using the KEMRecipientInfo structure as defined in
[I-D.ietf-lamps-cms-kemri]. The fields of the KEMRecipientInfo MUST
have the following values:
version is the syntax version number; it MUST be 0.
rid identifies the recipient's certificate or public key.
kem identifies the KEM algorithm ; it MUST contain one of id-ML-
KEM-512, id-ML-KEM-768, or id-ML-KEM-1024. These identifiers are
reproduced in Section 3.
kemct is the ciphertext produced for this recipient.
kdf identifies the key-derivation algorithm. Note that the KDF
used for CMS RecipientInfo process MAY be different than the KDF
used within the ML-KEM Algorithm.
kekLength is the size of the key-encryption key in octets.
ukm is an optional random input to the key-derivation function.
ML-KEM doesn't place any requirements on the ukm contents.
wrap identifies a key wrapping algorithm used to encrypt the
content-encryption key.
Prat, et al. Expires 3 September 2024 [Page 6]
Internet-Draft ML-KEM in CMS March 2024
2.2. Underlying Components
When ML-KEM is employed in CMS, the security levels of the different
underlying components used within the KEMRecipientInfo structure
SHOULD be consistent.
2.2.1. KDF
KMAC128-KDF and KMAC256-KDF are KMAC-based KDFs specified for use in
CMS in [I-D.ietf-lamps-cms-sha3-hash]. Here, KMAC# indicates the use
of either KMAC128-KDF or KMAC256-KDF.
KMAC#(K, X, L, S) takes the following parameters:
K: the input key-derivation key. In this document this is the
shared secret outputted from the Encapsulate() or Decapsulate()
functions. This corresponds to the IKM KDF input from Section 5
of [I-D.ietf-lamps-cms-kemri].
X: the context, corresponding to the info KDF input from Section 5
of [I-D.ietf-lamps-cms-kemri]. This is the ASN.1 DER encoding of
CMSORIforKEMOtherInfo.
L: the output length, in bits. This corresponds to the L KDF
input from Section 5 of [I-D.ietf-lamps-cms-kemri], which is
identified in the kekLength value from KEMRecipientInfo. The L
KDF input and kekLength values are specified in octets while this
L parameter is specified in bits.
S: the optional customization label. In this document this
parameter is unused, that is it is the zero-length string "".
The object identifier for KMAC128-KDF is id-kmac128 (see Section 3).
The object identifier for KMAC256-KDF is id-kmac256 (see Section 3).
Since the customization label to KMAC# is not used, the parameter
field MUST be absent when id-kmac128 or id-kmac256 is used as part of
an algorithm identifier specifying the KDF to use for ML-KEM in
KemRecipientInfo.
2.2.2. Components for ML-KEM in CMS
For ML-KEM-512, the following underlying components MUST be
supported:
KDF: KMAC128-KDF using id-kmac128
Prat, et al. Expires 3 September 2024 [Page 7]
Internet-Draft ML-KEM in CMS March 2024
Key wrapping: 128-bit AES key wrapping using id-aes128-wrap
[RFC3565]
For ML-KEM-768, the following underlying components MUST be
supported:
KDF: KMAC256-KDF using id-kmac256
Key wrapping: 256-bit AES key wrapping using id-aes256-wrap
[RFC3565]
For ML-KEM-1024, the following underlying components MUST be
supported:
KDF: KMAC256-KDF using id-kmac256
Key wrapping: 256-bit AES key wrapping using id-aes256-wrap
[RFC3565]
The above object identifiers are reproduced for convenience in
Section 3.
An implementation MAY also support other key-derivation functions and
other key-encryption algorithms.
If underlying components other than those specified above are used,
then the following KDF requirements are in effect in addition to
those asserted in [I-D.ietf-lamps-cms-kemri]:
ML-KEM-512 SHOULD be used with a KDF capable of outputting a key
with at least 128 bits of security and with a key wrapping
algorithm with a key length of at least 128 bits.
ML-KEM-768 SHOULD be used with a KDF capable of outputting a key
with at least 192 bits of security and with a key wrapping
algorithm with a key length of at least 192 bits.
ML-KEM-1024 SHOULD be used with a KDF capable of outputting a key
with at least 256 bits of security and with a key wrapping
algorithm with a key length of at least 256 bits.
2.3. Certificate Conventions
The conventions specified in this section augment [RFC5280].
Prat, et al. Expires 3 September 2024 [Page 8]
Internet-Draft ML-KEM in CMS March 2024
A recipient who employs the ML-KEM Algorithm with a certificate MUST
identify the public key in the certificate using the id-ML-KEM-512,
id-ML-KEM-768, or id-ML-KEM-1024 object identifiers following the
conventions specified in [I-D.ietf-lamps-kyber-certificates] and
reproduced in Section 3.
In particular, the key usage certificate extension MUST only contain
keyEncipherment (Section 4.2.1.3 of [RFC5280]).
2.4. SMIME Capabilities Attribute Conventions
Section 2.5.2 of [RFC8551] defines the SMIMECapabilities attribute to
announce a partial list of algorithms that an S/MIME implementation
can support. When constructing a CMS signed-data content type
[RFC5652], a compliant implementation MAY include the
SMIMECapabilities attribute that announces support for one or more of
the ML-KEM Algorithm identifiers.
The SMIMECapability SEQUENCE representing the ML-KEM Algorithm MUST
include one of the ML-KEM object identifiers in the capabilityID
field. When the one of the ML-KEM object identifiers appears in the
capabilityID field, the parameters MUST NOT be present.
3. Identifiers
All identifiers used by ML-KEM in CMS are defined elsewhere but
reproduced here for convenience:
id-TBD-NIST-KEM OBJECT IDENTIFIER ::= { TBD }
id-ML-KEM-512 OBJECT IDENTIFIER ::= { id-TBD-NIST-KEM TBD }
id-ML-KEM-768 OBJECT IDENTIFIER ::= { id-TBD-NIST-KEM TBD }
id-ML-KEM-1024 OBJECT IDENTIFIER ::= { id-TBD-NIST-KEM TBD }
hashAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 }
id-kmac128 OBJECT IDENTIFIER ::= { hashAlgs 21 }
id-kmac256 OBJECT IDENTIFIER ::= { hashAlgs 22 }
aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840)
organization(1) gov(101) csor(3)_ nistAlgorithms(4) 1 }
id-aes128-wrap OBJECT IDENTIFIER ::= { aes 5 }
id-aes256-wrap OBJECT IDENTIFIER ::= { aes 45 }
Prat, et al. Expires 3 September 2024 [Page 9]
Internet-Draft ML-KEM in CMS March 2024
4. Security Considerations
[EDNOTE: many of the security considerations below apply to ML-KEM in
general and are not specific to ML-KEM within CMS. As this document
and draft-ietf-lamps-kyber-certificates approach WGLC, the two
Security Consideration sections should be harmonized and duplicate
text removed.]
The Security Considerations section of
[I-D.ietf-lamps-kyber-certificates] applies to this specification as
well.
The ML-KEM variant and the underlying components need to be selected
consistent with the desired security level. Several security levels
have been identified in the NIST SP 800-57 Part 1
[NIST.SP.800-57pt1r5]. To achieve 128-bit security, ML-KEM-512
SHOULD be used, the key-derivation function SHOULD provide at least
128 bits of security, and the symmetric key-encryption algorithm
SHOULD be AES Key Wrap with a 128-bit key. To achieve 192-bit
security, ML-KEM-768 SHOULD be used, the key-derivation function
SHOULD provide at least 192 bits of security, and the symmetric key-
encryption algorithm SHOULD be AES Key Wrap with a 192-bit key or
larger. In this case AES Key Wrap with a 256-bit key is typically
used because AES-192 is not as commonly deployed. To achieve 256-bit
security, ML-KEM-1024 SHOULD be used, the key-derivation function
SHOULD provide at least 256 bits of security, and the symmetric key-
encryption algorithm SHOULD be AES Key Wrap with a 256-bit key.
Provided all inputs are well-formed, the key establishment procedure
of ML-KEM will never explicitly fail. Specifically, the ML-
KEM.Encaps and ML-KEM.Decaps algorithms from [FIPS203] will always
output a value with the same data type as a shared secret key, and
will never output an error or failure symbol. However, it is
possible (though extremely unlikely) that the process will fail in
the sense that ML-KEM.Encaps and ML-KEM.Decaps will produce different
outputs, even though both of them are behaving honestly and no
adversarial interference is present. In this case, the sender and
recipient clearly did not succeed in producing a shared secret key.
This event is called a decapsulation failure. Estimates for the
decapsulation failure probability (or rate) for each of the ML-KEM
parameter sets are provided in Table 1 [EDNOTE: make sure this
doesn't change] of [FIPS203] and reproduced here in Table 1.
Prat, et al. Expires 3 September 2024 [Page 10]
Internet-Draft ML-KEM in CMS March 2024
+===============+============================+
| Parameter set | Decapsulation failure rate |
+===============+============================+
| ML-KEM-512 | 2^(-139) |
+---------------+----------------------------+
| ML-KEM-768 | 2^(-164) |
+---------------+----------------------------+
| ML-KEM-1024 | 2^(-174) |
+---------------+----------------------------+
Table 1: ML-KEM decapsulation failures rates
Implementations MUST protect the ML-KEM private key, the key-
encryption key, the content-encryption key, message-authentication
key, and the content-authenticated-encryption key. Disclosure of the
ML-KEM private key could result in the compromise of all messages
protected with that key. Disclosure of the key-encryption key, the
content- encryption key, or the content-authenticated-encryption key
could result in compromise of the associated encrypted content.
Disclosure of the key-encryption key, the message-authentication key,
or the content-authenticated-encryption key could allow modification
of the associated authenticated content.
Additional considerations related to key management may be found in
[NIST.SP.800-57pt1r5].
The security of the ML-KEM Algorithm depends on a quality random
number generator. For further discussion on random number
generation, see [RFC4086].
ML-KEM encapsulation and decapsulation only outputs a shared secret
and ciphertext. Implementations SHOULD NOT use intermediate values
directly for any purpose.
Implementations SHOULD NOT reveal information about intermediate
values or calculations, whether by timing or other "side channels",
otherwise an opponent may be able to determine information about the
keying data and/or the recipient's private key. Although not all
intermediate information may be useful to an opponent, it is
preferable to conceal as much information as is practical, unless
analysis specifically indicates that the information would not be
useful to an opponent.
Generally, good cryptographic practice employs a given ML-KEM key
pair in only one scheme. This practice avoids the risk that
vulnerability in one scheme may compromise the security of the other,
and may be essential to maintain provable security.
Prat, et al. Expires 3 September 2024 [Page 11]
Internet-Draft ML-KEM in CMS March 2024
Parties MAY gain assurance that implementations are correct through
formal implementation validation, such as the NIST Cryptographic
Module Validation Program (CMVP) [CMVP].
5. IANA Considerations
None.
Within the CMS, algorithms are identified by object identifiers
(OIDs). All of the OIDs used in this document were assigned in other
IETF documents, in ISO/IEC standards documents, by the National
Institute of Standards and Technology (NIST).
6. Acknowledgements
This document borrows heavily from [I-D.ietf-lamps-rfc5990bis],
[FIPS203], and [I-D.kampanakis-ml-kem-ikev2]. Thanks go to the
authors of those documents. "Copying always makes things easier and
less error prone" - RFC8411.
Thanks to Carl Wallace for the detailed review and interoperability
testing.
7. References
7.1. Normative References
[FIPS203] "TBD", n.d..
[FIPS203-ipd]
National Institute of Standards and Technology (NIST),
"Module-Lattice-based Key-Encapsulation Mechanism
Standard", 24 August 2023,
<https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.203.ipd.pdf>.
[I-D.ietf-lamps-cms-kemri]
Housley, R., Gray, J., and T. Okubo, "Using Key
Encapsulation Mechanism (KEM) Algorithms in the
Cryptographic Message Syntax (CMS)", Work in Progress,
Internet-Draft, draft-ietf-lamps-cms-kemri-08, 6 February
2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
lamps-cms-kemri-08>.
Prat, et al. Expires 3 September 2024 [Page 12]
Internet-Draft ML-KEM in CMS March 2024
[I-D.ietf-lamps-cms-sha3-hash]
Housley, R., "Use of the SHA3 One-way Hash Functions in
the Cryptographic Message Syntax (CMS)", Work in Progress,
Internet-Draft, draft-ietf-lamps-cms-sha3-hash-01, 1 March
2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
lamps-cms-sha3-hash-01>.
[I-D.ietf-lamps-kyber-certificates]
Turner, S., Kampanakis, P., Massimo, J., and B.
Westerbaan, "Internet X.509 Public Key Infrastructure -
Algorithm Identifiers for Kyber", Work in Progress,
Internet-Draft, draft-ietf-lamps-kyber-certificates-02, 23
October 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-lamps-kyber-certificates-02>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES)
Encryption Algorithm in Cryptographic Message Syntax
(CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003,
<https://www.rfc-editor.org/rfc/rfc3565>.
[RFC5083] Housley, R., "Cryptographic Message Syntax (CMS)
Authenticated-Enveloped-Data Content Type", RFC 5083,
DOI 10.17487/RFC5083, November 2007,
<https://www.rfc-editor.org/rfc/rfc5083>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/rfc/rfc5652>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
Message Specification", RFC 8551, DOI 10.17487/RFC8551,
April 2019, <https://www.rfc-editor.org/rfc/rfc8551>.
Prat, et al. Expires 3 September 2024 [Page 13]
Internet-Draft ML-KEM in CMS March 2024
7.2. Informative References
[CMVP] National Institute of Standards and Technology,
"Cryptographic Module Validation Program", 2016,
<https://csrc.nist.gov/projects/cryptographic-module-
validation-program>.
[I-D.ietf-lamps-rfc5990bis]
Housley, R. and S. Turner, "Use of the RSA-KEM Algorithm
in the Cryptographic Message Syntax (CMS)", Work in
Progress, Internet-Draft, draft-ietf-lamps-rfc5990bis-04,
19 October 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-lamps-rfc5990bis-04>.
[I-D.kampanakis-ml-kem-ikev2]
Kampanakis, P. and G. Ravago, "Post-quantum Hybrid Key
Exchange with ML-KEM in the Internet Key Exchange Protocol
Version 2 (IKEv2)", Work in Progress, Internet-Draft,
draft-kampanakis-ml-kem-ikev2-02, 19 February 2024,
<https://datatracker.ietf.org/doc/html/draft-kampanakis-
ml-kem-ikev2-02>.
[NIST-PQ] National Institute of Standards and Technology, "Post-
Quantum Cryptography Project", 20 December 2016,
<https://csrc.nist.gov/projects/post-quantum-
cryptography>.
[NIST.SP.800-57pt1r5]
Barker, E. and NIST, "Recommendation for key
management:part 1 - general", NIST Special Publications
(General) 800-57pt1r5, DOI 10.6028/NIST.SP.800-57pt1r5,
May 2020,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-57pt1r5.pdf>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/rfc/rfc4086>.
Appendix A. ASN.1 Module
[EDNOTE: Do we need an ASN.1 module? We haven't defined any new
ASN.1. Yes, see S/MIME ASN.1 changes to composite-kem draft]
A.1. Examples
Prat, et al. Expires 3 September 2024 [Page 14]
Internet-Draft ML-KEM in CMS March 2024
EDITOR'S NOTE' - TODO
section to be completed
Appendix B. Revision History
[EDNOTE: remove before publishing]
* draft-ietf-lamps-cms-kyber-03:
- Switch MTI KDF from HKDF to KMAC.
* draft-ietf-lamps-cms-kyber-02:
- Rearrange and rewrite to align with rfc5990bis and I-D.ietf-
lamps-cms-kemri
- Move Revision History to end to avoid renumbering later
- Add Security Considerations
* draft-ietf-lamps-cms-kyber-01:
- Details of the KEMRecipientInfo content when using Kyber;
- Editorial changes.
* draft-ietf-lamps-cms-kyber-00:
- Use of KEMRecipientInfo to communicate algorithm info;
- Editorial changes.
Authors' Addresses
Julien Prat
CryptoNext Security
16, Boulevard Saint-Germain
75005 Paris
France
Email: julien.prat@cryptonext-security.com
Mike Ounsworth
Entrust Limited
2500 Solandt Road -- Suite 100
Ottawa, Ontario K2K 3G5
Canada
Email: mike.ounsworth@entrust.com
Prat, et al. Expires 3 September 2024 [Page 15]
Internet-Draft ML-KEM in CMS March 2024
Daniel Van Geest
CryptoNext Security
16, Boulevard Saint-Germain
75005 Paris
France
Email: daniel.vangeest.ietf@gmail.com
Prat, et al. Expires 3 September 2024 [Page 16]
