2. Use of the ML-KEM Algorithm in the CMS
Cette section conserve le texte RFC sur l'utilisation de ML-KEM avec CMS, y compris KEMRecipientInfo, HKDF, AES Key Wrap, ASN.1 identifiers, IANA registration et authenticated-enveloped-data example.
2. Use of the ML-KEM Algorithm in the 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 [RFC9629]
is used with the ML-KEM algorithm to securely transfer the content-
encryption key from the originator to the recipient.
Processing ML-KEM with KEMRecipientInfo follows the same steps as
Section 2 of [RFC9629]. To support the ML-KEM algorithm, a CMS
originator MUST implement the Encapsulate() function and a CMS
recipient MUST implement the Decapsulate() function.
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
[RFC9629].
The fields of the KEMRecipientInfo have the following meanings:
version
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-alg-ml-
kem-512, id-alg-ml-kem-768, or id-alg-ml-kem-1024. These
identifiers are reproduced in Section 3.
kemct
The ciphertext produced for this recipient.
kdf
Identifies the key derivation algorithm. Note that the Key
Derivation Function (KDF) used for CMS RecipientInfo process MAY
be different than the KDF used within the ML-KEM algorithm.
Implementations MUST support the HMAC-based Key Derivation
Function (HKDF) [RFC5869] with SHA-256 [FIPS180] using the id-alg-
hkdf-with-sha256 KDF object identifier (OID) [RFC8619]. As
specified in [RFC8619], the parameter field MUST be absent when
this OID appears within the ASN.1 type AlgorithmIdentifier.
Implementations MAY support other KDFs as well.
kekLength
The size of the key-encryption key in octets.
ukm
Optional input to the KDF. The secure use of ML-KEM in CMS does
not depend on the use of a ukm value, so this document does not
place any requirements on this value. See Section 3 of [RFC9629]
for more information about the ukm parameter.
wrap
Identifies a key-encryption algorithm used to encrypt the content-
encryption key. Implementations supporting ML-KEM-512 MUST
support the AES-Wrap-128 [RFC3394] key-encryption algorithm using
the id-aes128-wrap key-encryption algorithm OID [RFC3565].
Implementations supporting ML-KEM-768 or ML-KEM-1024 MUST support
the AES-Wrap-256 [RFC3394] key-encryption algorithm using the id-
aes256-wrap key-encryption algorithm OID [RFC3565].
Implementations MAY support other key-encryption algorithms as
well.
Appendix C contains an example of establishing a content-encryption
key using ML-KEM in the KEMRecipientInfo type.
2.2. Underlying Components
When ML-KEM is employed in the CMS, the underlying components used
within the KEMRecipientInfo structure SHOULD be consistent with a
minimum desired security level. Several security levels have been
identified in [NIST.SP.800-57pt1r5].
If underlying components other than those specified in Section 2.1
are used, then the following table gives the minimum requirements on
the components used with ML-KEM in the KEMRecipientInfo type in order
to satisfy the KDF and key wrapping algorithm requirements from
Section 7 of [RFC9629]:
+==========+=============+==============+=====================+
| Security | Algorithm | KDF Preimage | Symmetric Key- |
| Strength | | Strength | Encryption Strength |
+==========+=============+==============+=====================+
| 128-bit | ML-KEM-512 | 128-bit | 128-bit |
+----------+-------------+--------------+---------------------+
| 192-bit | ML-KEM-768 | 192-bit | 192-bit (*) |
+----------+-------------+--------------+---------------------+
| 256-bit | ML-KEM-1024 | 256-bit | 256-bit |
+----------+-------------+--------------+---------------------+
Table 1: ML-KEM KEMRecipientInfo Component Security Levels
(*) In the case of AES Key Wrap, a 256-bit key is typically used
because AES-192 is not as commonly deployed.
2.2.1. Use of the HKDF-Based Key Derivation Function
The HKDF function is a composition of the HKDF-Extract and HKDF-
Expand functions.
HKDF(salt, IKM, info, L)
= HKDF-Expand(HKDF-Extract(salt, IKM), info, L)
When used with KEMRecipientInfo, the salt parameter is unused; that
is, it is the zero-length string "". The IKM, info, and L parameters
correspond to the same KDF inputs from Section 5 of [RFC9629]. The
info parameter is independently generated by the originator and
recipient. Implementations MUST confirm that L is consistent with
the key size of the key-encryption algorithm.
2.3. Certificate Conventions
[RFC5280] specifies the profile for using X.509 certificates in
Internet applications. A recipient static public key is needed for
ML-KEM and the originator obtains that public key from the
recipient's certificate. The conventions for carrying ML-KEM public
keys are specified in [RFC9935].
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 OIDs in the capabilityID field. When one
of the ML-KEM OIDs appears in the capabilityID field, the parameters
MUST NOT be present.