Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS)
updates
- rfc-5652 — Cryptographic Message Syntax (CMS)
Extracted elements (23)
A KEM algorithm is a one-pass (store-and-forward) mechanism: the originator uses the recipient's public key to produce a ciphertext and shared secret via Encapsulate(), while the recipient uses their private key and the ciphertext via Decapsulate(). This means originator and recipient do not need to be online simultaneously, making KEM suitable for CMS enveloped-data.
Cryptographic algorithm implementations should be modular to allow new algorithms to be readily inserted, because KEM algorithms (like all cryptographic algorithms) become weaker over time as cryptanalysis techniques advance and computing capabilities improve.
The KEMRecipientInfo structure uses the pairwise shared secret as input to a KDF to produce a pairwise KEK, which encrypts the CEK or CAEK per recipient. All recipients receive the same CEK or CAEK, but each recipient's copy is individually encrypted under a distinct KEK derived from that recipient's KEM shared secret.
An acceptable KDF MUST accept IKM, L, and info as inputs; it MAY also accept a salt carried as a parameter to KeyDerivationAlgorithmIdentifier. All of these inputs MUST influence the output of the KDF.
Implementations MUST confirm that the kekLength value provided is consistent with the key-encryption algorithm identified in the wrap field.
Implementations MUST protect the KEM private key, the KEK, and the CEK (or CAEK). Compromise of the KEM private key may result in disclosure of all contents protected with that key; compromise of the KEK, CEK, or CAEK affects only a single message.
Implementations MUST randomly generate content-encryption keys, content-authenticated-encryption keys, and message-authentication keys. The generation of KEM key pairs also relies on random numbers; use of inadequate PRNGs can result in little or no security.
Implementations that do not support the ukm field SHOULD gracefully discontinue processing when the ukm field is present in KEMRecipientInfo.
The IKM value produced by the KEM MUST NOT be reused for any other purpose. The originator MUST generate a fresh KEM shared secret for each recipient, and MUST discard it after constructing the KEMRecipientInfo entry for that recipient. Similarly, the recipient MUST discard the KEM shared secret after deriving the KEK.
The recipient's certificate MUST contain a KEM public key. A recipient X.509 version 3 certificate that contains a key usage extension MUST assert the keyEncipherment bit. For recipient processing, implementations MUST support both issuerAndSerialNumber and subjectKeyIdentifier alternatives for specifying the recipient's certificate.
The version field in KEMRecipientInfo MUST be 0.
To support a particular KEM algorithm, the CMS originator MUST implement the KEM Encapsulate() function, and the CMS recipient MUST implement the KEM KeyGen() and KEM Decapsulate() functions.
KEMRecipientInfo is defined as an OtherRecipientInfo type identified by OID id-ori-kem (1.2.840.113549.1.9.16.13.3). It contains: version, rid, kem, kemct, kdf, kekLength, optional ukm, wrap, and encryptedKey fields.
The KEM-ALGORITHM ASN.1 CLASS (defined in the KEMAlgorithmInformation-2023 module, OID id-mod-kemAlgorithmInformation-2023 at 1.3.6.1.5.5.7.0.109) describes KEM algorithm properties including &id, optional &Value (kemct type), &Params, &PublicKeySet, &Ukm, &ukmPresence, and &smimeCaps.
IANA assigned OID decimal 109 (id-mod-kemAlgorithmInformation-2023) in the 'SMI Security for PKIX Module Identifier (1.3.6.1.5.5.7.0)' registry for the KEMAlgorithmInformation-2023 ASN.1 module defined in Section 6.1.
IANA assigned OID decimal 3 (id-ori-kem) in the 'SMI Security for S/MIME Other Recipient Info Identifiers (1.2.840.113549.1.9.16.13)' registry for the KEMRecipientInfo OtherRecipientInfo type defined in Section 3.
IANA assigned OID decimal 77 (id-mod-cms-kemri-2023) in the 'SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)' registry for the CMS-KEMRecipientInfo-2023 ASN.1 module defined in Section 6.2.
KEM algorithms do not provide data origin authentication; therefore, when a KEM algorithm is used with the authenticated-data content type, the contents are delivered with integrity from an unknown source.
The KDF SHOULD offer at least the security level of the KEM. The key-encryption algorithm and the KEK SHOULD also offer at least the security level of the KEM.
The KEM algorithm MUST explicitly be designed to be secure when the public key is used many times, because the public key is expected to be carried in a long-lived certificate and reused. KEM algorithms offering IND-CCA2 security are appropriate; a common pattern for achieving this is the Fujisaki-Okamoto (FO) transform or a variant.
When the key-encryption algorithm and the content-encryption (or authentication) algorithm use different key sizes, the effective security is determined by the weaker of the two. For example, AES-CBC with a 128-bit CEK wrapped under AES-KEYWRAP with a 256-bit KEK provides at most 128 bits of protection.
CMSORIforKEMOtherInfo ::= SEQUENCE { wrap KeyEncryptionAlgorithmIdentifier, kekLength INTEGER (1..65535), ukm [0] EXPLICIT UserKeyingMaterial OPTIONAL }. This DER-encoded structure serves as the 'info' context input to the KDF.
KEMRecipientInfo ::= SEQUENCE { version CMSVersion (always 0), rid RecipientIdentifier, kem KEMAlgorithmIdentifier, kemct OCTET STRING, kdf KeyDerivationAlgorithmIdentifier, kekLength INTEGER (1..65535), ukm [0] EXPLICIT UserKeyingMaterial OPTIONAL, wrap KeyEncryptionAlgorithmIdentifier, encryptedKey EncryptedKey }.