Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-08.txt
"Denis Pinkas"<denis.pinkas@bull.net> Fri, 23 October 2009 12:16 UTC
Return-Path: <denis.pinkas@bull.net>
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 E96F63A6960 for <pkix@core3.amsl.com>; Fri, 23 Oct 2009 05:16:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.817
X-Spam-Level: *
X-Spam-Status: No, score=1.817 tagged_above=-999 required=5 tests=[AWL=0.628, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, RCVD_BAD_ID=2.837]
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 U6E-00FNiPG8 for <pkix@core3.amsl.com>; Fri, 23 Oct 2009 05:16:42 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by core3.amsl.com (Postfix) with ESMTP id 13EA13A6358 for <pkix@ietf.org>; Fri, 23 Oct 2009 05:16:42 -0700 (PDT)
Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (Bull S.A.) with ESMTP id D87041804A; Fri, 23 Oct 2009 14:18:25 +0200 (CEST)
Received: from FRCLS4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2009102314165167:61407 ; Fri, 23 Oct 2009 14:16:51 +0200
From: Denis Pinkas <denis.pinkas@bull.net>
To: pkix <pkix@ietf.org>
Date: Fri, 23 Oct 2009 14:16:51 +0200
Message-Id: <DreamMail__141651_38360340381@msga-001.frcl.bull.fr>
References: <C7074ACA.5810%stefan@aaa-sec.com>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-Mailer: DreamMail 4.4.1.0
X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 23/10/2009 14:16:51, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 23/10/2009 14:16:52, Serialize complete at 23/10/2009 14:16:52
Content-Type: multipart/alternative; boundary="----=_NextPart_09102314165096216263677_002"
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
Reply-To: denis.pinkas@bull.net
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: Fri, 23 Oct 2009 12:16:44 -0000
Stefan, I could agree with the "minimalist" text you propose by changing a single word in it. Change "known" into "new". Then, the last paragraph would become: The update provided by this draft is motivated by reasons of interoperability and migration to other hash algorithms rather than mitigating new security issues. Can you live with it ? Denis ----- Message reçu ----- De : pkix-bounces À : Julien Stern,pkix Date : 2009-10-23, 11:58:02 Sujet : Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-08.txt Julien, The body of this draft has been done and agreed upon for quite some time now. The document is hold back only because we have not manage to agree on one security considerations section. Removing the security considerations section is not an option. All RFC documents must have one. We are NOT trying to say that ESSCertID serves no security purpose. The original security considerations section was trying to say that the motivation for allow algorithm agility (through ESSCertIDv2) is to allow migration to other hash algorithm rather than reasons of security. This approach did however receive serious pushback from Denis. We have since then tried to find a text that is both acceptable and accurate. So far unsuccessfully. In the effort to describe the particular threat that a stronger hash would protect against, it turns out that this threat requires a malicious trusted CA. This is however something that breaks the fundamental security assumptions of PKI. If you trust a bad CA, you are smoked.. No matter how good your protocol is. As BCP 72 requires us to tell (in the security considerations) what threats are in, or out, of scope of the specified protocol. Thus, describing this threat also requires us to tell the reader that threats caused by a trusted malicious CA in general are out of scope for a protocol to solve. Failing to do so may cause a reader to believe that he needs to migrate to ESSCertIDv2 to avoid serious security threats. This is not a desired outcome and could cause both confusion and interoperability issues trough premature and unmotivated migrations to ESSCertIDv2. You are free to propose text here that meets the requirements of BCP 72 section 5. I personally would be happy with a short note saying what we originally wanted to say.. That is: This draft incorporates the security considerations of RFC 5035 [ESSV2] with further explanations in this section. ESSCertID provides a means based on the SHA-1 hash algorithm for identifying the certificate used to verify the signature on a time stamp. The use of ESSCertIDv2 aims to enable implementers to comply with policies that require phasing out all uses of the SHA-1 algorithm. The update provided by this draft is motivated by reasons of interoperability and migration to other hash algorithms rather than mitigating known security issues. ... And delete the rest. /Stefan On 09-10-22 5:14 PM, "Julien Stern" <julien.stern@cryptolog.com> wrote: > 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 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix
- [pkix] I-D Action:draft-ietf-pkix-rfc3161-update-… Internet-Drafts
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Julien Stern
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Dino Esposito
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Stefan Santesson
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Denis Pinkas
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Julien Stern
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Stefan Santesson
- Re: [pkix] I-D Action:draft-ietf-pkix-rfc3161-upd… Stefan Santesson