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 athttps://www.rfc-editor.org/info/rfc9629.¶

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

This document updates "Cryptographic Message Syntax (CMS)"[RFC5652].¶

The CMS enveloped-data content type[RFC5652] and the CMS authenticated-enveloped-data content type[RFC5083] support both key transport and key agreement algorithms toestablish the key used to encrypt and decrypt the content. In recentyears, cryptographers have been specifying Key Encapsulation Mechanism(KEM) algorithms, including quantum-secure KEM algorithms. This documentdefines conventions for the use of KEM algorithms for the CMSenveloped-data content type and the CMS authenticated-enveloped-datacontent type.¶

A KEM algorithm is a one-pass (store-and-forward) mechanism fortransporting random keying material to a recipient using the recipient'spublic key. This means that the originator and the recipients do not needto be online at the same time. The recipient's private key is needed torecover the random keying material, which is then treated as a pairwiseshared secret (ss) between the originator and recipient.¶

The KEMRecipientInfo structure defined in this document uses the pairwiseshared secret as an input to a key derivation function (KDF) to produce apairwise key-encryption key (KEK). Then, the pairwise KEK is used to encrypt acontent-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 algorithmmust be secure against adaptive chosen ciphertext attacks. Second, thekey-encryption algorithm must provide confidentiality and integrity protection. Third,the choices of the KDF and the key-encryption algorithm need to provide the samelevel 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 bepassed to the recipient and shared secret (ss) for the originator.¶

Decapsulate(sk, ct) -> ss:

Given the private key (sk) and the ciphertext (ct), produce theshared secret (ss) for the recipient.¶

To support a particular KEM algorithm, the CMS originatorMUST implementthe KEM Encapsulate() function.¶

To support a particular KEM algorithm, the CMS recipientMUST implement the KEMKeyGen() function and the KEM Decapsulate() function. The recipient's public keyis usually carried in a certificate[RFC5280].¶

2.KEM Processing Overview

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

The originator randomly generates the CEK (or the CAEK), and thenall recipients obtain that key as an encrypted object within the KEMRecipientInfoencryptedKey field explained inSection 3. All recipients usethe originator-generated symmetric key to decrypt the CMS message.¶

A KEM algorithm and a key derivation function are used to securelyestablish a pairwise symmetric KEK, which is used to encryptthe 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[RFC5280] that includes the newlygenerated public key. Whether the public key is certified or not, the newlygenerated 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 inSection 6.2.5 of [RFC5652],recipient information foradditional key management techniques is represented in theOtherRecipientInfo type. Each key management technique is identified by a uniqueASN.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 versionMUST be 0. TheCMSVersion type is described inSection 10.2.5 of [RFC5652].¶

rid specifies the recipient's certificate or key that was used bythe originator with the KEM Encapsulate() function. TheRecipientIdentifier provides two alternatives for specifying therecipient's certificate[RFC5280], and thereby the recipient's publickey. The recipient's certificateMUST contain a KEM public key. Therefore,a recipient X.509 version 3 certificate that contains a key usageextensionMUST assert the keyEncipherment bit. The issuerAndSerialNumberalternative identifies the recipient's certificate by the issuer'sdistinguished name and the certificate serial number; thesubjectKeyIdentifier alternative identifies the recipient's certificate by a keyidentifier. When an X.509 certificate is referenced, the key identifiermatches the X.509 subjectKeyIdentifier extension value. When othercertificate formats are referenced, the documents that specify the certificateformat and their use with the CMS must include details on matchingthe key identifier to the appropriate certificate field. For recipientprocessing, implementationsMUST support both of these alternatives forspecifying the recipient's certificate. For originator processing,implementationsMUST support at least one of these alternatives.¶

kem identifies the KEM algorithm, and any associated parameters, usedby the originator. The KEMAlgorithmIdentifier is described inSection 4.¶

kemct is the ciphertext produced by the KEM Encapsulate() function forthis recipient.¶

kdf identifies the key derivation function, and any associated parameters,used by the originator to generate the KEK. TheKeyDerivationAlgorithmIdentifier is described inSection 10.1.6 of [RFC5652].¶

kekLength is the size of the KEK in octets. This value is oneof the inputs to the key derivation function. The upper bound on the integervalue is provided to make it clear to implementers that support for verylarge integer values is not needed. ImplementationsMUST confirm thatthe value provided is consistent with the key-encryption algorithmidentified 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 inSection 5 toprovide a context input to the key derivation function. For example, theukm value could include a nonce, application-specific context information,or an identifier for the originator. A KEM algorithm may placerequirements on the ukm value. Implementations that do not support theukm fieldSHOULD gracefully discontinue processing when the ukm field ispresent. Note that this requirement expands the original purpose of theukm described inSection 10.2.6 of [RFC5652]; it is not limited to beingused with key agreement algorithms.¶

