Use of Static-Static Elliptic Curve Diffie-Hellman Key Agreement in Cryptographic Message Syntax
draft-herzog-static-ecdh-06

[Ballot comment]
I have No objection to the publication of this document, but I have a
couple of minor editorial points that could usefully be fixed to
improve the document.

---

The term "MACed" is used without explanation.

---

Section 1

  All three of these types share the same basic structure.  First, a
  fresh symmetric key is generated.

There is a slight syntactic disconnect between these two sentances. Do
you mean the second sentance to be a process description (in which case
a paragraph break would be in order)? Or do you mean to describe the
shared basic structure in some way?

---

Section 1

  o  key transport: the symmetric key is encrypted using the public
      encryption key of some recipient,

To be very picky...
Do you mean "encryption key of the intended recipient"?

And Later...

  In this case, the participants are the originator and
  one of the recipients.

Again "the intended recipient" seems a better phrase.

ButI am somewhat worried that you have said "one of the recipients"
given tat in the case of multiple recipients (that is implied by your
language) I don't see how the other recipients will be able to function
as they will not have access to the necessary key.

---

Section 2

  the RecipientInfo kari choice is used.

Is "kari" an unexplained term or a typo?

---

"ukm" is used without expansion

---

Section 2.1 contains a number of MUST statements. Section 2.3 should
give an indication of what the receiver does when one of these MUSTs
is violated. This may be as simple as a reference to [CMS].

State changed to In Last Call from In Last Call.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Use of static-static Elliptic-Curve Diffie-Hellman key agreement in Cryptographic Message Syntax) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Use of static-static Elliptic-Curve Diffie-Hellman key agreement in
  Cryptographic Message Syntax'
  as an Informational RFC

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-03-02. 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-herzog-static-ecdh/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-herzog-static-ecdh/

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:  (Use of static-static Elliptic-Curve Diffie-Hellman key agreement in Cryptographic Message Syntax
) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Use of static-static Elliptic-Curve Diffie-Hellman key agreement in
  Cryptographic Message Syntax'
  as an Informational RFC

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-02-28. 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-herzog-static-ecdh/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-herzog-static-ecdh/

(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?

Jonathan Herzog  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 and
discussed on the SMIME WG list for review and comment.  Comments were
received from Jim Shaad.

(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 document shepherd has no specific concerns.

(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.  The SMIME WG has
been losing steam over the years, but if something comes along they're
not shy about voicing their displeasure.

(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 shepherd has verified that the draft satisfies all ID nits in the
-04 version.

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

(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 document shepherd has verified that the draft has an IANA
considerations section and that it is consistent with the body of the
message.

(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 language in this draft.

(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 how to use 'static-static' Elliptic Curve
Diffie-Hellman (S-S ECDH) key-agreement with the Cryptographic Message
Syntax (CMS).  In this form of key-agreement, the Diffie-Hellman values
of both sender and receiver are long-term values contained in certificates.

This form of key agreement can be used with three CMS content types:
EnvelopedData, AuthenicatedData, and AuthEnvelopedData.

    Working Group Summary

This is not the product of a WG, but it was discussed on the SMIME WG
mailing list.  This draft documents an option not in RFC 5753 (Use of
Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message
Syntax (CMS)). RFC 5753 specifies the use of ephemeral-static (E-S)
ECDH, but does not specify the use of S-S ECDH.  The SMIME WG did not
specify S-S ECDH because E-S ECDH is more secure (to save you some time:
E-S ECDH provides better security due to the originator's ephemeral
contribution to the key agreement scheme).  This is not to say S-S ECDH
is insecure it's just that E-S ECDH is considered more secure and there
was only a limited amount of energy to work on ECDH based solutions.
Note that draft-herzog-static-ecdh contains a section that compares
itself to RFC 5753.

The discussion on the WG list was light.  Jim Shaad provided reviews
that resulted -01.  -02, -03 and -04 were to address ID-nits.

    Document Quality

There is an implementation of an earlier version of this document.  This
implementation can be updated with little effort to match this version
of the final document.

Personnel

Jonathan Herzog  is the document Shepherd.
Tim Polk is the responsible Area Director.