[secdir] re-review of draft-ietf-smime-cms-rsa-kem

Stephen Kent <kent@bbn.com> Tue, 15 December 2009 18:36 UTC

Return-Path: <kent@bbn.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08B233A68C1 for <secdir@core3.amsl.com>; Tue, 15 Dec 2009 10:36:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.607
X-Spam-Level:
X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 RFDhjRYqIFgf for <secdir@core3.amsl.com>; Tue, 15 Dec 2009 10:36:52 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 28F903A6AA0 for <secdir@ietf.org>; Tue, 15 Dec 2009 10:36:52 -0800 (PST)
Received: from [192.1.255.196] by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from <kent@bbn.com>) id 1NKcGD-0005ie-C9; Tue, 15 Dec 2009 13:36:37 -0500
Mime-Version: 1.0
Message-Id: <p06240813c74c66966a10@[10.84.130.238]>
Date: Tue, 15 Dec 2009 13:36:35 -0500
To: secdir@ietf.org
From: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Subject: [secdir] re-review of draft-ietf-smime-cms-rsa-kem
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Dec 2009 18:36:53 -0000

I reviewed version 05 of this I-D in July of 2008.  The current version is 10.

My original reviewed cited only a two major concerns:

	- the previous version was ambiguous about support for 
Camella. This version clarifies this issue, making support for 
Camellia a SHOULD.

	- the pervious version called for using an algorithm ID (with 
very complex parameters) in a cert to signal when a message recipient 
requires use of RSA-KEM. The authors addressed this concern in 
Section 2.3 (and Appendix B), by stating that these parameters MUST 
be absent when this OID is used in a cert in this context.

I have corresponded with Sean and he suggested that he could provide 
more explicit words re the fact that the parameters MUST be omitted 
when the algorithm OID appears in the SubjectPublicKey field of a 
cert. I encourage Sean to include this additional text.

Steve