Document: draft-ietf-smime-cms-rsa-kem-05
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.

Comments:

--Substantive:

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.

--Nits:

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 RSAPublicKey type:"

Redundant "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.

Appendix A:

The appendix uses the term "byte" in multiple locations where "octet"  
might be less ambiguous. (Assuming that "byte" was not preferred on
purpose.)