S/MIME Capabilities for Public Key Definitions
draft-ietf-pkix-pubkey-caps-07

[Ballot comment]
  Please reword the last sentence of the Abstract.  It says:
  >
  > An example of where this is used is with the OCSP Agility draft.
  >
  Can this be worded in a way that points to an RFC?  If not, can it be
  worded in a way that does not use "draft"?

  Section 2.1 says:
  >
  >      RSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 7680 | 15360 |
  >                            4096 | 8192, ...)
  >
  The integer values appear in a surprising order.  While this will not
  impact code or interoperability, why not put them in ascending order?

  Should the capabilities in section 3.1 provide an optional way to
  specify sizes of P, Q, and G that are supported?

  Similarly, should the capabilities in section 3.2 provide an optional
  way to specify sizes of P and G that are supported?

  In Section 4.1 and 4.2 and 4.3, I suggest a list of named curves
  instead of the very rich structure that is currently specified.
  Several other documents have taken this approach.  Any popular curve
  can be assigned an object identifier to name it.

  In addition to my comments above, please consider the comments from
  the Gen-ART Review by Mary Barnes on 23-Apr-2012.  The review can be
  found here:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07383.html

[Ballot comment]
I am balloting No Objection on the assumption that the Security ADs
are on top of this work.

I do have a few nits I noticed along the way.

---

Abstract

s/define/defined/

---

Please expand acronyms not marked with an asterisk in
http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt

---

Section 1

OLD
  but we did not currently have any way of
  doing so at the current time.
NEW
  but we did not have any way of doing so.
END

---

Section 1

s/structure need/structure needs/

[Ballot comment]
- I thought S/MIME capabilities were to allow a sender to
know what a receiver wanted/could handle, this says it the
other way around.

- 1 s/need to be/needs to be/ in last para before 1.1

[Ballot comment]
Substantive suggestions; please adopt or respond to these:

-- Introduction --

   Given that we are assigning different data types to the algorithm
   descriptors here, and many of the algorithm descriptors are the same
   as are used in signature, key transport or key agreement algorithms,
   the public key versions of these structures MUST NOT be placed in the
   same locations as the other versions.  It is expected that the places
   where one needs S/MIME capabilities for public keys is going to be
   vastly different than for the other values.

I suggest avoiding 2119 language in the Introduction, as that's a place where people don't tend to expect such normative statements.  If that's the only place that MUST NOT exists, it might be missed.  And I find the latter sentence confusing.  "places... is going to be different" ?  The grammatical failure there makes me think that you're not saying what you mean to say.  Please rephrase.

-- Section 1.1 --

   This is because
   I am a strong advocate of moving to the current versions of ASN.1

This is almost a total nit, but I'm going to call it "substantive": this document is the product of a WG, not an individual, and "I am a strong advocate" isn't appropriate.  If moving to the current versions is WG consensus, that's what it should say.  If not, then it doesn't matter whether or not the editor is an advocate.

-- Section 2.1 --

   The only reason for using one of more specific public
   key identifiers is if the user wants to restrict the usage of the RSA
   public key with a specific algorithm.

Should that be "TO" a specific algorithm?  Otherwise it looks like it means "when using a specific algorithm."  Also in 4.1.

-- Section 6 --
[Update: the -05 version addresses my comments for this section.]

========
Editorial suggestions.  No need to respond to these; take them, leave them, or modify them as you please:

-- Section 2.2 and 2.3 --

   have not been included in this location s as the same information

Spurious "s" in there?  Or does "location s" mean something specific?  The RFC Editor will fix this, so if it needs to be there, there needs to be a notation.

-- Section 3 --

   There is current two Diffie-Hellman public key object identifiers.

"are currently"

-- Section 4.1 --

   This object associated the existing object identifier

"associates".

-- Section 4.2 --

      This object associated the
      existing object identifier (id-??) used for the public key

"associates".  And what's that "??" ?

-- Section 4.3 --

Same comment as for 4.2.

-- Section 5 --

   When the S/MIME group defined a S/MIME Capability for the RSA-SSA-PSS
   signature algorithm, it was done so in the context of how S/MIME
   defines and uses S/MIME Capabilities.

