ietf
[Top] [All Lists]

Requesting community feedback on late update to draft-turner-encryptedkeypackagecontenttype-algs

2010-06-18 11:20:48
Folks,

I would like to inform the community about a late update to
draft-turner-encryptedkeypackagecontenttype-algs.  The document has been
through IETF Last Call and evaluated by the IESG, but an error of omission
was recently identified; addressing this error would necessitate several
changes. 

The current text is available at
  
http://tools.ietf.org/html/draft-turner-encryptedkeypackagecontenttype-algs-
02


The author received comments after IETF LC closed that the specification
should address SignedData for alignment with section 2 of
draft-turner-encryptedkeypackagecontenttype.  Upon review, the algorithm
types for signed data were inadvertently omitted from
draft-turner-encryptedkeypackagecontenttype-algs. Resolving this comment
requires inserting a new brief section and an additional change to the text
on public key sizes to explicitly list the RSA, RSASSA-PSS, and DSA
signature algorithms.  The late update is being handled in the form of an
RFC Editor note (see below).

The critical changes are incorporated in the RFC Editor Note as changes (3),
(4), and (5).  Changes (6) and (7) are also introduced as a consequence of
changes (3), (4), and (5).  Changes (1) and (2) were existing notes from the
original approval process.

[The entire Note is included for completeness.]

--- RFC Editor Note ---

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.

--- end of RFC Editor Note ---

I have asked the RFC Editor to suspend processing of this document until
further notice.

I would like to confirm that the community is comfortable with these
changes.  If no comments are received by June 24, I will ask the RFC Editor
to proceed with publication using the new RFC Editor Note.

Thanks,

Tim Polk


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>
  • Requesting community feedback on late update to draft-turner-encryptedkeypackagecontenttype-algs, Polk, William T. <=