Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type
draft-turner-encryptedkeypackagecontenttype-algs-02

[Ballot discuss]
Section 2 needs to specify a content-encryption algorithm.  Based on
  the other choices in this document, the mandatory-to-implement
  content-encryption algorithm ought to be AES-CBC with a 128 bit key.

  Section 3 specifiesd a key-encryption algorithm, when a content-
  encryption algorithm is required.  Based on the other choices in this
  document, the mandatory-to-implement content-encryption algorithm
  ought to be AES-CBC with a 128 bit key.

[Ballot comment]
2. EnvelopedData

  EnvelopedData supports a number of key management techniques. 
  Implementations that claim conformance to this document MUST support
  the key transport mechanisms and SHOULD support the key agreement
  mechanisms.  Other techniques MAY be supported.

[...]

  When key agreement is used, Diffie-Hellman ephemeral-static [RFC3370]
  SHOULD be supported.

It doesn't look like there is a mandatory to implement key agreement protocol. Maybe the last SHOULD needs to be replaced with a MUST.

(Please ignore earlier Proto write-up; that was for a different document.)

**BEGIN DOWNREF ALERT**

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.

**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 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.

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.

**BEGIN DOWNREF ALERT**

This document is headed for standards track, but there are normative
references to two informative IDs and 4 superseded ITU/ISO standards.
All of these references (NEWPKIXASN, NEWSMIMEASN, X.680, X.681, X.682,
X.683) all result from the choice of '02 ASN.1. I chose the '02 ASN.1
because I want to use the latest available ASN.1 that has a freeware
compiler and I'd rather import than redefine ASN.1 structures.

**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 a content type for encrypted key packages. It
is a choice of: EnvelopedData, EncryptedData, or AuthEnvelopedData. The
rationale for it's use is based on the CMS content constraints
documented in draft-housley-cms-content-constraints-extn. This document
also defines an attribute that provides a hint as to which key should be
used to decrypt the content when the EncryptedData choice is used.

Working Group Summary

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

Document Quality

The document is short, but provides enough background to explain why why
the content type is needed.

Personnel

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