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.