Spurious "so".

   This meant that one can place

"could place"

-- Section 6 --

   There are number of considerations that need
   to be taking into account when doing this.

"taken"

[Ballot comment]

  Please reword the last sentence of the Abstract.  It says:
  >
  > An example of where this is used is with the OCSP Agility draft.
  >
  Can this be worded in a way that points to an RFC?  If not, can it be
  worded in a way that does not use "draft"?

  Section 2.1 says:
  >
  >      RSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 7680 | 15360 |
  >                            4096 | 8192, ...)
  >
  The integer values appear in a surprising order.  While this will not
  impact code or interoperability, why not put them in ascending order?

  Should the capabilities in section 3.1 provide an optional way to
  specify sizes of P, Q, and G that are supported?

  Similarly, should the capabilities in section 3.2 provide an optional
  way to specify sizes of P and G that are supported?

  In Section 4.1 and 4.2 and 4.3, I suggest a list of named curves
  instead of the very rich structure that is currently specified.
  Several other documents have taken this approach.  Any popular curve
  can be assigned an object identifier to name it.

  In addition to my comments above, please consider the comments from
  the Gen-ART Review by Mary Barnes on 23-Apr-2012.  The review can be
  found here:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07383.html

[Ballot comment]
Substantive suggestions; please adopt or respond to these:

-- Introduction --

   Given that we are assigning different data types to the algorithm
   descriptors here, and many of the algorithm descriptors are the same
   as are used in signature, key transport or key agreement algorithms,
   the public key versions of these structures MUST NOT be placed in the
   same locations as the other versions.  It is expected that the places
   where one needs S/MIME capabilities for public keys is going to be
   vastly different than for the other values.

I suggest avoiding 2119 language in the Introduction, as that's a place where people don't tend to expect such normative statements.  And I find the latter sentence confusing.  "places... is going to be different" ?  The grammatical failure there makes me think that you're not saying what you mean to say.  Please rephrase.

-- Section 1.1 --

   This is because
   I am a strong advocate of moving to the current versions of ASN.1

This is almost a total nit, but I'm going to call it "substantive": this document is the product of a WG, not an individual, and "I am a strong advocate" isn't appropriate.  If moving to the current versions is WG consensus, that's what it should say.  If not, then it doesn't matter whether or not the editor is an advocate.

-- Section 2.1 --

   The only reason for using one of more specific public
   key identifiers is if the user wants to restrict the usage of the RSA
   public key with a specific algorithm.

Should that be "TO" a specific algorithm?  Otherwise it looks like it means "when using a specific algorithm."  Also in 4.1.

-- Section 6 --

   This means that when an S/MIME capabilities
   sequence is defined care needs to be taken to specify the types of
   algorithms and/or public keys that are to be specified in that
   sequence.

Are you trying to say that one needs to be careful not to specify an algorithm when a public key is meant, and vice versa?  If so, please re-word to say that.  If not, please try re-wording in some other way to make it clear.

   The more detailed the information that is communicated, the better
   the end results are going to be.

About this paragraph: what you're saying implies that being able to specify combinations is important: not just "I support RSA and I support SHA-256," but specifically "I support RSA *with* SHA-256."  Is there a way to do this?  What's the concrete advice to implementors here?

   The more information passed the better.
   ...
   The less information passed the better.

This is cute, but when I saw this I expected a paragraph that reconciled these two.  There isn't one.  Again: what's the advice to implementors that comes out of these two paragraphs?

========
Editorial suggestions.  No need to respond to these; take them, leave them, or modify them as you please:

-- Section 2.2 and 2.3 --

   have not been included in this location s as the same information

Spurious "s" in there?  Or does "location s" mean something specific?  The RFC Editor will fix this, so if it needs to be there, there needs to be a notation.

-- Section 3 --

   There is current two Diffie-Hellman public key object identifiers.

"are currently"

-- Section 4.1 --

   This object associated the existing object identifier

"associates".

-- Section 4.2 --

      This object associated the
      existing object identifier (id-??) used for the public key

