Internet Engineering Task Force (IETF) S. Turner Request for Comments: 7192 IECA Category: Standards Track April 2014 ISSN: 2070-1721Algorithms for Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types
Turner Standards Track [Page 1]
RFC 7192 Algs for CMS Key Package Rcpt Content Type April 2014 1. IntroductionThis document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) key package receipt and error content types [RFC7191]. Specifically, it includes conventions necessary to implement SignedData [RFC5652], EnvelopedData [RFC5652], EncryptedData [RFC5652], and AuthEnvelopedData [RFC5083].
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
2. SignedData
If an implementation supports SignedData, then it MUST support the signature scheme RSA [RFC3370] and SHOULD support the signature schemes RSA Probabilistic Signature Scheme (RSASSA-PSS) [RFC4056] and Digital Signature Algorithm (DSA) [RFC3370]. Additionally, implementations MUST support the hash function SHA-256 [RFC5754] in concert with these signature schemes, and they SHOULD support the hash function SHA-1 [RFC3370]. Implementations can also choose the to support Elliptic Curve Digital Signature Algorithm (ECDSA) [RFC5753] and [RFC6090].
Turner Standards Track [Page 2]
RFC 7192 Algs for CMS Key Package Rcpt Content Type April 2014 3. EnvelopedDataIf an implementation supports EnvelopedData, then it MUST implement key transport and it MAY implement key agreement.
4. EncryptedData
If an implementation supports EncryptedData, then it MUST implement AES-128 in CBC mode [AES] and SHOULD implement AES-256 in CBC mode [AES].
5. AuthEnvelopedData
If an implementation supports AuthEnvelopedData, then it MUST implement the EnvelopedData recommendations except for the content- encryption algorithm, which, in this case, MUST be AES-GCM [RFC5084]; the 128-bit version MUST be implemented, and the 256-bit version SHOULD be implemented. Implementations MAY also support AES-CCM [RFC5084].
Turner Standards Track [Page 3]
RFC 7192 Algs for CMS Key Package Rcpt Content Type April 2014 6. Public Key SizesThe easiest way to implement SignedData, EnvelopedData, and AuthEnvelopedData is with public key certificates [RFC5280]. If an implementation supports RSA, RSASSA-PSS, DSA, RSAES-OAEP, or Diffie- Hellman, then it MUST support key lengths from 1024-bit to 2048-bit, inclusive. If an implementation supports ECDSA or ECDH, then it MUST support keys on the P-256 curve [RFC6090].
7. Security Considerations
The security considerations from [RFC3370], [RFC3394], [RFC3560], [RFC4056], [RFC5084], [RFC5652], [RFC5753], and [RFC5754] apply.
8. Acknowledgements
I'd like to thank Russ Housley for his early feedback on this document.9. References 9.1. Normative References[AES] National Institute of Standards and Technology, FIPS Pub
Turner Standards Track [Page 4]
RFC 7192 Algs for CMS Key Package Rcpt Content Type April 2014
[RFC5083] Housley, R., "Cryptographic Message Syntax (CMS)
9. Informative References
[RFC5959] Turner, S., "Algorithms for Asymmetric Key Package Content
Turner Standards Track [Page 5]
RFC 7192 Algs for CMS Key Package Rcpt Content Type April 2014
[RFC6162] Turner, S., "Elliptic Curve Algorithms for Cryptographic