Algorithms for Cryptographic Message Syntax (CMS) Protection of Symmetric Key Package Content Types
Extracted elements (15)
AES-GCM and AES-CCM were not chosen as the primary content-encryption algorithms for symmetric key packages because no mode of AES-GCM or AES-CCM provides the same keying-material segregation properties as AES Key Wrap with Padding. The document notes it will be updated if such a mode is defined.
AES Key Wrap with Padding (RFC5649) was chosen as the content-encryption algorithm because in high assurance cryptographic modules it is desirable to segregate cryptographic keying material from other data, and using a specific mechanism solely for protection of keying material assists this goal.
The document does not define any new algorithms but refers to previously defined algorithms from RFC3370, RFC4056, RFC5083, RFC5084, RFC5649, RFC5652, RFC5753, RFC5754, and RFC6090. Implementations must reference those specifications for encoding details.
If an implementation supports AuthEnvelopedData, it MUST follow EnvelopedData recommendations except that the content-encryption algorithm MUST be AES-GCM; the 128-bit version MUST be implemented and the 256-bit version SHOULD be implemented. AES-CCM MAY also be supported.
If an implementation supports ECDSA or ECDH, it MUST support keys on the P-256 curve.
If an implementation supports EncryptedData, it MUST implement AES-128 Key Wrap with Padding and SHOULD implement AES-256 Key Wrap with Padding. Only the content-encryption algorithm is specified since EncryptedData requires keys be managed by other means.
If an implementation supports EnvelopedData, it MUST implement key transport. RSA encryption MUST be supported for key transport; RSAES-OAEP SHOULD be supported.
If an implementation supports RSA, RSASSA-PSS, DSA, RSAES-OAEP, or Diffie-Hellman, it MUST support key lengths from 1024-bit to 2048-bit, inclusive.
If an implementation supports SignedData, it MAY support ECDSA per RFC6090 and RFC5753.
If an implementation supports SignedData, it MUST support RSA signature scheme and MUST support SHA-256 hash function. It SHOULD also support RSASSA-PSS, DSA, and SHA-1.
Regardless of key management technique, implementations MUST support AES-128 Key Wrap with Padding (RFC5649) as the content-encryption algorithm for EnvelopedData. AES-256 Key Wrap with Padding SHOULD be supported.
When key agreement is used in EnvelopedData, DH ephemeral-static MUST be supported; ECDH MAY be supported.
When key agreement is used, the same key-wrap algorithm MUST be used for both key and content encryption. AES-128 content encryption requires AES-128 key-wrap; AES-256 content encryption requires AES-256 key-wrap.
NIST SP800-57 provides comparable bits of security for algorithms and key sizes and defines time frames during which certain security levels are appropriate; some deployment environments may find these time frames useful for algorithm agility planning.
Security considerations from RFC3370, RFC3560, RFC4056, RFC5083, RFC5084, RFC5649, RFC5652, RFC5753, RFC5754, and RFC6031 all apply to use of these algorithms with symmetric key package content types.