"associates".  And what's that "??" ?

-- Section 4.3 --

Same comment as for 4.2.

-- Section 5 --

   When the S/MIME group defined a S/MIME Capability for the RSA-SSA-PSS
   signature algorithm, it was done so in the context of how S/MIME
   defines and uses S/MIME Capabilities.

Spurious "so".

   This meant that one can place

"could place"

-- Section 6 --

   There are number of considerations that need
   to be taking into account when doing this.

"taken"

IESG:

IANA has reviewed draft-ietf-pkix-pubkey-caps-04.txt, which is
currently in Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no
IANA Actions that need completion.

State changed to In Last Call from Last Call Requested

The following Last Call Announcement was sent out:

From: The IESG

To: IETF-Announce

CC:

Reply-To: ietf@ietf.org

Subject: Last Call:  (S/MIME Capabilities for Public Key Definitions) to Informational RFC





The IESG has received a request from the Public-Key Infrastructure

(X.509) WG (pkix) to consider the following document:

- 'S/MIME Capabilities for Public Key Definitions'

  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 2012-04-20. 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.



Abstract





  This document defines a set of S/MIME Capability types for ASN.1

  encoding for the current set of public keys define in the PKIX

  working group.  This facilitates the ability for a requester to

  specify information on the public keys and signature algorithms to be

  used in responses.  An example of where this is used is with the OCSP

  Agility draft.









The file can be obtained via

http://datatracker.ietf.org/doc/draft-ietf-pkix-pubkey-caps/



IESG discussion can be tracked via

http://datatracker.ietf.org/doc/draft-ietf-pkix-pubkey-caps/ballot/





No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why
is this the proper type of RFC? Is this type of RFC indicated in the
title page header?

The requested track is Informational. This status is indicated on
the title page. Documents that describe the ASN.1 encoding formation
from the PKIX working group have traditionally been tracked as
Informational so this document is consistent with that precedent.

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

Technical Summary

This document defines a set of S/MIME Capability types for ASN.1
encoding for the current set of public key algorithms identified in
the PKIX working group. This enables a requester to specify
information on the public keys and signature algorithms to be used
in responses. An example of where this is used is the OCSP Agility
draft.

Working Group Summary

There were no significant issues about the document that were raised
during the WG process, as such the changes represent the consensus of
the active participants on the document

Document Quality

No known implementations of the work currently exist. The author
does not know if there has been any active work in getting the
algorithm agility work for OCSP rolled out.

Personnel

Document Shepherd: Stephen Kent
Responsible Area Director: Sean Turner

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document has been reviewed by the WG and the author as responded to all
issues raised on the list. The document has been reviewed for nits.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

The document has been reviewed by a small number of interested parties.
However it is believed that these people have done a sufficient job in
reviewing the document.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

There is no need for focused, external reviews for this document.

(6) Describe any specific concerns or issues that the Document Shepherd
has 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 WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

The document still has some TBD values in the ASN.1 modules. The
intent of the author is to request these code points be assigned at
the time that IETF last call comments are addressed. The code points
are to be assigned by Russ Housley from the PKIX OID arc.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

The author as confirmed that all known IPR issues have been filed.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosures exist on the document.

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

This document represents a strong consensus of a small number of
individuals. However there was no dissension.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No dissent on the document has been registered.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

None.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

The document has been reviewed for ASN.1 compliance and has been checked
using the OSS syntax checker using dummy values. These dummy values will
be replaced before publication.

(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) 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 plan for their completion?

No.

(15) Are there downward normative references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

This document does not affect any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of
the document. Confirm that all protocol extensions that the document
makes are associated with the appropriate reservations in IANA
registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries
include a detailed specification of the initial contents for the
registry, that allocations procedures for future registrations are
defined, and a reasonable name for the new registry has been
suggested (see RFC 5226).

The document has no IANA implications. The code points to be assigned are
to be done from the PKIX OID arc.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

The ASN.1 has been validated by running it through the OSS syntax checker
and the A2C ASN.1 compiler. The same checks will be run again when the code
points are assigned during the post IETF Last call update.