Algorithms for Asymmetric Key Package Content Type
updated by
- rfc-6162 — Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Asymmetric Key Package Content Type
Extracted elements (17)
AES Key Wrap with Padding was chosen as the content encryption algorithm because it is specifically designed for encrypting one cryptographic key with another, enabling segregation of cryptographic keying material from other data — a property desirable in high-assurance modules. AES-GCM and AES-CCM do not provide the same segregation properties.
PKCS #5 and PKCS #12 differ primarily in their password encoding: PKCS #5 uses ASCII encoding while PKCS #12 uses Unicode encoding as specified in Section B.1 of PKCS #12. RFC 2898 recommends PBES2 for new specifications over PBES1.
The document uses algorithms defined in existing RFCs (RFC 3370, RFC 3560, RFC 4056, RFC 4231, RFC 5083, RFC 5084, RFC 5649, RFC 5652, RFC 5754) and defines no new algorithms, ensuring backward compatibility with existing CMS implementations.
For EnvelopedData, regardless of key management technique, AES-128 Key Wrap with Padding MUST be supported as the content encryption algorithm, and AES-256 Key Wrap with Padding SHOULD be supported.
If an implementation supports AuthenticatedData, it MUST implement SHA-256 and HMAC with SHA-256. SHA-1 and HMAC with SHA-1 SHOULD be supported.
If an implementation supports AuthEnvelopedData, it MUST follow the EnvelopedData requirements except 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 EncryptedData, it MUST implement AES-128 Key Wrap with Padding and SHOULD implement AES-256 Key Wrap with Padding as the content encryption algorithm.
If an implementation supports EnvelopedData, it MUST implement key transport. When key transport is used, RSA encryption MUST be supported and RSAES-OAEP SHOULD be supported. When key agreement is used, DH ephemeral-static MUST be supported.
If an implementation supports RSA, RSASSA-PSS, DSS, RSAES-OAEP, or DH, it MUST support key lengths from 1024-bit to 2048-bit, inclusive.
If an implementation supports SignedData, it MUST support RSA as a signature scheme and SHOULD support RSASSA-PSS and DSA. SHA-256 MUST be supported and SHA-1 SHOULD be supported as hash functions.
Implementations of AsymmetricKeyPackage do not require support for any CMS protecting content type; however, if the AsymmetricKeyPackage is CMS protected, it is RECOMMENDED that the conventions defined in this document be followed.
PBES2 with PBKDF2 using HMAC with SHA-256 as the key derivation algorithm and AES-128 Key Wrap with Padding as the encryption algorithm MUST be supported for the EncryptedPrivateKeyInfo structure. AES-256 Key Wrap with Padding MAY also be supported.
When key agreement is used in EnvelopedData, the key wrap algorithm MUST match the content encryption algorithm: AES-128 Key Wrap with Padding wraps AES-128, and AES-256 Key Wrap with Padding wraps AES-256.
SMIMECapabilities attribute values for AES Key Wrap with Padding as content encryption: AES-128 KW with Padding is 30 0d 06 09 60 86 48 01 65 03 04 01 08; AES-192 is ...1C; AES-256 is ...30. These DER-encoded OID sequences enable recipients to advertise support.
The EncryptedPrivateKeyInfo structure (defined in RFC 5958) is used to encrypt PrivateKeyInfo. It has no recipients, no originators, and no content encryption keys, and requires keys to be managed by other means — similar to CMS EncryptedData.
Security considerations from RFC 3370, RFC 3560, RFC 4056, RFC 4231, RFC 5083, RFC 5084, RFC 5649, RFC 5652, RFC 5754, and RFC 5958 all apply. NIST SP800-57 provides comparable bits of security for various algorithms and key sizes, and defines time frames during which certain security levels are appropriate.
The security strength of a PBES is bounded by the password's entropy. A 20-character user-chosen password from a 94-character keyboard provides only ~36 bits of entropy; a randomly chosen 20-character password provides ~131 bits. NIST SP800-63 provides further guidance on password entropy.