]> ZTE Corp.

China song.xueyan2@zte.com.cn

China Mobile

China chenmeiling@chinamobile.com

LAMPS PQ FrodoKEM CMS This document specifies the conventions for using Composite FrodoKEM algorithms with the Cryptographic Message Syntax (CMS). Composite FrodoKEM combines FrodoKEM with traditional algorithms (RSA-OAEP, ECDH, X25519, X448) to provide hybrid post-quantum key encapsulation.

Introduction defines a collection of Key Encapsulation Mechanism (KEM) algorithms, referred to as Composite FrodoKEM, which combine FrodoKEM with traditional algorithms RSA-OAEP, ECDH, X25519, and X448. defines the KEMRecipientInfo structure for the use of KEM algorithms for the Cryptographic Message Syntax (CMS) enveloped-data content type, the CMS authenticated-data content type, and the CMS authenticated-enveloped-data content type. This document acts as a companion to by providing conventions for using Composite FrodoKEM algorithms with the KEMRecipientInfo structure within the CMS. specifies two implementation variants for each FrodoKEM parameter set that differ in the internal pseudorandom function: a SHAKE variant and an AES variant. This document supports both variants for each Composite FrodoKEM algorithm.

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.

ASN.1 Module CMS values are generated using ASN.1 , using the Basic Encoding Rules (BER) and the Distinguished Encoding Rules (DER) .

Composite FrodoKEM FrodoKEM is a lattice-based KEM using the standard Learning With Errors (LWE) problem over unstructured lattices as its underlying primitive. It was standardized by ISO with two primary parameter sets: FrodoKEM-976 for NIST security level 3 and FrodoKEM-1344 for NIST security level 5. Composite FrodoKEM pairs FrodoKEM-976 or FrodoKEM-1344 with RSA-OAEP, ECDH, X25519, or X448 at similar security levels such that the shared secret key from each component algorithm is combined into a single shared secret key. All KEM algorithms provide three functions: KeyGen(), Encapsulate(), and Decapsulate(). The following summarizes these three functions for Composite FrodoKEM, see section 3 of for details: KeyGen() -> (ek, dk): Generate the public encapsulation key (ek) and a private decapsulation key (dk). Encapsulate(ek) -> (ct, ss): Given the recipient's public key (ek), produce both a ciphertext (ct) to be passed to the recipient and a shared secret (ss) for use by the originator. Decapsulate(dk, ct) -> ss: Given the private key (dk) and the ciphertext (ct), produce the shared secret (ss) for the recipient.

Use of Composite FrodoKEM in the CMS Composite FrodoKEM algorithms MAY be employed for one or more recipients in the CMS enveloped-data content type , the CMS authenticated-data content type , or the CMS authenticated- enveloped-data content type . In each case, the KEMRecipientInfo type is used with the Composite FrodoKEM algorithm to securely transfer the content-encryption key from the originator to the recipient. Processing a Composite FrodoKEM algorithm with KEMRecipientInfo follows the same steps as Section 2 of . To support the Composite FrodoKEM algorithm, a CMS originator MUST implement the Encapsulate() function and a CMS recipient MUST implement the Decapsulate() function.

RecipientInfo Conventions When a Composite FrodoKEM algorithm is employed for a recipient, the RecipientInfo alternative for that recipient MUST be OtherRecipientInfo using the KEMRecipientInfo structure as defined in . 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 the Composite FrodoKEM OIDs in Section 3.

kemct

The ciphertext produced for this recipient. Implementations MUST be prepared to process OCTET STRING values of up to approximately 22,100 octets (21,829 octets for FrodoKEM-1344-ECDH-P521) due to the large ciphertext size of FrodoKEM-1344.

kdf

Identifies the key derivation algorithm. Note that the Key Derivation Function (KDF) used for CMS RecipientInfo processing MAY be different than the KDF used within the Composite FrodoKEM algorithm. Implementations MUST support the HMAC-based Key Derivation Function (HKDF) with SHA-256 , using the id-alg-hkdf-with-sha256 OID . 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 Composite FrodoKEM 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 for more information about the ukm parameter.

wrap

