Gen-ART LC review of draft-ietf-smime-cms-rsa-kem-05

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

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.)

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf