Use of the RSA-KEM Algorithm in the Cryptographic Message Syntax (CMS)
obsoletes
- rfc-5990 — Use of the RSA-KEM Key Transport Algorithm in the Cryptographic Message Syntax (CMS)
Extracted elements (28)
RSA-KEM is architecturally convenient because public-key operations are separate from symmetric operations on keying material, and the length of keying material is determined by the symmetric algorithms rather than the RSA modulus size.
RSA-KEM provides higher security assurance than PKCS #1 v1.5 because its input is a structureless random integer (avoiding adversarial exploitation of structure) and the input is independent of the keying material (so the RSA decryption result is not directly available to an adversary), yielding a tight security proof in the random oracle model.
This document replaces the RFC 5990 KeyTransRecipientInfo approach with KEMRecipientInfo (RFC 9629), sending the ciphertext in the kemct field and the wrapped key in the encryptedKey field separately, rather than concatenating them as EK = (C || WK). The id-rsa-kem-spki alias for id-rsa-kem is introduced to avoid visual confusion and maintain backward compatibility.
A recipient may identify their RSA public key using either rsaEncryption (PKCS #1 v1.5 OID) or id-rsa-kem-spki; when rsaEncryption is used, willingness to accept RSA-KEM is not indicated by the OID and MAY instead be signaled via the SMIMECapabilities attribute or certificate extension.
For backward compatibility, implementations MAY also support the RSA-KEM Key Transport algorithm (id-rsa-kem-spki with KeyTransRecipientInfo) as specified in RFC 5990. The same RSA key pair may be used with both the RFC 5990 key transport algorithm and this specification, because the RSA public/private key operations are identical in both.
The KDF used for CMS KEMRecipientInfo processing (to derive the KEK from the shared secret) MAY be different from the KDF used within the RSA-KEM algorithm itself (to derive the shared secret from the random integer z).
A CMS implementation supporting RSA-KEM MUST support KDF3 (ANS X9.44) with SHA-256 as the key derivation function, and MUST support AES-Wrap-128 (RFC 3394) as the key-encryption algorithm. Other KDFs and key-encryption algorithms MAY be supported.
A CMS originator supporting RSA-KEM MUST implement Encapsulate(); a CMS recipient MUST implement Decapsulate().
An RSA key pair used for RSA-KEM SHOULD NOT also be used for digital signatures, and SHOULD NOT be used with other key establishment schemes, data encryption, or more than one set of underlying algorithm components.
If the keyUsage extension is present in a certificate conveying an RSA public key with id-rsa-kem-spki, the extension MUST contain only keyEncipherment; all other keyUsage values MUST NOT be present.
Implementations MUST NOT use the integer z directly for any purpose; z MUST be passed through the KDF before use, and z, Z, and other intermediate results MUST be securely deleted when no longer needed.
Implementations MUST protect the RSA private key, the key-encryption key, the content-encryption key, message-authentication key, and content-authenticated-encryption key; disclosure of any of these keys leads to compromise of corresponding content.
SHA-1 MUST NOT be used with KDF3, despite its presence in the ASN.1 module for RFC 5990 compatibility; SHA-1 is considered obsolete.
The KEMRecipientInfo version field MUST be 0, and the kem field MUST contain id-kem-rsa when RSA-KEM is employed.
The random integer z MUST be generated independently at random for each Encapsulate() invocation, whether for the same or different recipients.
The recipient MUST check that the received ciphertext byte string is the expected length (nLen) and that the resulting integer c is in the range [0, n-1] prior to attempting RSA decryption.
When id-rsa-kem-spki appears in SubjectPublicKeyInfo, the AlgorithmIdentifier parameters SHOULD be absent; with absent parameters, KDF3 with SHA-256 is used by default. When parameters are present, GenericHybridParameters MUST be used with id-kem-rsa and RsaKemParameters.
GenericHybridParameters is an ASN.1 SEQUENCE with two fields: kem (a KeyEncapsulationMechanism AlgorithmIdentifier with algorithm id-kem-rsa and RsaKemParameters) and dem (a DataEncapsulationMechanism AlgorithmIdentifier identifying the key-encryption algorithm). When present, these constrain the kdf, kekLength, and wrap fields of KEMRecipientInfo.
RSA-KEM is a one-pass KEM algorithm providing three functions: KeyGen() generates an RSA key pair; Encapsulate(pk) generates a random integer z, encrypts it as ct = z^e mod n, and derives a shared secret SS = KDF(Z, ssLen); Decapsulate(sk, ct) decrypts to recover z and derives the same shared secret.
RsaKemParameters is an ASN.1 SEQUENCE containing keyDerivationFunction (an AlgorithmIdentifier) and keyLength (a positive INTEGER giving the key-encryption key length in octets). It appears within the kem field of GenericHybridParameters.
The KEMRecipientInfo structure (RFC 9629) is used to convey RSA-KEM parameters. Its fields include: version (0), rid (recipient identifier), kem (id-kem-rsa), kemct (ciphertext C), kdf (key derivation function), kekLength (key-encryption key size in octets), ukm (optional random input), wrap (key-encryption algorithm), and encryptedKey (wrapped keying material).
Two object identifiers are defined: id-kem-rsa (OID 1.0.18033.2.2.4, from ISO/IEC 18033-2) identifies the RSA-KEM algorithm in KEMRecipientInfo; id-rsa-kem-spki (alias for id-rsa-kem, OID 1.2.840.113549.1.9.16.3.14) identifies the algorithm in SubjectPublicKeyInfo and SMIMECapabilities for backward compatibility with RFC 5990.
IANA assigned OID 1.2.840.113549.1.9.16.0.79 (id-mod-cms-rsa-kem-2023) in the 'SMI Security for S/MIME Module Identifier' registry for the ASN.1 module defined in this document. IANA also updated the id-alg-rsa-kem entry (value 14) in the 'SMI Security for S/MIME Algorithms' registry to note it is also referred to as id-rsa-kem-spki.
Combined use of an RSA key pair for both RSA-KEM and digital signatures is NOT RECOMMENDED; ASC X9 requires separation between key pairs used for key establishment and digital signatures, and such separation may be essential to maintain provable security.
Implementations SHOULD NOT reveal information about intermediate values (z, Z) or calculations (exponentiation, integer conversion, KDF) via timing or other side channels; observable behavior SHOULD be the same for all ciphertexts in range.
RSA key size and underlying components must be selected consistent with the desired security level. For 128-bit security, the RSA key should be at least 3072 bits, the KDF should use SHA-256, and the symmetric key-encryption should use AES Key Wrap with a 128-bit key (per NIST SP 800-57).
The security of RSA-KEM can be shown tightly related to either solving the RSA problem or breaking the symmetric key-encryption algorithm, assuming the KDF is modeled as a random oracle and the symmetric algorithm satisfies the properties of a data encapsulation mechanism.
The security of RSA-KEM depends on a quality random number generator for generating the random integer z; a poorly implemented or maliciously chosen z is partially mitigated by passing it through the KDF, but good randomness remains essential.