Skip to content
RFC Editor - Official home of RFCs

RFC 9629: Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS)

  • R. Housley,  
  • J. Gray,  
  • T. Okubo
Proposed Standard

Abstract

The Cryptographic Message Syntax (CMS) supports key transport and key agreement algorithms. In recent years, cryptographers have been specifying Key Encapsulation Mechanism (KEM) algorithms, including quantum-secure KEM algorithms. This document defines conventions for the use of KEM algorithms by the originator and recipients to encrypt and decrypt CMS content. This document updates RFC 5652.

Status of This Memo

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

1. Introduction

This document updates "" [].

The CMS enveloped-data content type [] and the CMS authenticated-enveloped-data content type [] support both key transport and key agreement algorithms to establish the key used to encrypt and decrypt the content. In recent years, cryptographers have been specifying Key Encapsulation Mechanism (KEM) algorithms, including quantum-secure KEM algorithms. This document defines conventions for the use of KEM algorithms for the CMS enveloped-data content type and the CMS authenticated-enveloped-data content type.

A KEM algorithm is a one-pass (store-and-forward) mechanism for transporting random keying material to a recipient using the recipient's public key. This means that the originator and the recipients do not need to be online at the same time. The recipient's private key is needed to recover the random keying material, which is then treated as a pairwise shared secret (ss) between the originator and recipient.

The KEMRecipientInfo structure defined in this document uses the pairwise shared secret as an input to a key derivation function (KDF) to produce a pairwise key-encryption key (KEK). Then, the pairwise KEK is used to encrypt a content-encryption key (CEK) or a content-authenticated-encryption key (CAEK) for that recipient. All of the recipients receive the same CEK or CAEK.

In this environment, security depends on three things. First, the KEM algorithm must be secure against adaptive chosen ciphertext attacks. Second, the key-encryption algorithm must provide confidentiality and integrity protection. Third, the choices of the KDF and the key-encryption algorithm need to provide the same level of security as the KEM algorithm.

A KEM algorithm provides three functions:

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 shared secret (ss) for the originator.
Decapsulate(sk, ct) -> ss:
Given the private key (sk) and the ciphertext (ct), produce the shared secret (ss) for the recipient.

To support a particular KEM algorithm, the CMS originator MUST implement the KEM Encapsulate() function.

To support a particular KEM algorithm, the CMS recipient MUST implement the KEM KeyGen() function and the KEM Decapsulate() function. The recipient's public key is usually carried in a certificate [].

1.1. 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 BCP 14 [] [] when, and only when, they appear in all capitals, as shown here.

1.2. ASN.1

CMS values are generated using ASN.1 [X.680], which uses the Basic Encoding Rules (BER) and the Distinguished Encoding Rules (DER) [X.690].

1.3. CMS Version Numbers

As described in Section 1.3 of [], the major data structures include a version number as the first item in the data structure. The version number is intended to avoid ASN.1 decode errors. Some implementations do not check the version number prior to attempting a decode, and then if a decode error occurs, the version number is checked as part of the error-handling routine. This is a reasonable approach; it places error processing outside of the fast path. This approach is also forgiving when an incorrect version number is used by the originator.

Whenever the structure is updated, a higher version number will be assigned. However, to ensure maximum interoperability, the higher version number is only used when the new syntax feature is employed. That is, the lowest version number that supports the generated syntax is used.

2. KEM Processing Overview

KEM algorithms can be used with three CMS content types: the enveloped-data content type [], the authenticated-data content type [], or the authenticated-enveloped-data content type []. For simplicity, the terminology associated with the enveloped-data content type will be used in this overview.

The originator randomly generates the CEK (or the CAEK), and then all recipients obtain that key as an encrypted object within the KEMRecipientInfo encryptedKey field explained in Section 3. All recipients use the originator-generated symmetric key to decrypt the CMS message.

A KEM algorithm and a key derivation function are used to securely establish a pairwise symmetric KEK, which is used to encrypt the originator-generated CEK (or the CAEK).

In advance, each recipient uses the KEM KeyGen() function to create a key pair. The recipient will often obtain a certificate [] that includes the newly generated public key. Whether the public key is certified or not, the newly generated public key is made available to potential originators.

