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

[Ben Campbell <ben at estacado.net>]

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, "From ietf-bounces at ietf.org  Mon Jun 30 14:15:31 2008
Return-Path: <ietf-bounces at ietf.org>
X-Original-To: ietf-archive at megatron.ietf.org
Delivered-To: ietfarch-ietf-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 47F953A6ADE;
	Mon, 30 Jun 2008 14:15:31 -0700 (PDT)
X-Original-To: ietf at core3.amsl.com
Delivered-To: ietf at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id BEF0D3A6ADE
	for <ietf at core3.amsl.com>; Mon, 30 Jun 2008 14:15:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id Jes7I36htgLv for <ietf at core3.amsl.com>;
	Mon, 30 Jun 2008 14:15:27 -0700 (PDT)
Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net
	[IPv6:2001:470:1f03:266::2])
	by core3.amsl.com (Postfix) with ESMTP id A55373A6AFD
	for <ietf at ietf.org>; Mon, 30 Jun 2008 14:15:25 -0700 (PDT)
Received: from dn3-213.estacado.net (dn3-213.estacado.net [172.16.3.213])
	(authenticated bits=0)
	by estacado.net (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 ben at estacado.net)
Message-Id: <D1CBD421-237A-4790-9000-98D722CAE10D at estacado.net>
From: Ben Campbell <ben at estacado.net>
To: General Area Review Team <gen-art at ietf.org>
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)
Cc: blake at sendmail.com, ietf at ietf.org, kaliski_burt at emc.com, turners at ieca.com,
	jrandall at rsa.com
X-BeenThere: ietf at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: ietf-bounces at ietf.org
Errors-To: ietf-bounces at ietf.org

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... 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 at ietf.org
https://www.ietf.org/mailman/listinfo/ietf


 
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 at ietf.org
https://www.ietf.org/mailman/listinfo/ietf