Skip to main content

Algorithms for Cryptographic Message Syntax (CMS) Protection of Symmetric Key Package Content Types
draft-turner-cms-symmetrickeypackage-algs-00

Revision differences

Document history

Date Rev. By Action
2012-08-22
00 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2011-03-01
(System) Posted related IPR disclosure: Certicom Corp's Statement about IPR related to draft-turner-cms-symmetrickeypackage-algs
2011-02-18
00 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent.
2011-02-15
00 (System) IANA Action state changed to No IC from In Progress
2011-02-15
00 (System) IANA Action state changed to In Progress
2011-02-15
00 Amy Vezza IESG state changed to Approved-announcement sent
2011-02-15
00 Amy Vezza IESG has approved the document
2011-02-15
00 Amy Vezza Closed "Approve" ballot
2011-02-15
00 Amy Vezza Ballot writeup text changed
2011-02-15
00 Tim Polk Ballot writeup text changed
2011-02-14
00 Tim Polk Ballot writeup text changed
2011-02-07
00 Amy Vezza Approval announcement text regenerated
2011-02-03
00 Cindy Morgan Removed from agenda for telechat
2011-02-03
00 Cindy Morgan State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation.
2011-02-03
00 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded
2011-02-03
00 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded
2011-02-03
00 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded
2011-02-03
00 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded
2011-02-03
00 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded
2011-02-02
00 Tim Polk Ballot writeup text changed
2011-02-02
00 Adrian Farrel
[Ballot comment]
Section 3

  Regardless of the key management technique choice, implementations
  MUST support AES-128 Key Wrap with Padding [RFC5649] as …
[Ballot comment]
Section 3

  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.

Is it sufficiently clear from context that this "MUST" applies only
to the case on an implementation that supports EnvelopedData?
2011-02-02
00 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded
2011-02-02
00 Russ Housley
[Ballot comment]
In section 3 please replace:

  When key agreement is used, a key wrap algorithm is also specified to wrap the content encryption …
[Ballot comment]
In section 3 please replace:

  When key agreement is used, a key wrap algorithm is also specified to wrap the content encryption key.

with:

  When key agreement is used, the same key wrap algorithm MUST be used for both key and content encryption.
 
Global changes:
  s/key encryption key/key-encryption key/
  s/key encryption algorithm/key-encryption algorithm/
  s/content encryption key/content-encryption key/
  s/content encryption algorithm/content-encryption algorithm/
2011-02-02
00 Russ Housley
[Ballot discuss]
In Section 3, the document says:

  When key agreement is used, a key wrap algorithm is also specified to
  wrap the …
[Ballot discuss]
In Section 3, the document says:

  When key agreement is used, a key wrap algorithm is also specified to
  wrap the content encryption key.  If the content encryption algorithm
  is AES-128 Key Wrap with Padding, then the key wrap algorithm MUST be
  AES-128 Key Wrap with Padding [RFC5649].  If the content encryption
  algorithm is AES-256 Key Wrap with Padding, then the key wrap
  algorithm MUST be AES-256 Key Wrap with Padding [RFC5649].

  Key agreement produces a key-encryption key, which is in turn used to
  wrap a content-encryption key.  Shouldn't this specify the use of AES
  Key Wrap with Padding and the same size key is to be used for both of
  these keys?
2011-02-02
00 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss
2011-02-02
00 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded
2011-02-01
00 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Sam Hartman.
2011-02-01
00 Russ Housley [Ballot comment]
Global changes:
  s/key encryption key/key-encryption key/
  s/key encryption algorithm/key-encryption algorithm/
  s/content encryption key/content-encryption key/
  s/content encryption algorithm/content-encryption algorithm/
2011-02-01
00 Russ Housley
[Ballot discuss]
In Section 3, the document says:

  When key agreement is used, a key wrap algorithm is also specified to
  wrap the …
[Ballot discuss]
In Section 3, the document says:

  When key agreement is used, a key wrap algorithm is also specified to
  wrap the content encryption key.  If the content encryption algorithm
  is AES-128 Key Wrap with Padding, then the key wrap algorithm MUST be
  AES-128 Key Wrap with Padding [RFC5649].  If the content encryption
  algorithm is AES-256 Key Wrap with Padding, then the key wrap
  algorithm MUST be AES-256 Key Wrap with Padding [RFC5649].

  Key agreement produces a key-encryption key, which is in turn used to
  wrap a content-encryption key.  Shouldn't this specify the use of AES
  Key Wrap with Padding and the same size key is to be used for both of
  these keys?
2011-02-01
00 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded
2011-02-01
00 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded
2011-02-01
00 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded
2011-01-31
00 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded
2011-01-30
00 Sean Turner [Ballot Position Update] New position, Recuse, has been recorded
2011-01-30
00 Tim Polk [Ballot Position Update] New position, Yes, has been recorded for Tim Polk
2011-01-30
00 Tim Polk Ballot has been issued
2011-01-30
00 Tim Polk Created "Approve" ballot
2011-01-25
00 Tim Polk State changed to IESG Evaluation from Waiting for AD Go-Ahead.
2011-01-25
00 Tim Polk Placed on agenda for telechat - 2011-02-03
2011-01-18
00 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2011-01-11
00 Amanda Baber IANA understands that, upon approval of this document, there are no IANA
Actions that need completion.
2011-01-04
00 Samuel Weiler Request for Last Call review by SECDIR is assigned to Sam Hartman
2011-01-04
00 Samuel Weiler Request for Last Call review by SECDIR is assigned to Sam Hartman
2010-12-21
00 Amy Vezza Last call sent
2010-12-21
00 Amy Vezza
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Algorithms for Cryptographic Message Syntax (CMS) Protection of Symmetric Key Package Content Types) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'Algorithms for Cryptographic Message Syntax (CMS)  Protection of
  Symmetric Key Package Content Types'
  as a Proposed
