Asymmetric Key Packages
RFC 5958

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: 'Asymmetric Key Packages' to Proposed Standard

The IESG has approved the following document:

- 'Asymmetric Key Packages '
   <draft-turner-asymmetrickeyformat-05.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-05.txt

Technical Summary

This document defines the syntax for private key information. This
document obsoletes RFC 5208. Changes from RFC 5208 include: defining a
CMS content type, adding public key to structure (v2 if included),
adding local storage considerations.

The document includes downrefs to NEWPKIXASN and NEWSMIMEASN.  These
Informational RFCs have been added to Downref Registry based on Last
Calls eralier in 2010.

Working Group Summary

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

Document Quality

The document is of the same quality as RFC 5208.

Personnel

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

RFC Editor Note

Please make the following 13 changes:

1) Section 2

OLD:

  Earlier versions of this
  specification [RFC5208] did not specify a particular encoding rule
  set, but generators SHOULD use DER [X.690] and receivers SHOULD be
  prepared to handle BER [X.690] and DER [X.690].

NEW:

  Earlier versions of this
  specification [RFC5208] did not specify a particular encoding rule
  set, but generators SHOULD use DER [X.690] and receivers MUST support
  BER [X.690], which also includes DER [X.690].

2) Section 2

OLD:

     Version ::= INTEGER { v1(0), v2(1) } (v1, ..., v2, ... )

NEW:

     Version ::= INTEGER { v1(0), v2(1) } (v1, ..., v2)

3) Section 3

OLD:

  This section gives the syntax for encrypted private-key information,
  which is used with [P12].

NEW:

  This section gives the syntax for encrypted private-key information,
  which is used by [P12].


4) Section 3

OLD:

  Generators SHOULD use DER [X.690] and receivers SHOULD be
  prepared to handle BER [X.690] and DER [X.690]

NEW:


  Generators SHOULD use DER [X.690] and receivers MUST support
  BER [X.690], which also includes and DER [X.690].

5) Section 5

OLD:

  PEM encoding is either the Base64 encoding of the DER encoded
  EncryptedPrivateKeyInfo sandwiched between:

NEW:

  PEM encoding is either the Base64 encoding, from Section 4 of
  [RFC4648], of the DER encoded EncryptedPrivateKeyInfo sandwiched
   between:

6) Section 5

OLD:

  or the Base64 encoding of the DER encoded PrivateKeyInfo sandwiched
  between:

NEW:

  or the Base64 encoding, see Section 4 of [RFC4648], of the DER
  encoded PrivateKeyInfo sandwiched between:

7) Section 7

OLD:

  This specification also defines a new media type that IANA is
  requested to add to the registry at:

NEW:

  This document makes use of object identifiers to identify a CMS content




  type and the ASN.1 module found in Appendix A.  The CMS content type
  OID is registered in a DoD arc.  The ASN.1 module OID is registered in
  an arc delegated by RSADSI to the SMIME Working Group.  No further
action
  by IANA is necessary for this document or any anticipated updates.

  This specification also defines a new media subtype that IANA is
  requested to add to the registry at:

8) Section 7.1

OLD:

7.1. Registration of media type application/pkcs8

      To: ietf-types@iana.org
      Subject: Registration of media type application/pkcs8
      Type name: application

NEW:

  7.1. Registration of media subtype application/pkcs8

       Type name: application

9) Section 7.1

OLD:

    Security considerations: Carries a cryptographic private key.

New:

    Security considerations: Carries a cryptographic private key.
                             See Section 6.

10) Section 7.1

OLD:

      Any MIME-compliant transport

NEW:

      Any MIME-compliant transport that processes asymmetric keys.

11) Section 7.1

OLD:

      The IESG <iesg@ietf.org>

NEW:

      The IESG

12) Appendix A

OLD:

  CONTENT-TYPE
   FROM CryptographicMessageSyntax-2009
     { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
       smime(16) modules(0) cms-2004-02(41) }
  -- From New PKIX ASN.1 [RFCTBD1]
  Attribute{}, ATTRIBUTE
   FROM PKIX-CommonTypes-2009
     { iso(1) identified-organization(3) dod(6) internet(1)
       security(5) mechanisms(5) pkix(7) id-mod(0)
       id-mod-pkixCommon-02(57) }

NEW:

  Attribute{}, CONTENT-TYPE
   FROM CryptographicMessageSyntax-2009
     { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
       smime(16) modules(0) id-mod-cms-2004-02(41) }
  -- From New PKIX ASN.1 [RFCTBD1]
  ATTRIBUTE
   FROM PKIX-CommonTypes-2009
     { iso(1) identified-organization(3) dod(6) internet(1)
       security(5) mechanisms(5) pkix(7) id-mod(0)
       id-mod-pkixCommon-02(57) }


13) Appendix A

OLD:

     Version ::= INTEGER { v1(0), v2(1) } (v1, ..., v2, ... )

NEW:

     Version ::= INTEGER { v1(0), v2(1) } (v1, ..., v2)