Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type
updated by
- rfc-6161 — Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type
Extracted elements (19)
AES Key Wrap with Padding was chosen as the content-encryption algorithm because it is specifically designed to segregate cryptographic keying material from other data, supporting high-assurance cryptographic module design. AES-GCM and AES-CCM do not provide the same segregation properties, so they are used only in AuthEnvelopedData.
Public key certificates per RFC 5280 are identified as the easiest implementation path for SignedData, EnvelopedData, and AuthEnvelopedData, implying that certificate-based implementations are the expected interoperability baseline.
For AuthEnvelopedData, implementations MUST support 128-bit AES-GCM and SHOULD support 256-bit AES-GCM. Implementations MAY also support AES-CCM.
For EncryptedData, implementations MUST support AES-128 Key Wrap with Padding and SHOULD support AES-256 Key Wrap with Padding as the content-encryption algorithm.
If an implementation supports RSA, RSAES-OAEP, DH, RSASSA-PSS, or DSA, it MUST support key lengths from 1024 bits to 2048 bits, inclusive.
Implementations claiming conformance MUST support key transport mechanisms and SHOULD support key agreement mechanisms for EnvelopedData. Other key management techniques MAY be supported.
Implementations of SignedData MUST support SHA-256 as the hash function in concert with signature schemes, and SHOULD support SHA-1.
Implementations of SignedData MUST support the RSA signature scheme and SHOULD support RSASSA-PSS and DSA signature schemes.
Regardless of the key management technique, implementations MUST support AES-128 Key Wrap with Padding as the content-encryption algorithm for EnvelopedData; implementations SHOULD support AES-256 Key Wrap with Padding.
The key management requirements for AuthEnvelopedData are the same as for EnvelopedData: MUST support key transport (RSA), SHOULD support key agreement (Ephemeral-Static DH).
When key agreement is used, the key wrap algorithm MUST match the content-encryption algorithm: AES-128 Key Wrap with Padding for AES-128 content-encryption, and AES-256 Key Wrap with Padding for AES-256 content-encryption.
When key agreement is used with EnvelopedData, Ephemeral-Static Diffie-Hellman (DH) MUST be supported.
When key transport is used with EnvelopedData, RSA encryption MUST be supported and RSAES-OAEP SHOULD be supported.
AuthEnvelopedData is a CMS content type combining authenticated encryption with the same key management options as EnvelopedData, but using AES-GCM or AES-CCM as the content-encryption algorithm.
EncryptedData is a CMS content type where key management is handled by external means; only the content-encryption algorithm is specified within this document.
EnvelopedData is a CMS content type supporting multiple key management techniques (key transport and key agreement) combined with a content-encryption algorithm to protect cryptographic key packages.
NIST SP 800-57 provides guidance on comparable bits of security for algorithms and key sizes, and defines time frames during which certain security strengths are appropriate; implementers operating in regulated environments may find these time frames relevant.
No AES-GCM or AES-CCM mode exists that provides the same key-material segregation properties as AES Key Wrap with Padding; if such a mode is defined in the future, this document would be updated to adopt it.
The security considerations from the referenced algorithm and CMS RFCs (RFC 3370, RFC 3560, RFC 4056, RFC 5083, RFC 5084, RFC 5649, RFC 5652, RFC 5754, RFC 6032) all apply to implementations of this document.