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

Ben Campbell <> Mon, 30 June 2008 21:15 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 47F953A6ADE; Mon, 30 Jun 2008 14:15:31 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id BEF0D3A6ADE for <>; Mon, 30 Jun 2008 14:15:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Jes7I36htgLv for <>; Mon, 30 Jun 2008 14:15:27 -0700 (PDT)
Received: from ( [IPv6:2001:470:1f03:266::2]) by (Postfix) with ESMTP id A55373A6AFD for <>; Mon, 30 Jun 2008 14:15:25 -0700 (PDT)
Received: from ( []) (authenticated bits=0) by (8.14.2/8.14.1) with ESMTP id m5ULFXia076524 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 30 Jun 2008 16:15:33 -0500 (CDT) (envelope-from
Message-Id: <>
From: Ben Campbell <>
To: General Area Review Team <>
Mime-Version: 1.0 (Apple Message framework v924)
Subject: Gen-ART LC review of draft-ietf-smime-cms-rsa-kem-05
Date: Mon, 30 Jun 2008 16:15:33 -0500
X-Mailer: Apple Mail (2.924)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"

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.

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.



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

Ietf mailing list