Algorithms for Asymmetric Key Package Content Type
draft-turner-asymmetrickeyformat-algs-01

[Ballot discuss]
This is almost nitpicking, but I think it is important to be precise:


2. EncryptedPrivateKeyInfo

  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.

Unicode is not an encoding, it is a set of code points (characters).
If PKCS #12 is using one of the Unicode encodings such as UTF-8,
UTF-16LE, UTF-16BE, UCS-4, etc., please specify which one.

**BEGIN DOWNREF ALERT**

This document is headed for standards track, but there are normative
references to three informative RFCs. RFC2898 is for Password Based
Encryption based on PKCS#5, RFC3394 if for AES Key Wrap, RFC5649 and is
for AES Key Wrap with Padding.

**END DOWNRED ALERT**

PROTO write-up:

1.a - Carl Wallace is the Shepherd. He's personally reviewed the ID
and personally knows it's ready for IESG publication.
1.b - The document has been reviewed by key IETF participants. There are
no concerns about depth or breadth of the reviews.
1.c - There is no need for wider review.
1.d - There are no specific concerns that the AD and/or IESG should be
aware of.
1.e - The consensus is solid.
1.f - There has been no threat of an appeal.
1.g - The Shepherd has personally verified that the document satisfies
all ID nits.
1.h - The document splits it references.
1.i - The document has an IANA consideration and it is consistent with
the main body (there are no IANA considerations).
1.j - The Shepherd has personally compiled the ASN.1 modules. Note that
dummy OID values were used while we await final assignment.

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.

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.