S/MIME Capabilities for Public Key Definitions
RFC 6664

Note: This ballot was opened for revision 04 and is now closed.

(Sean Turner) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Benoît Claise) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Comment (2012-04-25 for -05)
No email
send info
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.





Please expand acronyms not marked with an asterisk in 


Section 1

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


Section 1

s/structure need/structure needs/

(Stephen Farrell) No Objection

Comment (2012-04-24 for -05)
No email
send info
- 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

(Brian Haberman) No Objection

(Russ Housley) (was Discuss) No Objection

Comment (2012-05-17)
No email
send info
  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:

Barry Leiba No Objection

Comment (2012-04-24 for -05)
No email
send info
[Update: the -05 version addresses all my substantive comments.]

(Pete Resnick) No Objection

(Robert Sparks) No Objection

(Martin Stiemerling) No Objection