wrap identifies a key-encryption algorithm used to encrypt theCEK. The KeyEncryptionAlgorithmIdentifieris described inSection 10.1.3 of [RFC5652].¶

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

4.KEM Algorithm Identifier

The KEMAlgorithmIdentifier type identifies a KEM algorithm used toestablish a pairwise ss. The details of establishment depend onthe KEM algorithm used. A key derivation function is used to transformthe pairwise ss value into a KEK.¶

  KEMAlgorithmIdentifier ::= AlgorithmIdentifier{ KEM-ALGORITHM, {...} }

5.Key Derivation

This section describes the conventions of using the KDF to compute theKEK for KEMRecipientInfo. For simplicity, theterminology used in the HKDF specification[RFC5869] is used here.¶

Many KDFs internally employ a one-way hash function. When this isthe case, the hash function that is used is indirectly indicated bythe KeyDerivationAlgorithmIdentifier. Other KDFs internally employ anencryption algorithm. When this is the case, the encryption that isused is indirectly indicated by the KeyDerivationAlgorithmIdentifier.¶

The KDF inputs are as follows:¶

IKM is the input keying material. It is a symmetric secret input tothe KDF. The KDF may use a hash function or an encryption algorithmto generate a pseudorandom key. The algorithm used to derive theIKM is dependent on the algorithm identified in theKeyDerivationAlgorithmIdentifier.¶

L is the length of the output keying material in octets. L isidentified in the kekLength of the KEMRecipientInfo. Thevalue is dependent on the key-encryption algorithm used;the key-encryption algorithm is identified in the KeyEncryptionAlgorithmIdentifier.¶

info is contextual input to the KDF. The DER-encodedCMSORIforKEMOtherInfo structure is created from elements of theKEMRecipientInfo structure. CMSORIforKEMOtherInfo is defined as:¶

      CMSORIforKEMOtherInfo ::= SEQUENCE {        wrap KeyEncryptionAlgorithmIdentifier,        kekLength INTEGER (1..65535),        ukm [0] EXPLICIT UserKeyingMaterial OPTIONAL }

The CMSORIforKEMOtherInfo structure contains the following:¶

wrap identifies a key-encryption algorithm; the output of thekey derivation function will be used as a key for this algorithm.¶

kekLength is the length of the KEK in octets; theoutput of the key derivation function will be exactly this size.¶

ukm is optional user keying material; seeSection 3.¶

The KDF output is as follows:¶

OKM is the output keying material with the exact length of L octets.The OKM is the KEK that is used to encrypt the CEK or the CAEK.¶

An acceptable KDFMUST accept an IKM, L, and info as inputs. An acceptableKDFMAY also accept a salt input value, which is carried as a parameter tothe KeyDerivationAlgorithmIdentifier if present. All of theseinputsMUST influence the output of the KDF.¶

6.ASN.1 Modules

This section provides two ASN.1 modules[X.680]. The first ASN.1module is an extension to the AlgorithmInformation-2009 module discussed in[RFC5912]; it defines the KEM-ALGORITHM CLASS. The secondASN.1 module defines the structures needed to use KEM algorithmswith CMS[RFC5652].¶

The first ASN.1 module uses EXPLICIT tagging, and the secondASN.1 module uses IMPLICIT tagging.¶

Both ASN.1 modules follow the conventions established in[RFC5911],[RFC5912], and[RFC6268].¶