Standard

Note that this specification includes a normative reference to RFC 5753,
"Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic
Message Syntax (CMS)" which was published as an Informational RFC.
The IESG requests feedback on whether this RFC is sufficiently well
understood to serve as a normative reference.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-01-18. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-turner-cms-symmetrickeypackage-algs/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-turner-cms-symmetrickeypackage-algs/
2010-12-21
00 Tim Polk Last Call was requested
2010-12-21
00 Tim Polk State changed to Last Call Requested from Publication Requested.
2010-12-21
00 Tim Polk Last Call text changed
2010-12-21
00 (System) Ballot writeup text was added
2010-12-21
00 (System) Last call text was added
2010-12-21
00 (System) Ballot approval text was added
2010-12-17
00 Cindy Morgan
(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the document
and, in particular, does he …
(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the document
and, in particular, does he or she believe this version is ready
for forwarding to the IESG for publication?

Sean Turner  is the document Shepherd. He has
reviewed this version of the document and believes that it is ready for
forwarding to the IESG for publication.

(1.b) Has the document had adequate review both from key members of
the interested community and others? Does the Document Shepherd
have any concerns about the depth or breadth of the reviews that
have been performed?

This draft is not the product of a WG, but it was forwarded to both the
KEYPROV WGs for review and comment.

The low level of comments is primarily due to the fact that this draft
is essentially equivalent to RFC 5959 except that a) it's for the
Symmetric Key Package Content Type as Asymmetric Key Package, and b) it
adds the ECDSA and ECDH algorithms as MAYs.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective, e.g.,
security, operational complexity, someone familiar with AAA,
internationalization or XML?

The document shepherd has no such concerns.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or
she is uncomfortable with certain parts of the document, or has
concerns whether there really is a need for it. In any event, if
the interested community has discussed those issues and has
indicated that it still wishes to advance the document, detail
those concerns here.

The only issue is that this document specifies support for the ECDSA and
ECDH algorithms as MAYs. IPR has been submitted on both RFCs to which
this draft points to for those EC algs.

(1.e) How solid is the consensus of the interested community behind
this document? Does it represent the strong concurrence of a few
individuals, with others being silent, or does the interested
community as a whole understand and agree with it?

There is consensus by a small group of individuals.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

There has been no threat of an appeal or any indication of extreme
discontent.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document met
all formal review criteria it needs to, such as the MIB Doctor,
media type and URI type reviews?

The document has verified that the draft satisfies all ID nits.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that are
not ready for advancement or are otherwise in an unclear state?
If such normative references exist, what is the strategy for their
completion? Are there normative references that are downward
references, as described in [RFC3967]? If so, list these downward
references to support the Area Director in the Last Call procedure
for them [RFC3967].

This draft does split its references into normative and informative. All
references are to RFC-level or equivalent standards with the exception
of one reference. That reference is a draft that was recently approved
by the IESG.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body of
the document? If the document specifies protocol extensions, are
reservations requested in appropriate IANA registries? Are the
IANA registries clearly identified? If the document creates a new
registry, does it define the proposed initial contents of the
registry and an allocation procedure for future registrations?
Does it suggested a reasonable name for the new registry? See
[I-D.narten-iana-considerations-rfc2434bis]. If the document
describes an Expert Review process has Shepherd conferred with the
Responsible Area Director so that the IESG can appoint the needed
Expert during the IESG Evaluation?

The Shepherd has verified that the document has an IANA considerations
section and that it is consistent with the document (i.e., None).

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML code,
BNF rules, MIB definitions, etc., validate correctly in an
automated checker?

There is no formal syntax in this document.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Writeup? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

This document describes the conventions for using several cryptographic
algorithms with the Cryptographic Message Syntax (CMS) to protect the
symmetric key package content type (RFC 6031). Specifically, it
includes conventions necessary to implement SignedData, EnvelopedData,
EncryptedData, and AuthEnvelopedData.

Working Group Summary

As noted earlier, this draft is not the product of a WG, but it was
forwarded to both the KEYPROV WG for review and comment. No comments
were received. This can be attributed to the fact that it is almost
identical to RFC 5959. The exceptions are that a) it's for the
Symmetric Key Package Content Type as Asymmetric Key Package, and b) it
adds ECC algs as a MAYs.

Document Quality

There are no known implementations of this document.

Personnel

Sean Turner  is the document Shepherd.
Tim Polk  is the responsible Area Director.
2010-12-17
00 Cindy Morgan Draft added in state Publication Requested
2010-12-17
00 Cindy Morgan [Note]: 'Sean Turner (turners@ieca.com) is the document Shepherd.' added
2010-09-23
00 (System) New version available: draft-turner-cms-symmetrickeypackage-algs-00.txt