RE: New Liaison Statement, "Liaison to IETF on the resolution of DR320"
"Santosh Chokhani" <chokhani@orionsec.com> Thu, 25 October 2007 13:53 UTC
Return-path: <owner-ietf-pkix@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il39k-0004QX-HX for pkix-archive@lists.ietf.org; Thu, 25 Oct 2007 09:53:52 -0400
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il39Z-0004Aj-7T for pkix-archive@lists.ietf.org; Thu, 25 Oct 2007 09:53:42 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9PCoQQx000686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Oct 2007 05:50:27 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l9PCoQoU000685; Thu, 25 Oct 2007 05:50:26 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from EXVS01.ex.dslextreme.net ([66.51.199.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9PCoPVb000676 for <ietf-pkix@imc.org>; Thu, 25 Oct 2007 05:50:26 -0700 (MST) (envelope-from chokhani@orionsec.com)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: RE: New Liaison Statement, "Liaison to IETF on the resolution of DR320"
Date: Thu, 25 Oct 2007 05:50:10 -0700
Message-ID: <82D5657AE1F54347A734BDD33637C87909945C47@EXVS01.ex.dslextreme.net>
In-Reply-To: <20071025084358.GD4999@mars.cry.pto>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: New Liaison Statement, "Liaison to IETF on the resolution of DR320"
thread-index: AcgW7nGtamqKqlMNTXKUbsczXflWXQAFwyxA
References: <OF49CACE0F.A054F73F-ONC125737C.0041B2BD@frcl.bull.fr> <82D5657AE1F54347A734BDD33637C8790987D3BC@EXVS01.ex.dslextreme.net> <20071022143330.GQ4999@mars.cry.pto> <82D5657AE1F54347A734BDD33637C8790987D7E4@EXVS01.ex.dslextreme.net> <20071025084358.GD4999@mars.cry.pto>
From: Santosh Chokhani <chokhani@orionsec.com>
To: Julien Stern <julien.stern@cryptolog.com>, ietf-pkix@imc.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l9PCoQVb000680
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e
Julien, It is very simple. Point to me to the specific post or e-mail me (not the entire mail list) your protection approach. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Julien Stern Sent: Thursday, October 25, 2007 4:44 AM To: ietf-pkix@imc.org Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution of DR320" Santosh, I think you are being a bit unfair, as I did explain on the list as clearly as I could the attack and the protection (early Nov 2004). Anyway, I do not feel like boring other readers to death by starting the whole discussion once again. Maybe we can sit down at a table and chat if we happen to meet at a conference someday :) Regards, -- Julien On Mon, Oct 22, 2007 at 10:41:10AM -0700, Santosh Chokhani wrote: > Julien, > > What I recall is that your attack was a CA trusted to issue CA > certificates by the relying party going rogue. X.509 does not protect > against that. > > You also mentioned that you had protection against it, you were > unwilling to share it, and you said that you will share it after you > publish your work. > > I have yet to see your proposal. > > As a matter of fact on PKIX or X.500 forum within last year again I > asked you to share your proposal and you never replied. > > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Julien Stern > Sent: Monday, October 22, 2007 10:34 AM > To: ietf-pkix@imc.org > Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution > of DR320" > > > On Mon, Oct 22, 2007 at 06:18:22AM -0700, Santosh Chokhani wrote: > > > > We have been down this route before. > > Oooooh Yes. Lots of fun and (gentle) arguments... > > > See my presentation to PKIX in Fall 2004 IETF meeting in Washington > DC. > > > > My understanding from 2004 presentation was that Russ Housley proposed > instead of ensuring certificate certification path and CRL certification > path matching, we make sure that we ensure that the paths begin at the > same trust anchor. It was felt by the group (not I) that coupled with > name constraints in cross certified environment is sufficient to > mitigate the risk to an acceptably low level. Of course, my argument > always has been that using the certificate certification path to > constrain the CRL certification path provides you both with security and > efficiency, something you do not always get. The primary reason to not > adopt my suggestion is that it requires change to client software. > > I did not feel either that trust anchor matching was sufficient enough. > > As you may remember, I also felt that your proposed solution, while > improving the situation, did not close every possible attacks, and I > proposed an alternative that was (in my humble opinion) even more secure > but with even more changes on the client software. > > Anyway, my current take on the subject would be roughly the following. > RFC3280bis could include something in the line of: > > "The uniqueness of DN of all entities in all the Trust Anchors > hierarchies SHOULD be enforced. If the uniqueness cannot be guaranteed > in some circonstances, client software MAY implement additional checks > in order to lower the risk of outputing an incorrect revocation value > during > path validation. [We could give example of additional checks here: > checking the trust anchor matching, check the full path matching, > checking the AuthorityKeyIdentifier hash matching, etc]. Client > implementors should however be aware that these additional checks may > hinder interoperability in the general case." > > -- > Julien > >
- Re: New Liaison Statement, "Liaison to IETF on th… Russ Housley
- Re: New Liaison Statement, "Liaison to IETF on th… Paul Hoffman
- RE: New Liaison Statement, "Liaison to IETF on th… Ryan Hurst
- RE: New Liaison Statement, "Liaison to IETF on th… Tom Gindin
- RE: New Liaison Statement, "Liaison to IETF on th… Paul Hoffman
- Re: New Liaison Statement, "Liaison to IETF on th… Steven Legg
- Re: New Liaison Statement, "Liaison to IETF on th… Denis Pinkas
- Re: New Liaison Statement, "Liaison to IETF on th… Denis Pinkas
- Re: New Liaison Statement, "Liaison to IETF on th… Julien Stern
- Re: New Liaison Statement, "Liaison to IETF on th… Denis Pinkas
- RE: New Liaison Statement, "Liaison to IETF on th… Santosh Chokhani
- Re: New Liaison Statement, "Liaison to IETF on th… Denis Pinkas
- Re: New Liaison Statement, "Liaison to IETF on th… Julien Stern
- Re: New Liaison Statement, "Liaison to IETF on th… Julien Stern
- Re: New Liaison Statement, "Liaison to IETF on th… Denis Pinkas
- RE: New Liaison Statement, "Liaison to IETF on th… Santosh Chokhani
- RE: New Liaison Statement, "Liaison to IETF on th… Santosh Chokhani
- Re: New Liaison Statement, "Liaison to IETF on th… Paul Hoffman
- RE: New Liaison Statement, "Liaison to IETF on th… stephen.farrell
- RE: New Liaison Statement, "Liaison to IETF on th… Santosh Chokhani
- Re: New Liaison Statement, "Liaison to IETF on th… Julien Stern
- RE: New Liaison Statement, "Liaison to IETF on th… Santosh Chokhani