| Internet-Draft | Composite FrodoKEM for X.509 PKI | September 2026 |
| Song & Chen | Expires 2 April 2027 | [Page] |
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.¶
This Internet-Draft is submitted in full conformance with the 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 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 2 April 2027.¶
Copyright (c) 2026 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.¶
[I-D.song-lamps-pq-composite-frodokem] defines a collection of Key Encapsulation Mechanism (KEM) algorithms, referred to as Composite FrodoKEM, which combine FrodoKEM [ISO18033-2-AMD2] with traditional algorithms RSA-OAEP, ECDH, X25519, and X448. [RFC9629] defines the KEMRecipientInfo structure for the use of KEM algorithms for the Cryptographic Message Syntax (CMS) [RFC5652] 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 [I-D.song-lamps-pq-composite-frodokem] by providing conventions for using Composite FrodoKEM algorithms with the KEMRecipientInfo structure within the CMS.¶
[I-D.song-lamps-pq-composite-frodokem] 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.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
CMS values are generated using ASN.1 [X680], using the Basic Encoding Rules (BER) and the Distinguished Encoding Rules (DER) [X690].¶
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 [I-D.song-lamps-pq-composite-frodokem] 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.¶
Composite FrodoKEM algorithms 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] 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 [RFC9629]. To support the Composite FrodoKEM algorithm, a CMS originator MUST implement the Encapsulate() function and a CMS recipient MUST implement the Decapsulate() function.¶
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 [RFC9629].¶
The fields of the KEMRecipientInfo have the following meanings:¶
The syntax version number; it MUST be 0.¶
Identifies the recipient's certificate or public key.¶
Identifies the KEM algorithm; it MUST contain one of the Composite FrodoKEM OIDs in Section 3.¶
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.¶
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) [RFC5869] with SHA-256 [FIPS180], using the id-alg-hkdf-with-sha256 OID [RFC8619]. The parameter field MUST be absent when this OID appears within the ASN.1 type AlgorithmIdentifier. Implementations MAY support other KDFs as well.¶
The size of the key-encryption key in octets.¶
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 [RFC9629] for more information about the ukm parameter.¶
Identifies a key-encryption algorithm used to encrypt the content- encryption key. Implementations supporting FrodoKEM-976-based composites MUST support the AES-Wrap-192 [RFC3394] key-encryption algorithm using the id-aes192-wrap key-encryption algorithm OID [RFC3565]. Implementations supporting FrodoKEM-1344-based composites 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.¶
The result of encrypting the content-encryption key or the content-authenticated-encryption key with the key-encryption key.¶
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 [RFC9629]. The components are chosen based on the FrodoKEM variant used within the Composite FrodoKEM algorithm.¶
+==========+================+==============+=====================+ | Security | FrodoKEM | KDF Preimage | Symmetric Key- | | Strength | Variant | Strength | Encryption Strength | +==========+================+==============+=====================+ | 192-bit | FrodoKEM-976 | 192-bit | 192-bit (*) | +----------+----------------+--------------+---------------------+ | 256-bit | FrodoKEM-1344 | 256-bit | 256-bit | +----------+----------------+--------------+---------------------+¶
(*) 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.¶
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 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.¶
[RFC5280] 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 [I-D.song-lamps-pq-composite-frodokem].¶
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 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.¶
All identifiers used to indicate Composite FrodoKEM within the CMS are defined in [I-D.song-lamps-pq-composite-frodokem] and [RFC8619]; and the corresponding OIDs are defined in [RFC3565]. They are reproduced here for convenience:¶
-- SHAKE Variants
id-FrodoKEM976-RSA2048-SHA3-256 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) alg(6) TBD1 }
id-FrodoKEM976-RSA3072-SHA3-256 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) alg(6) TBD2 }
id-FrodoKEM976-RSA4096-SHA3-256 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) alg(6) TBD3 }
id-FrodoKEM976-X25519-SHA3-256 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) alg(6) TBD4 }
id-FrodoKEM976-ECDH-P256-SHA3-256 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) alg(6) TBD5 }
id-FrodoKEM976-ECDH-P384-SHA3-256 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) alg(6) TBD6 }
id-FrodoKEM976-ECDH-brainpoolP256r1-SHA3-256
OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) alg(6) TBD7 }
id-FrodoKEM1344-RSA3072-SHA3-256 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) alg(6) TBD8 }
id-FrodoKEM1344-ECDH-P384-SHA3-256 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) alg(6) TBD9 }
id-FrodoKEM1344-ECDH-brainpoolP384r1-SHA3-256
OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) alg(6) TBD10 }
id-FrodoKEM1344-X448-SHA3-256 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) alg(6) TBD11 }
id-FrodoKEM1344-ECDH-P521-SHA3-256 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) alg(6) TBD12 }
-- AES Variants
id-FrodoKEM976-AES-RSA2048-SHA3-256 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) alg(6) TBD13 }
id-FrodoKEM976-AES-RSA3072-SHA3-256 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) alg(6) TBD14 }
id-FrodoKEM976-AES-RSA4096-SHA3-256 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) alg(6) TBD15 }
id-FrodoKEM976-AES-X25519-SHA3-256 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) alg(6) TBD16 }
id-FrodoKEM976-AES-ECDH-P256-SHA3-256 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) alg(6) TBD17 }
id-FrodoKEM976-AES-ECDH-P384-SHA3-256 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) alg(6) TBD18 }
id-FrodoKEM976-AES-ECDH-brainpoolP256r1-SHA3-256
OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) alg(6) TBD19 }
id-FrodoKEM1344-AES-RSA3072-SHA3-256 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) alg(6) TBD20 }
id-FrodoKEM1344-AES-ECDH-P384-SHA3-256 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) alg(6) TBD21 }
id-FrodoKEM1344-AES-ECDH-brainpoolP384r1-SHA3-256
OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) alg(6) TBD22 }
id-FrodoKEM1344-AES-X448-SHA3-256 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) alg(6) TBD23 }
id-FrodoKEM1344-AES-ECDH-P521-SHA3-256 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) alg(6) TBD24 }
-- KEMRecipientInfo.kdf OIDs
id-alg-hkdf-with-sha256 OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) alg(3) 28 }
-- KEMRecipientInfo.wrap OIDs
aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840)
organization(1) gov(101) csor(3) nistAlgorithms(4) 1 }
id-aes192-wrap OBJECT IDENTIFIER ::= { aes 25 }
id-aes256-wrap OBJECT IDENTIFIER ::= { aes 45 }
¶
The Composite FrodoKEM encapsulation algorithm performs the following steps:¶
The Security Considerations sections of [RFC9629] and [I-D.ietf-lamps-cms-composite-kem] 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 [I-D.longa-cfrg-frodokem-security-considerations].¶
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 [I-D.song-lamps-pq-composite-frodokem].¶
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.¶
| Decimal | Description | References |
|---|---|---|
| TBDMOD | id-mod-composite-frodokem-cms-2026 | This Document |