<CODE BEGINS>  KEMAlgorithmInformation-2023    { iso(1) identified-organization(3) dod(6) internet(1)      security(5) mechanisms(5) pkix(7) id-mod(0)          id-mod-kemAlgorithmInformation-2023(109) }  DEFINITIONS EXPLICIT TAGS ::=  BEGIN  -- EXPORTS ALL;  IMPORTS    ParamOptions, PUBLIC-KEY, SMIME-CAPS    FROM AlgorithmInformation-2009      { iso(1) identified-organization(3) dod(6) internet(1)        security(5) mechanisms(5) pkix(7) id-mod(0)        id-mod-algorithmInformation-02(58) } ;  -- KEM-ALGORITHM  --  -- Describes the basic properties of a KEM algorithm  --  -- Suggested prefix for KEM algorithm objects is: kema-  --  --  &id - contains the OID identifying the KEM algorithm  --  &Value - if present, contains a type definition for the kemct;  --               if absent, implies that no ASN.1 encoding is  --               performed on the kemct value  --  &Params - if present, contains the type for the algorithm  --               parameters; if absent, implies no parameters  --  &paramPresence - parameter presence requirement  --  &PublicKeySet - specifies which public keys are used with  --               this algorithm  --  &Ukm - if absent, type for user keying material  --  &ukmPresence - specifies the requirements to define the UKM  --               field  --  &smimeCaps - contains the object describing how the S/MIME  --               capabilities are presented.  --  -- Example:  -- kema-kem-rsa KEM-ALGORITHM ::= {  --    IDENTIFIER id-kem-rsa  --    PARAMS TYPE RsaKemParameters ARE optional  --    PUBLIC-KEYS { pk-rsa | pk-rsa-kem }  --    UKM ARE optional  --    SMIME-CAPS { TYPE GenericHybridParameters  --        IDENTIFIED BY id-rsa-kem }  -- }  KEM-ALGORITHM ::= CLASS {    &id             OBJECT IDENTIFIER UNIQUE,    &Value          OPTIONAL,    &Params         OPTIONAL,    &paramPresence  ParamOptions DEFAULT absent,    &PublicKeySet   PUBLIC-KEY OPTIONAL,    &Ukm            OPTIONAL,    &ukmPresence    ParamOptions DEFAULT absent,    &smimeCaps      SMIME-CAPS OPTIONAL  } WITH SYNTAX {    IDENTIFIER &id    [VALUE &Value]    [PARAMS [TYPE &Params] ARE &paramPresence]    [PUBLIC-KEYS &PublicKeySet]    [UKM [TYPE &Ukm] ARE &ukmPresence]    [SMIME-CAPS &smimeCaps]  }  END<CODE ENDS>

<CODE BEGINS>  CMS-KEMRecipientInfo-2023    { iso(1) member-body(2) us(840) rsadsi(113549)      pkcs(1) pkcs-9(9) smime(16) modules(0)      id-mod-cms-kemri-2023(77) }  DEFINITIONS IMPLICIT TAGS ::=  BEGIN  -- EXPORTS ALL;  IMPORTS    OTHER-RECIPIENT, CMSVersion, RecipientIdentifier,    EncryptedKey, KeyDerivationAlgorithmIdentifier,    KeyEncryptionAlgorithmIdentifier, UserKeyingMaterial      FROM CryptographicMessageSyntax-2010  -- RFC 6268        { iso(1) member-body(2) us(840) rsadsi(113549)          pkcs(1) pkcs-9(9) smime(16) modules(0)          id-mod-cms-2009(58) }    KEM-ALGORITHM      FROM KEMAlgorithmInformation-2023  -- RFC 9629        { iso(1) identified-organization(3) dod(6) internet(1)          security(5) mechanisms(5) pkix(7) id-mod(0)          id-mod-kemAlgorithmInformation-2023(109) }    AlgorithmIdentifier{}      FROM AlgorithmInformation-2009  -- RFC 5912        { iso(1) identified-organization(3) dod(6) internet(1)          security(5) mechanisms(5) pkix(7) id-mod(0)          id-mod-algorithmInformation-02(58) } ;  --  -- OtherRecipientInfo Types (ori-)  --  SupportedOtherRecipInfo OTHER-RECIPIENT ::= { ori-KEM, ... }  ori-KEM OTHER-RECIPIENT ::= {    KEMRecipientInfo IDENTIFIED BY id-ori-kem }  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 }  --  -- KEMRecipientInfo  --  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 }  KEMAlgSet KEM-ALGORITHM ::= { ... }  KEMAlgorithmIdentifier ::=    AlgorithmIdentifier{ KEM-ALGORITHM, {KEMAlgSet} }  --  -- CMSORIforKEMOtherInfo  --  CMSORIforKEMOtherInfo ::= SEQUENCE {    wrap KeyEncryptionAlgorithmIdentifier,    kekLength INTEGER (1..65535),    ukm [0] EXPLICIT UserKeyingMaterial OPTIONAL }  END<CODE ENDS>

7.Security Considerations

The security considerations discussed in[RFC5652] are applicable to this document.¶

To be appropriate for use with this specification, the KEM algorithmMUSTexplicitly be designed to be secure when the public key is used manytimes. For example, a KEM algorithm with a single-use public key is notappropriate, because the public key is expected to be carried in along-lived certificate[RFC5280] and used over and over. Thus, KEMalgorithms that offer indistinguishability under adaptive chosen ciphertextattack (IND-CCA2) security are appropriate. A common design pattern forobtaining IND-CCA2 security with public key reuse is to apply theFujisaki-Okamoto (FO) transform[FO] or a variant of the FOtransform[HHK].¶

