Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type
RFC 6033

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>
Subject: Protocol Action: 'Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type' to Proposed Standard

The IESG has approved the following document:

- 'Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key 
   Package Content Type '
   <draft-turner-encryptedkeypackagecontenttype-algs-02.txt> as a Proposed Standard

This document has been reviewed in the IETF but is not the product of an
IETF Working Group. 

The IESG contact person is Tim Polk.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-turner-encryptedkeypackagecontenttype-algs-02.txt

Technical Summary

This document specifies algorithms to secure the encrypted key content
type defined in draft-turner-encryptedkeypackagecontenttype.  The
algorithm choices and key sizes are based on RFC 5751, with
the exception of content encryption algorithm and key wrap algorithm
being AES Key Wrap with Padding.  This rationale for the choice is in
the security considerations.

This document is headed for standards track, but there are normative
references to two informative RFCs.  RFC3394 if for AES Key Wrap and
RFC5649 and is for AES Key Wrap with Padding.  Both are in the downref
registry.

Working Group Summary

This document is not the product of an IETF Working Group.

Document Quality

The document is short and lists the algorithms to be used based on the
encapsulation mechanism.

Personnel

Carl Wallace is the document Shepherd.  Tim Polk is the
responsible Security Area AD.

RFC Editor Note

(1) In Section 2, please make the following substitution:

OLD:

   Regardless of the key management technique choice, implementations
   MUST support AES-128 Key Wrap with Padding [RFC5649].  Implementations
   SHOULD support AES-256 Key Wrap with Padding [RFC5649].

NEW:

   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.  Regardless of the key management
technique
   choice, implementations MUST support AES-128 Key Wrap with Padding
   [RFC5649] as the content encryption algorithm.  Implementations SHOULD
   support AES-256 Key Wrap with Padding [RFC5649] as the
content-encryption
   algorithm.

(2) In Section 3, please make the following substitution:

OLD

   EncryptedData [RFC5652] requires that keys be managed by other means;

   therefore, the only algorithm specified is the content encryption 
   algorithm. Implementations MUST support AES-128 Key Wrap with Padding 
   [RFC5649].  Implementations SHOULD support AES-256 Key Wrap with 
   Padding [RFC5649]. 

NEW

   EncryptedData [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].


(3) In the current section 5 (Public Key Sizes), please make the following
substitution
OLD
   If an implementation supports RSA, RSAES-OAEP, or DH,
   then it MUST support key lengths from 1024-bit to 2048-bit,
   inclusive. 
NEW
   If an implementation supports RSA, RSAES-OAEP, DH, RSASSA-PSS, 
   or DSA, then it MUST support key lengths from 1024-bit to 
   2048-bit, inclusive.  

(4) In the current section 6, Security Considerations, please make the
following
substitution:

OLD
   The security considerations from [RFC3370], [RFC3560], [RFC5083],
   [RFC5084], [RFC5649], [RFC5652], and [RFCTBD] apply.
NEW
   The security considerations from [RFC3370], [RFC3560], [RFC4056],
    [RFC5083], [RFC5084], [RFC5649], [RFC5652], [RFC5754], and [RFCTBD]
apply.

(5) Insert a new section 5 as follows

5. Signed Data

   Implementations of SignedData [RFC5652] MUST support the signature
   scheme RSA [RFC3370][RFC5754] and SHOULD support the signature schemes
   RSASSA-PSS [RFC4056] and 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) Please renumber the current sections 5 through 8 as sections 6
through 9.

(7) Please add the following normative references.

[RFC4056] Schaad, J., "Use of RSASSA-PSS Signature Algorithm in
Cryptographic Message Syntax (CMS)", RFC 4056, June 2005.

[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic Message
Syntax", RFC 5754, January 2010.