Internet Engineering Task Force (IETF) S. Turner Request for Comments: 6033 IECA Category: Standards Track December 2010 ISSN: 2070-1721Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type
Turner Standards Track [Page 1]
RFC 6033 Algorithms for CMS Encrypted Key Packages December 2010 1. IntroductionThis document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) encrypted key package content type [RFC6032]. Specifically, it includes conventions necessary to implement the following CMS content types: EnvelopedData [RFC5652], EncryptedData [RFC5652], and AuthEnvelopedData [RFC5083].
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
2. EnvelopedData
EnvelopedData [RFC5652] supports a number of key management techniques. Implementations that claim conformance to this document MUST support the key transport mechanisms and SHOULD support the key agreement mechanisms as defined below. Other techniques MAY be supported.
Turner Standards Track [Page 2]
RFC 6033 Algorithms for CMS Encrypted Key Packages December 2010 3. EncryptedDataEncryptedData [RFC5652] requires that keys be managed by other means; therefore, the only algorithm specified is the content-encryption algorithm. Since the content type is used to carry a cryptographic key and its attributes, an algorithm that is traditionally used to encrypt one key with another is employed. Implementations MUST support AES-128 Key Wrap with Padding [RFC5649]. Implementations SHOULD support AES-256 Key Wrap with Padding [RFC5649].
4. AuthEnvelopedData
AuthEnvelopedData [RFC5083], like EnvelopedData, supports a number of key management techniques. The key management requirements for AuthEnvelopedData are the same as for EnvelopedData. The difference is the content-encryption algorithm. Implementations MUST support 128-bit AES-Galois/Counter Mode (AES-GCM) [RFC5084] and SHOULD support 256-bit AES-GCM [RFC5084]. Implementations MAY also support AES-Counter with CBC-MAC (AES-CCM) [RFC5084].
5. Signed Data
Implementations of SignedData [RFC5652] MUST support the signature scheme RSA [RFC3370] [RFC5754] and SHOULD support the signature schemes RSA Probabilistic Signature Scheme (RSASSA-PSS) [RFC4056] and Digital Signature Algorithm (DSA) [RFC3370] [RFC5754]. Additionally, implementations MUST support in concert with these signature schemes the hash function SHA-256 [RFC5754] and it SHOULD support the hash function SHA-1 [RFC3370].
6. Public Key Sizes
The easiest way to implement SignedData, EnvelopedData, and AuthEnvelopedData is with public key certificates [RFC5280]. If an implementation supports RSA, RSAES-OAEP, DH, RSASSA-PSS, or DSA, then it MUST support key lengths from 1024 bits to 2048 bits, inclusive.
7. Security Considerations
The security considerations from [RFC3370], [RFC3560], [RFC4056], [RFC5083], [RFC5084], [RFC5649], [RFC5652], [RFC5754], and [RFC6032] apply.
Turner Standards Track [Page 3]
RFC 6033 Algorithms for CMS Encrypted Key Packages December 2010
[SP800-57] provides comparable bits of security for some algorithms and key sizes. [SP800-57] also provides time frames during which certain numbers of bits of security are appropriate, and some environments may find these time frames useful.8. References 8.1. Normative References[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Turner Standards Track [Page 4]
RFC 6033 Algorithms for CMS Encrypted Key Packages December 2010
[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic
8.2. Informative References
[SP800-57] National Institute of Standards and Technology (NIST),