Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-08.txt

Julien Stern <julien.stern@cryptolog.com> Thu, 22 October 2009 15:14 UTC

Return-Path: <julien.stern@cryptolog.com>
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1AE53A6973 for <pkix@core3.amsl.com>; Thu, 22 Oct 2009 08:14:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.735
X-Spam-Level:
X-Spam-Status: No, score=-1.735 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311]
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 XqLyvXEWcN-4 for <pkix@core3.amsl.com>; Thu, 22 Oct 2009 08:14:20 -0700 (PDT)
Received: from maiev.nerim.net (maiev.ipv6.nerim.net [IPv6:2001:7a8:1:1::89]) by core3.amsl.com (Postfix) with ESMTP id C24B93A6970 for <pkix@ietf.org>; Thu, 22 Oct 2009 08:14:19 -0700 (PDT)
Received: from mx.cryptolog.com (cryptolog2.pck.nerim.net [213.41.184.9]) by maiev.nerim.net (Postfix) with ESMTP id 8926CB8176; Thu, 22 Oct 2009 17:14:28 +0200 (CEST)
X-Virus-Scanned: at cryptolog.com
Received: from mua.cryptolog.com by mx.cryptolog.com (Cryptolog) with ESMTP id 4611516C061; Thu, 22 Oct 2009 17:14:28 +0200 (CEST)
Message-ID: <4AE076D4.2080704@cryptolog.com>
Date: Thu, 22 Oct 2009 17:14:28 +0200
From: Julien Stern <julien.stern@cryptolog.com>
User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706)
MIME-Version: 1.0
To: pkix@ietf.org
References: <20091014094502.674AA28C16D@core3.amsl.com>
In-Reply-To: <20091014094502.674AA28C16D@core3.amsl.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: ESI@LISTS.ETSI.ORG
Subject: Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-08.txt
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pkix>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Oct 2009 15:14:20 -0000

Internet-Drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.
> 
> 
> 	Title           : ESSCertIDv2 update for RFC 3161
> 	Author(s)       : S. Santesson, N. Pope
> 	Filename        : draft-ietf-pkix-rfc3161-update-08.txt
> 	Pages           : 8
> 	Date            : 2009-10-14


Dear all,

Sorry for jumping in late in the discussion.

I disagree with the current proposed addition to the security 
considerations section.

In the various email exchanges on this list as well as on the ESTI ESI 
list, it appears that what is currently under debate is whether the 
ESSCertID is useful from a security standpoint. So people are trying to 
argue about the feasability or the infeasability, as well as the 
practicality and the real-life impact of various certificate 
substitution attacks.

I do not think that this is the point. The point of this update is to 
allow the usage of the ESSCertID v2 (defined in RFC 5035) instead of the 
ESSCertID v1.

I do not think that adding a security consideration that is essentially 
saying "oh, by the way, ESSCertID v2 is essentially useless 
security-wise" when it is meant to be used in S/MIME, PKIX (3161, 5126), 
CAdES, XAdES, PAdES, ECOM, etc fits in such an update. I'm not sure 
either that such an update reflects the largest view of the community...

People are free to believe that ESSCertID (v1 or v2) serves no security 
purpose. Others are free to believe otherwise.

But if the authors truly believe that the ONLY possible attack scenario 
is the one roughly described in the security consideration section, then 
let them prove it. Otherwise, remove the security consideration section. 
(In my humble opinion, it is not correct anyway).

Regards,

--
Julien