The originator establishes the CEK (or the CAEK) using these steps:

  1. The CEK (or the CAEK) is generated at random.

  2. For each recipient:

    • The recipient's public key is used with the KEM Encapsulate() function to obtain a pairwise shared secret (ss) and the ciphertext for the recipient.

    • The key derivation function is used to derive a pairwise symmetric KEK, from the pairwise ss and other data that is optionally sent in the ukm field.

    • The KEK is used to encrypt the CEK for this recipient.

  3. The CEK (or the CAEK) is used to encrypt the content for all recipients.

The recipient obtains the CEK (or the CAEK) using these steps:

  1. The recipient's private key and the ciphertext are used with the KEM Decapsulate() function to obtain a pairwise ss.

  2. The key derivation function is used to derive a pairwise symmetric KEK, from the pairwise ss and other data that is optionally sent in the ukm field.

  3. The KEK is used to decrypt the CEK (or the CAEK).

  4. The CEK (or the CAEK) is used to decrypt the content.

3. KEM Recipient Information

This document defines KEMRecipientInfo for use with KEM algorithms. As specified in Section 6.2.5 of [], recipient information for additional key management techniques is represented in the OtherRecipientInfo type. Each key management technique is identified by a unique ASN.1 object identifier.

The object identifier associated with KEMRecipientInfo is:

  id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
    rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 13 }

  id-ori-kem OBJECT IDENTIFIER ::= { id-ori 3 }

The KEMRecipientInfo type is:

  KEMRecipientInfo ::= SEQUENCE {
    version CMSVersion,  -- always set to 0
    rid RecipientIdentifier,
    kem KEMAlgorithmIdentifier,
    kemct OCTET STRING,
    kdf KeyDerivationAlgorithmIdentifier,
    kekLength INTEGER (1..65535),
    ukm [0] EXPLICIT UserKeyingMaterial OPTIONAL,
    wrap KeyEncryptionAlgorithmIdentifier,
    encryptedKey EncryptedKey }

The fields of the KEMRecipientInfo type have the following meanings:

version is the syntax version number. The version MUST be 0. The CMSVersion type is described in Section 10.2.5 of [].

rid specifies the recipient's certificate or key that was used by the originator with the KEM Encapsulate() function. The RecipientIdentifier provides two alternatives for specifying the recipient's certificate [], and thereby the recipient's public key. The recipient's certificate MUST contain a KEM public key. Therefore, a recipient X.509 version 3 certificate that contains a key usage extension MUST assert the keyEncipherment bit. The issuerAndSerialNumber alternative identifies the recipient's certificate by the issuer's distinguished name and the certificate serial number; the subjectKeyIdentifier alternative identifies the recipient's certificate by a key identifier. When an X.509 certificate is referenced, the key identifier matches the X.509 subjectKeyIdentifier extension value. When other certificate formats are referenced, the documents that specify the certificate format and their use with the CMS must include details on matching the key identifier to the appropriate certificate field. For recipient processing, implementations MUST support both of these alternatives for specifying the recipient's certificate. For originator processing, implementations MUST support at least one of these alternatives.

kem identifies the KEM algorithm, and any associated parameters, used by the originator. The KEMAlgorithmIdentifier is described in Section 4.

kemct is the ciphertext produced by the KEM Encapsulate() function for this recipient.

kdf identifies the key derivation function, and any associated parameters, used by the originator to generate the KEK. The KeyDerivationAlgorithmIdentifier is described in Section 10.1.6 of [].

kekLength is the size of the KEK in octets. This value is one of the inputs to the key derivation function. The upper bound on the integer value is provided to make it clear to implementers that support for very large integer values is not needed. Implementations MUST confirm that the value provided is consistent with the key-encryption algorithm identified in the wrap field below.

ukm is optional user keying material. When the ukm value is provided, it is used as part of the info structure described in Section 5 to provide a context input to the key derivation function. For example, the ukm value could include a nonce, application-specific context information, or an identifier for the originator. A KEM algorithm may place requirements on the ukm value. Implementations that do not support the ukm field SHOULD gracefully discontinue processing when the ukm field is present. Note that this requirement expands the original purpose of the ukm described in Section 10.2.6 of []; it is not limited to being used with key agreement algorithms.

wrap identifies a key-encryption algorithm used to encrypt the CEK. The KeyEncryptionAlgorithmIdentifier is described in Section 10.1.3 of [].

encryptedKey is the result of encrypting the CEK or the CAEK (the content-authenticated-encryption key, as discussed in []) with the KEK. EncryptedKey is an OCTET STRING.

4. KEM Algorithm Identifier

The KEMAlgorithm