A set-key attribute for symmetric-key packages
draft-herzog-setkey-07

[Ballot discuss]
I have small issue I would like to discuss before recommending approval of this document:


2.  The set-key attribute

  As above, this structure may be expanded at a later date with
  additional types.  Implementations SHOULD gracefully handle values
  and types which they do not recognize.

How can the SHOULD be satisfied in an interoperable way? By ignoring them?

How is extensibility going to work in a general case? Handling of a union versa handling of an intersection are going to produce quite different results.

[Ballot discuss]
I have small issue I would like to discuss before recommending approval of this document:


2.  The set-key attribute

  As above, this structure may be expanded at a later date with
  additional types.  Implementations SHOULD gracefully handle values
  and types which they do not recognize.

How can the SHOULD be satisfied in an interoperable way? By ignoring them?

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:  (A set-key attribute for symmetric-key packages) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'A set-key attribute for symmetric-key packages'
  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-22. 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-setkey/

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

> -------------
> (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 both the
> KEYPROV and SMIME WGs for review and comment.  It was discussed on the
> SMIME WG list.  Comments were received from Jim Shaad. Off-list comments
> were received from Russ Housley and Sean Turner.
>
> (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?
>
> Yes.
>
> The Document Shepard notes that the nit-checker finds one error,
> which the Document Shepard believes to be itself an error:
>
> Downref: Normative reference to an Not Issued RFC: RFC 6031
>
>
>
> (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?
>
> This draft uses two OIDs: one for the ASN.1 module and one for the
> set-key attribute.  These OIDs will be registered in the SMIME Arc,
> which is administered by Russ Housley.  The OIDs are not yet registered,
> but will be after IETF LC.  The Shepherd considers it better to wait for
> assignment until the last possible moment.  The ASN.1 modules will
> compile with dummy numbers (i.e., 999) for both the module and attribute.
>
> Note that the IANA considerations are similar to those in the recently
> published RFCs: 5958, 5940, 5753.
>
> (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?
>
> The Shepherd has verified that the ASN.1 syntax does compile.  Note that
> dummy OIDs are needed for the two "XX" values.
>
> (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
>
> A set-key is a symmetric key (or set of keys) associated with an
> immutable set of participants.  This document defines a set-key
> attribute for use in the CMS-based symmetric-key package structure
> defined in in RFC 6031.
>
>    Working Group Summary
>
> As noted earlier, this draft is not the product of a WG, , but it was
> forwarded to both the KEYPROV and SMIME WGs for review and comment.  It
> was discussed on the SMIME WG list.  Comments were received from Jim
> Shaad. Off-list comments were received from Russ Housley and Sean Turner.
>
> The comments concerned the methodology of organizing the sets.
>
>    Document Quality
>
> There are no known implementations of this document.
>
> Personnel
>
> Jonathan Herzog  is the document Shepherd.
> Tim Polk  is the responsible Area Director.
>