Identifies a key-encryption algorithm used to encrypt the content- encryption key. Implementations supporting FrodoKEM-976-based composites MUST support the AES-Wrap-192 key-encryption algorithm using the id-aes192-wrap key-encryption algorithm OID . Implementations supporting FrodoKEM-1344-based composites MUST support the AES-Wrap-256 key-encryption algorithm using the id-aes256-wrap key-encryption algorithm OID . Implementations MAY support other key-encryption algorithms as well.

encryptedKey

The result of encrypting the content-encryption key or the content-authenticated-encryption key with the key-encryption key.

Underlying Components If underlying components other than those specified in this document are used, then the following table gives the minimum requirements on the components used with Composite FrodoKEM in the KEMRecipientInfo type in order to satisfy the KDF and key wrapping algorithm requirements from Section 7 of . The components are chosen based on the FrodoKEM variant used within the Composite FrodoKEM algorithm. (*) Although 192-bit symmetric key-encryption strength is theoretically appropriate for FrodoKEM-976, a 256-bit AES Key Wrap key is often used in practice because AES-192 is not as commonly deployed. Implementations MAY use AES-Wrap-256 for FrodoKEM-976- based composites.

Use of the HKDF-Based Key Derivation Function The HKDF function is a composition of the HKDF-Extract and HKDF- Expand functions. 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 . The info parameter is independently encoded by the originator and recipient from the KEMRecipientInfo fields. Implementations MUST confirm that L is consistent with the key size of the key-encryption algorithm.

Certificate Conventions specifies the profile for using X.509 certificates in Internet applications. A recipient static public key is needed for Composite FrodoKEM and the originator obtains that public key from the recipient's certificate. The conventions for carrying Composite FrodoKEM public keys are specified in .

SMIME Capabilities Attribute Conventions Section 2.5.2 of 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 , a compliant implementation MAY include the SMIMECapabilities attribute that announces support for one or more of the Composite FrodoKEM algorithm identifiers. The SMIMECapability SEQUENCE representing the Composite FrodoKEM algorithm MUST include one of the Composite FrodoKEM OIDs in the capabilityID field. When one of the Composite FrodoKEM OIDs appears in the capabilityID field, the parameters MUST NOT be present.

Identifiers All identifiers used to indicate Composite FrodoKEM within the CMS are defined in and ; and the corresponding OIDs are defined in . They are reproduced here for convenience:

Security Considerations The Composite FrodoKEM encapsulation algorithm performs the following steps: The Security Considerations sections of and apply to this document. The latter provides comprehensive discussion of key protection, random number generation, intermediate value handling, side-channel resistance, and key reuse for composite KEM algorithms in CMS, all of which are equally applicable to Composite FrodoKEM. Additional security considerations specific to FrodoKEM, including side-channel resistance, fault attack mitigations, and parameter set selection guidance, are discussed in .

IANA Considerations

PKIX Module Identifier Registry IANA is requested to allocate values from the "SMI Security for PKIX Algorithm" registry (1.3.6.1.5.5.7.6) for the Composite FrodoKEM algorithm identifiers listed in Section 3. These allocations are specified in .

S/MIME Module Identifier Registry IANA is requested to allocate a value from the "SMI Security for S/ MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry for the included ASN.1 module. SMI Security for S/MIME Module Identifier

Decimal	Description	References
TBDMOD	id-mod-composite-frodokem-cms-2026	This Document

References Normative References Informative References National Institute of Standards and Technology (U.S.) ITU-T ITU-T ISO CryptoNext Security Entrust Limited Entrust Limited Microsoft NXP Semiconductors Federal Office for Information Security University of Waterloo ISO standardized FrodoKEM in June 2026 [ISO18033-2-AMD2]. This document provides security guidance for FrodoKEM for use in protocols. It explains what security claims protocol designers may rely on, what assumptions and conditions are required, what parameter sets are in scope, and what implementors need to do to use FrodoKEM safely. The scope follows the current FrodoKEM Internet-Draft [I-D.FrodoKEM]. ZTE Corp. China Mobile Composite FrodoKEM defines combinations of FrodoKEM with RSA-OAEP, ECDH, X25519, and X448. This document specifies the algorithm definitions, key formats, and certificate conventions for using Composite FrodoKEM in the X.509 Public Key Infrastructure.