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

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/

[Update: the -05 version addresses all my substantive comments.]

  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

- 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