Use of the RSA-KEM Key Transport Algorithm in the Cryptographic Message Syntax (CMS)
obsoleted by
- rfc-9690 — Use of the RSA-KEM Algorithm in the Cryptographic Message Syntax (CMS)
Extracted elements (28)
RSA-KEM encrypts a random integer with the recipient's public key rather than the keying data itself, then derives a key-encrypting key via a KDF and wraps the keying data symmetrically. This provides a 'tight' security proof in the random oracle model because the RSA input has no exploitable structure and is independent of the keying data, unlike PKCS #1 v1.5.
The architecture separates public-key operations from symmetric operations on the keying data, and the length of the keying data is bounded only by the symmetric key-wrapping scheme rather than the RSA modulus size. This is architecturally convenient and avoids the length constraints of direct RSA encryption.
A recipient MAY identify an RSA public key using the rsaEncryption OID (same as PKCS #1 v1.5), in which case willingness to use RSA-KEM is not implied; it may be signaled separately via SMIMECapabilities. Only by using id-rsa-kem in the certificate does the recipient restrict the key to RSA-KEM use.
ANS X9.44 originally specified id-ac-generic-hybrid to identify the RSA-KEM Key Transport Algorithm, whereas this document uses id-rsa-kem. These OIDs are not interchangeable. Legacy implementations wishing to interoperate with ANS X9.44 should consult that specification for details on id-ac-generic-hybrid.
A CMS implementation supporting RSA-KEM MUST support at least KDF3 (based on SHA-256) as the key derivation function and AES-Wrap-128 as the symmetric key-wrapping scheme.
An implementation SHOULD also support KDF2 based on SHA-1. The Camellia key wrap SHOULD be supported if Camellia is supported as a content-encryption cipher. Triple-DES Key Wrap SHOULD be supported if Triple-DES is supported as a content-encryption cipher.
For SHA algorithm identifiers (SHA-1, SHA-224, SHA-256, SHA-384, SHA-512), implementations SHOULD generate algorithm identifiers without parameters and MUST accept algorithm identifiers either without parameters or with NULL parameters.
If a recipient wishes to restrict a public key to RSA-KEM use only, the certificate MUST identify the public key using id-rsa-kem. When id-rsa-kem appears in SubjectPublicKeyInfo.algorithm, the parameters field SHALL be omitted, making the AlgorithmIdentifier a SEQUENCE of one component.
If the keyUsage extension is present in a certificate conveying an RSA public key with the id-rsa-kem OID, the extension MUST contain the keyEncipherment value. dataEncipherment SHOULD NOT be present.
The keyDerivationFunction in RsaKemParameters MUST be KDF2 or KDF3 for alignment with ANS X9.44, though other KDFs MAY be used with CMS. The dem field MUST be an X9-approved symmetric key-wrapping scheme for ANS X9.44 alignment, though other wrapping schemes MAY be used with CMS.
The length of the keying data to be transported MUST be among the lengths supported by the underlying symmetric key-wrapping scheme (e.g., AES and Camellia Key Wraps require a multiple of 8 bytes, at least 16 bytes; Triple-DES requires 64-bit block size).
The random integer z MUST be generated independently at random for different encryption operations, whether for the same or different recipients. Reuse of z across encryption operations would undermine the security of the scheme.
The SMIMECapability SEQUENCE representing RSA-KEM MUST include the id-rsa-kem OID in the capabilityID field and MUST include a GenericHybridParameters value in the parameters field identifying the components to be employed.
When RSA-KEM is employed for a recipient, the RecipientInfo alternative MUST be KeyTransRecipientInfo, with keyEncryptionAlgorithm.algorithm MUST be id-rsa-kem, keyEncryptionAlgorithm.parameters MUST be a GenericHybridParameters value, and encryptedKey MUST be the encrypted keying data output by the algorithm.
GenericHybridParameters is a SEQUENCE containing two fields: 'kem' (KeyEncapsulationMechanism, identifying the RSA-KEM mechanism via id-kem-rsa) and 'dem' (DataEncapsulationMechanism, identifying the symmetric key-wrapping scheme). This structure appears in AlgorithmIdentifier parameters for id-rsa-kem.
RsaKemParameters is a SEQUENCE containing 'keyDerivationFunction' (an AlgorithmIdentifier for the KDF, MUST be KDF2 or KDF3 for ANS X9.44 alignment) and 'keyLength' (an INTEGER 1..MAX specifying the KEK length in bytes). These parameters appear as the associated parameters for id-kem-rsa.
The RSA-KEM Key Transport Algorithm is identified by the OID id-rsa-kem (1.2.840.113549.1.9.16.3.14), assigned in this document. When used in an AlgorithmIdentifier, parameters MUST use the GenericHybridParameters syntax; parameters MUST be absent in the SubjectPublicKeyInfo field.
The RSAPublicKey type used for encoding the RSA public key is a SEQUENCE of modulus (INTEGER n) and publicExponent (INTEGER e), DER-encoded and carried in the subjectPublicKey BIT STRING within SubjectPublicKeyInfo. This encoding is used regardless of which AlgorithmIdentifier (rsaEncryption or id-rsa-kem) identifies the key.
The sender's 6-step operation: generate random z in [0, n-1], compute ciphertext C = z^e mod n (nLen bytes), derive KEK = KDF(Z, kekLen), compute WK = Wrap(KEK, K), output EK = C || WK. The recipient's operation reverses this: split EK, decrypt C to recover z, re-derive KEK, unwrap WK to recover K.
This document assigns two new OIDs: id-rsa-kem (1.2.840.113549.1.9.16.3.14) identifying the RSA-KEM Key Transport Algorithm, and the ASN.1 module identifier CMS-RSA-KEM (1.2.840.113549.1.9.16.0.21). Both are assigned in an arc delegated by RSA Data Security Inc. to the S/MIME Working Group.
Combined use of an RSA key pair for multiple schemes (e.g., both key transport and digital signatures) is NOT RECOMMENDED. An RSA key pair used for RSA-KEM SHOULD NOT also be used for digital signatures, other key establishment schemes, data encryption, or with more than one set of underlying algorithm components.
Implementations MUST protect the RSA private key and the content-encryption key. Compromise of the RSA private key may result in disclosure of all messages protected with that key; compromise of the content-encryption key may result in disclosure of the associated encrypted content.
Implementations SHOULD NOT reveal information about intermediate values or calculations (including the integer z, string Z, and RSA exponentiation) via timing or other side channels. The observable behavior SHOULD be identical for all in-range ciphertexts C, and intermediate values MUST be securely deleted when no longer needed.
RSA-KEM should be considered for new CMS applications as a replacement for PKCS #1 v1.5, which is vulnerable to chosen-ciphertext attacks. RSA-KEM has a tighter security proof than RSAES-OAEP, at the cost of slightly longer encrypted keying data.
Security level recommendations: 80-bit security requires RSA key at least 1024 bits and SHA-1 or above; 112-bit security requires at least 2048 bits and SHA-224 or above; 128-bit security requires at least 3072 bits and SHA-256 or above. AES or Camellia Key Wrap may be used at all three levels.
The security of RSA-KEM is tightly related to the difficulty of solving the RSA problem or breaking the symmetric key-wrapping scheme, assuming the KDF is modeled as a random oracle and the wrapping scheme satisfies data encapsulation mechanism properties. The RSA key size and underlying components should be selected consistent with the desired symmetric security level.
The security of the algorithm depends on the strength of the random number generator, which SHOULD have a comparable security level to the overall scheme. A weak RNG can undermine the security guarantee of RSA-KEM even if all other components are strong.
The encrypted keying data EK is the concatenation EK = C || WK, where C is the RSA ciphertext (nLen bytes, big-endian encoding of z^e mod n) and WK is the symmetrically wrapped keying data. The recipient splits EK by taking the first nLen bytes as C and the remainder as WK.