Algorithms for Asymmetric Key Package Content Type
RFC 5959

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 Asymmetric Key Package Content Type' to Proposed Standard

The IESG has approved the following document:

- 'Algorithms for Asymmetric Key Package Content Type '
   <draft-turner-asymmetrickeyformat-algs-01.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-asymmetrickeyformat-algs-01.txt

Technical Summary

This document specifies algorithms to secure the asymmetric key content
type defined in draft-turner-asymmetrickeyformat-03.txt. 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 three informative RFCs. RFC2898 "Password Based
Encryption based on PKCS#5" and RFC5649 "AES Key Wrap with Padding"
wree called out in this Last Call; RFC3394 "AES Key Wrap" was added
to the downref registry earlier in 2010.

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) Section 1

OLD:

  keys be managed

NEW:

  keys to be managed

2) Replace the text in Section 2 as follows:

OLD

   The de facto standard used to encrypt the PrivateKeyInfo structure, 
   which is subsequently placed in the EncryptedPrivateKeyInfo 
   encryptedData field, is Password Based Encryption (PBE) based on 
   PKCS#5 [RFC2898] and PKCS#12 [P12]. The major difference between PKCS 
   #5 and PKCS #12 is the supported encoding for the password: ASCII for 
   PKCS #5 and Unicode for PKCS #12.  [RFC2898] specifies two PBE 
   Schemes (PBES) 1 and 2, the defacto is PBES 1.  The notation for the 
   PBES 1 is: PBEWith<digest>And<encryption>.  The following schemes are 
   defined in PKCS #5: PBEWithMD2AndDES-CBC, PBEWithMD2AndRC2, 
   PBEWithMD5AndDES-CBC, PBEWithMD5AndRC2, PBEWithSHA1AndDES-CBC, 
   PBEWithSHA1AndRC2.  The following schemes are defined in PKCS #12: 
   PBEWithSHAAnd3-KeyTripleDES-CBC, PBEWithSHAAnd2-KeyTripleDES-CBC, 
   PBEWithSHAAnd128BitRC2-CBC, PBEWithSHAAnd40BitRC2-CBC, 
   PBEWithSHAAnd128BitRC4, and PBEWithSHAAnd40BitRC4.  Implementation 
   defaults vary. 

   The PBES 1 algorithms require salt and iteration count values. The 
   salt length in PKCS #5 is 8 octets while there is no restriction on 
   the length of the salt in PKCS #12, but PKCS #12 recommends the salt 
   be as long as the digest algorithms output (e.g., 20 octets for SHA-
   1).  The iteration count in PKCS #5 is recommended to be at least 
   1000 and PKCS #12 recommends at least 1024. 

   It is RECOMMENDED that implementations support AES-128 Key Wrap with 
   Padding [RFC5649] or AES-256 Key Wrap with Padding [RFC5649].


NEW
                                      
   The de facto standard used to encrypt the PrivateKeyInfo structure, 
   which is subsequently placed in the EncryptedPrivateKeyInfo 
   encryptedData field, is Password Based Encryption (PBE) based on 
   PKCS#5 [RFC2898] and PKCS#12 [P12].  The major difference between PKCS
   #5 and PKCS #12 is the supported encoding for the password: ASCII for
   PKCS #5 and Unicode for PKCS #12, encoded as specified in Section
   B.1 of [P12].  [RFC2898] specifies two PBE Schemes (PBES) 1 and 2;
   [RFC2898] recommends PBESS 2 for new specification.  PBES2 with a key
   derivation algorithm of PBKDF2 using HMAC with SHA-256 [RFC5754] and
   an encryption algorithm of DES-EDE2-CBC-Pad as defined in [RFC2898]
   MUST be supported.

   It is RECOMMENDED that implementations support AES-128 Key Wrap with
   Padding [RFC5649] or AES-256 Key Wrap with Padding [RFC5649] as an
   encryption algorithm.

3) Section 3.2

OLD:

  If an implementation supports EnvelopedData, then it MUST implement
  the key transport and it MAY implement the key agreement mechanism.

NEW:

  If an implementation supports EnvelopedData, then it MUST implement
  key transport and it MAY implement key agreement.

4) Section 6

OLD:

  The security considerations from [RFC3370], [RFC3394], [RFC3560],
  [RFC5652], [RFC4056], [RFC4231], [RFC5083], [RFC5084], [RFC5649],
  [RFC5754], and [RFCTBD1] apply.

NEW:

  The security considerations from [RFC3370], [RFC3560], [RFC4056],
  [RFC4231], [RFC5083], [RFC5084], [RFC5649], [RFC5652], [RFC5754],
   and [RFCTBD1] apply.

5) Section 6

OLD:

  Unfortunately, there is no AES-CCM or AES-GCM mode that provides the
  same properties.  If an AES-CCM and AES-GCM mode that provides the same
  properties is defined, then this document will be updated to adopt that
  algorithm.

NEW:

  Unfortunately, there is no AES-GCM or AES-CCM mode that provides the
  same properties.  If an AES-GCM and AES-CCM mode that provides the same
  properties is defined, then this document will be updated to adopt that
  algorithm.

6) Section 8.1

  Delete reference to [RFC3394].