I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
Please resolve these comments along with any other Last Call comments
you may receive.
Reviewer: Ben Campbell
Review Date: 2008-06-30
IETF LC End Date: 2008-07-04
IESG Telechat date: (if known)
Summary: This draft is almost ready for publication as a proposed
standard. I have one substantive comment which should be considered
prior to publication, and a few nits.
This draft normatively references RFC 3280, which was obsoleted by RFC
5280 after this draft was published. The authors should consider
whether it would be appropriate to update the reference prior to
publication. I have no opinion on how invasive such an update might
be, so I am categorizing this as substantive, although it could really
just be a nit.
The draft appears to be expired, Also, the short title still claims
to be version 04.
Section 2, paragraph 2:
I'm not sure what to make of the SHOULD consider statement along
with the last sentence. Do you intend any statement of preference for
one or the other, or effectively saying we should consider both?
Section 2.1, paragraph 5:
The last sentence is hard to follow due to the chained "whiles". Can
it be rephrased?
Section 2.2, first paragraph:
Odd line spacing. This occurs a few times throughout the document.
Section 2.3, right before definition of RSAPublicKey, "... type
Section 3, paragraph 1:
It might be helpful to add a short paragraph explaining the
significance of this algorithm mapping to a random oracle in lay terms
(or at least in terms where a person generally familiar with IETF
protocols but not cryptology jargon would understand.)
Paragraph 10 (starting with "Implementations SHOULD NOT reveal...")
Are there any documents that could be referenced here to elaborate on
this guidance to implementors? Right now, this draft says enough to
let implementors know they need to worry about side channels, but does
not provide much concrete advice on how to avoid them. To be clear, I
don't think this document _should_ provide such guidance itself; if no
such documents exist in a form that could be referenced, then so be it.
The appendix uses the term "byte" in multiple locations where "octet"
might be less ambiguous. (Assuming that "byte" was not preferred on
Ietf mailing list