Note: This ballot was opened for revision 04 and is now closed.
Summary: Has enough positions to pass.
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
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.
s/structure need/structure needs/
[Update: the -05 version addresses all my substantive comments.]
- 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
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