The KDFSHOULD offer at least the security level of the KEM.¶

The choice of the key-encryption algorithm and the size of theKEKSHOULD be made based on the security levelprovided by the KEM. The key-encryption algorithm and theKEKSHOULD offer at least the security level ofthe KEM.¶

KEM algorithms do not provide data origin authentication; therefore, whena KEM algorithm is used with the authenticated-data content type, thecontents are delivered with integrity from an unknown source.¶

ImplementationsMUST protect the KEM private key, the KEK, and the CEK (or theCAEK). Compromise of the KEM private key mayresult in the disclosure of all contents protected with that KEM private key.However, compromise of the KEK, the CEK, or the CAEK may result in disclosureof the encrypted content of a single message.¶

The KEM produces the IKM input value for the KDF. This IKM valueMUST NOTbe reused for any other purpose. Likewise, any random value used bythe KEM algorithm to produce the shared secret or its encapsulationMUST NOTbe reused for any other purpose. That is, the originatorMUST generate afresh KEM shared secret for each recipient in the KEMRecipientInfostructure, including any random value used by the KEM algorithm to producethe KEM shared secret. In addition, the originatorMUST discard the KEM sharedsecret, including any random value used by the KEM algorithm to producethe KEM shared secret, after constructing the entry in the KEMRecipientInfostructure for the corresponding recipient. Similarly, the recipientMUSTdiscard the KEM shared secret, including any random value used by the KEMalgorithm to produce the KEM shared secret, after constructing theKEK from the KEMRecipientInfo structure.¶

ImplementationsMUST randomly generate content-encryption keys,content-authenticated-encryption keys, and message-authentication keys.Also, the generation of KEM key pairs relies on random numbers. The useof inadequate pseudorandom number generators (PRNGs) to generate thesekeys can result in little or no security. An attacker may find it mucheasier to reproduce the PRNG environment that produced the keys,searching the resulting small set of possibilities, rather than brute-force searching the whole key space. The generation of quality randomnumbers is difficult.[RFC4086] offers important guidance in this area.¶

If the cipher and key sizes used for the key-encryption algorithm and thecontent-encryption algorithm are different, the effective security isdetermined by the weaker of the two algorithms. If, for example, thecontent is encrypted with AES-CBC using a 128-bit CEK and the CEK iswrapped with AES-KEYWRAP using a 256-bit KEK, then at most 128 bits ofprotection is provided.¶

If the cipher and key sizes used for the key-encryption algorithm and thecontent-authenticated-encryption algorithm are different, the effectivesecurity is determined by the weaker of the two algorithms. If, for example,the content is encrypted with AES-GCM using a 128-bitCAEK and the CAEK is wrapped with AES-KEYWRAP using a 192-bit KEK, then atmost 128 bits of protection is provided.¶

If the cipher and key sizes used for the key-encryption algorithm and themessage-authentication algorithm are different, the effective security isdetermined by the weaker of the two algorithms. If, for example, thecontent is authenticated with HMAC-SHA256 using a 512-bitmessage-authentication key and the message-authentication key is wrappedwith AES-KEYWRAP using a 256-bit KEK, then at most 256 bits ofprotection is provided.¶

Implementers should be aware that cryptographic algorithms, including KEMalgorithms, become weaker with time. As new cryptoanalysis techniques aredeveloped and computing capabilities advance, the work factor to break aparticular cryptographic algorithm will be reduced. As a result,cryptographic algorithm implementations should be modular, allowing newalgorithms to be readily inserted. That is, implementers should be preparedfor the set of supported algorithms to change over time.¶

8.IANA Considerations

For KEMRecipientInfo as defined inSection 3, IANA has assigned the following OID in the "SMI Security for S/MIME Other Recipient Info Identifiers (1.2.840.113549.1.9.16.13)" registry:¶

For the ASN.1 module defined inSection 6.1, IANA has assigned the following OID in the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0):¶

For the ASN.1 module defined inSection 6.2, IANA has assigned the following OID in the "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry:¶

Acknowledgements

Our thanks toBurt Kaliski for his guidance and design review.¶

Our thanks toCarl Wallace for his careful review of the ASN.1 modules.¶

Our thanks toHendrik Brockhaus,Jonathan Hammell,Mike Jenkins,David von Oheimb,Francois Rousseau, andLinda Dunbarfor their careful reviews and thoughtful comments.¶

Authors' Addresses