Re: New Liaison Statement, "Liaison to IETF on the removal

http://www.pansarex.com/

HSIANG Klien

------=_NextPart_000_0005_01C81603.B539DBC0-- From Plutaygmv@hjcgas.com Wed Oct 24 06:24:30 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkdPa-00025Q-Bf for pkix-archive@lists.ietf.org; Wed, 24 Oct 2007 06:24:30 -0400 Received: from e179087164.adsl.alicedsl.de ([85.179.87.164] helo=e181177106.adsl.alicedsl.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkdPW-0008DY-JP for pkix-archive@lists.ietf.org; Wed, 24 Oct 2007 06:24:27 -0400 Received: from 59aede1cd2dd46b ([115.174.152.31]:13987 "EHLO 59aede1cd2dd46b" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [85.179.206.167] with ESMTP id S22QDRJHLATKLKDG (ORCPT ); Wed, 24 Oct 2007 12:24:42 +0200 Message-ID: <000401c81628$103809b0$a7ceb355@59aede1cd2dd46b> From: "mauricio Pluta" To: Subject: versets Date: Wed, 24 Oct 2007 12:24:30 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C81638.D3C0D9B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.0 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0004_01C81638.D3C0D9B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hola pkix-archive give her the full sausage when you increase your cock size http://resxxx.com/ mauricio Pluta ------=_NextPart_000_0004_01C81638.D3C0D9B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

hola pkix-archive

give her the full sausage when you increase = your cock=20 size

http://resxxx.com/

mauricio Pluta

------=_NextPart_000_0004_01C81638.D3C0D9B0-- From cip-pinkard@neox-tech.com Thu Oct 25 05:07:59 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikyh5-0006jP-16 for pkix-archive@lists.ietf.org; Thu, 25 Oct 2007 05:07:59 -0400 Received: from [189.32.124.142] (helo=BD207C8E.poa.virtua.com.br) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ikygj-0000GL-QJ for pkix-archive@lists.ietf.org; Thu, 25 Oct 2007 05:07:38 -0400 Received: from rafael ([104.195.31.36] helo=rafael) by BD207C8E.poa.virtua.com.br ( sendmail 8.13.3/8.13.1) with esmtpa id 1ImbiQ-000DQA-Qb for pkix-archive@lists.ietf.org; Thu, 25 Oct 2007 07:04:31 -0200 Message-ID: <000201c816e6$0736a510$8e7c20bd@rafael> From: "cip pinkard" To: Subject: ticohadi Date: Thu, 25 Oct 2007 07:04:19 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C816D5.43ADD510" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.7 (++++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0009_01C816D5.43ADD510 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable How's tricks? pkix-archive dont waste another minute, make your penis massive http://www.rtfil.com/ cip pinkard ------=_NextPart_000_0009_01C816D5.43ADD510 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

How's tricks? pkix-archive

dont waste another minute, make your penis=20 massive

http://www.rtfil.com/

cip pinkard

------=_NextPart_000_0009_01C816D5.43ADD510-- From owner-ietf-pkix@mail.imc.org Thu Oct 25 05:51:17 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkzMz-0003fg-05 for pkix-archive@lists.ietf.org; Thu, 25 Oct 2007 05:51:17 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkzMk-00066L-0x for pkix-archive@lists.ietf.org; Thu, 25 Oct 2007 05:51:08 -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 l9P8i7hd079848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Oct 2007 01:44:07 -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 l9P8i7bO079847; Thu, 25 Oct 2007 01:44:07 -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 kraid.nerim.net (smtp-104-thursday.nerim.net [62.4.16.104]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9P8i6WW079839 for ; Thu, 25 Oct 2007 01:44:07 -0700 (MST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog2.pck.nerim.net [213.41.184.9]) by kraid.nerim.net (Postfix) with ESMTP id 95F00CF0AE for ; Thu, 25 Oct 2007 10:44:04 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 2045D4428C for ; Thu, 25 Oct 2007 10:44:04 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at cryptolog.com Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus.cry.pto [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPISboNCw3ck for ; Thu, 25 Oct 2007 10:44:00 +0200 (CEST) Received: from mars.cry.pto (isonoe.cry.pto [10.0.1.15]) by uranus.cry.pto (Postfix) with SMTP id 092DA4427F for ; Thu, 25 Oct 2007 10:43:59 +0200 (CEST) Received: by mars.cry.pto (sSMTP sendmail emulation); Thu, 25 Oct 2007 10:43:59 +0200 From: "Julien Stern" Date: Thu, 25 Oct 2007 10:43:58 +0200 To: ietf-pkix@imc.org Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution of DR320" Message-ID: <20071025084358.GD4999@mars.cry.pto> Mail-Followup-To: Julien Stern , ietf-pkix@imc.org References: <82D5657AE1F54347A734BDD33637C8790987D3BC@EXVS01.ex.dslextreme.net> <20071022143330.GQ4999@mars.cry.pto> <82D5657AE1F54347A734BDD33637C8790987D7E4@EXVS01.ex.dslextreme.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82D5657AE1F54347A734BDD33637C8790987D7E4@EXVS01.ex.dslextreme.net> User-Agent: Mutt/1.5.13 (2006-08-11) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be 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 > > From owner-ietf-pkix@mail.imc.org Thu Oct 25 09:53:52 2007 Return-path: 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 ; 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: <82D5657AE1F54347A734BDD33637C8790987D3BC@EXVS01.ex.dslextreme.net> <20071022143330.GQ4999@mars.cry.pto> <82D5657AE1F54347A734BDD33637C8790987D7E4@EXVS01.ex.dslextreme.net> <20071025084358.GD4999@mars.cry.pto> From: "Santosh Chokhani" To: "Julien Stern" , 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: List-ID: List-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 > > From owner-ietf-pkix@mail.imc.org Fri Oct 26 06:32:34 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlMUU-0007vE-Eu for pkix-archive@lists.ietf.org; Fri, 26 Oct 2007 06:32:34 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlMUG-0007J6-U7 for pkix-archive@lists.ietf.org; Fri, 26 Oct 2007 06:32:32 -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 l9Q9RrXF045874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Oct 2007 02:27:53 -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 l9Q9Rrhu045873; Fri, 26 Oct 2007 02:27:53 -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 pfepa.post.tele.dk (pfepa.post.tele.dk [195.41.46.235]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9Q9RpO7045864 for ; Fri, 26 Oct 2007 02:27:52 -0700 (MST) (envelope-from era@tdcadsl.dk) Received: from morten (0x503ff080.albnxx10.adsl-dhcp.tele.dk [80.63.240.128]) by pfepa.post.tele.dk (Postfix) with ESMTP id 87826FAC04E; Fri, 26 Oct 2007 11:27:48 +0200 (CEST) From: "Erik Andersen" To: "'Russ Housley'" , "'Hoyt L Kesterson II'" , Subject: RE: Upper Bounds for X.509 Date: Fri, 26 Oct 2007 11:28:41 +0200 Message-ID: <000101c817b2$99ff1db0$0100a8c0@morten> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6822 In-Reply-To: <200710221034.l9MAYKwt097035@balder-227.proper.com> Importance: Normal Thread-Index: AcgUofmawl/U3apHTzSftthhyN1X/gDEF5dg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 PKIX could impose upper bounds on anything they want without this being reflected in the ASN.1, but in English text. Erik Andersen Andersen's L-Service Mobile: +45 20 97 14 90 e-mail: era@tdcadsl.dk http://www.x500standard.com/ http://home20.inet.tele.dk/era/me > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Russ Housley > Sent: 22. oktober 2007 11:34 > To: Hoyt L Kesterson II; ietf-pkix@imc.org > Subject: Re: Upper Bounds for X.509 > > > Hoyt: > > One never knows which non-critical extensions might be put in a > certificate. Remember when Bob Jueneman was advocating pictures in > certificates.... > > Russ > > > At 04:30 AM 10/22/2007, Hoyt L Kesterson II wrote: > > >Steven, I didn't say it was an attractive option. I have always been > >against these limits. > > > >Peter Gutmann recommended that "reasonable" upper bounds be set, > >e.g. thousand characters for a common name. But it appears his > >concern is about erratic operation when the certificate itself it huge. > > > >It may be more reasonable to set a max size on the entire > >certificate than on the individual components that comprise it. > > > > hoyt > > > > >Hoyt, > > > > > >Hoyt L Kesterson II wrote: > > >>Another option is to keep the bounds as we have them and have the > > IETF standard mandate the bounds, choosing any values you like. > > > > > >Then directory deployments would have to choose between being nice > > >to PKIX applications by imposing PKIX's upper bounds, or being > > >nice to other LDAP applications by not imposing upper bounds. > > > > > >Regards, > > >Steven From ingman@altcom.pl Fri Oct 26 08:49:38 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlOd8-0006EC-FU for pkix-archive@lists.ietf.org; Fri, 26 Oct 2007 08:49:38 -0400 Received: from [81.215.1.168] (helo=dsl.static812151168.ttnet.net.tr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlOd4-0002ul-U2 for pkix-archive@lists.ietf.org; Fri, 26 Oct 2007 08:49:36 -0400 Received: by 10.175.38.206 with SMTP id sruvTAOEnpYiG; Fri, 26 Oct 2007 15:49:41 +0300 (GMT) Received: by 192.168.174.96 with SMTP id imddBQYpThjwxd.2066581578347; Fri, 26 Oct 2007 15:49:39 +0300 (GMT) Message-ID: <000901c817ce$aa190f50$a801d751@pc> From: "Kari ingman" To: Subject: 0greater Date: Fri, 26 Oct 2007 15:49:36 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C817E7.CF664750" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.5 (+) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0008_01C817E7.CF664750 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable Hallo pkix-archive dont waste another minute, make your penis massive http://rtfil.com/ Kari ingman ------=_NextPart_000_0008_01C817E7.CF664750 Content-Type: text/html; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable

Hallo pkix-archive

dont waste another minute, make your penis=20 massive

http://rtfil.com/

Kari ingman

------=_NextPart_000_0008_01C817E7.CF664750-- From chasady.Josefsson@uncleduckyoutfitters.com Sat Oct 27 13:03:05 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ilp3x-0000YV-CZ for pkix-archive@lists.ietf.org; Sat, 27 Oct 2007 13:03:05 -0400 Received: from [85.99.212.238] (helo=dsl.dynamic8599212238.ttnet.net.tr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ilp3s-00011f-Iu for pkix-archive@lists.ietf.org; Sat, 27 Oct 2007 13:03:01 -0400 Received: from i5c8a6 ([155.173.187.58] helo=i5c8a6) by dsl.dynamic8599212238.ttnet.net.tr ( sendmail 8.13.3/8.13.1) with esmtpa id 1ypUBZ-000KED-SH for pkix-archive@lists.ietf.org; Sat, 27 Oct 2007 20:03:25 +0300 Message-ID: <000401c818bb$3a4ec190$eed46355@i5c8a6> From: "chasady Josefsson" To: Subject: kousanky Date: Sat, 27 Oct 2007 20:02:59 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C818D4.5F9BF990" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0005_01C818D4.5F9BF990 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable hellow pkix-archive her pussy is screaming for some seriously big dick http://takipark.com/ chasady Josefsson ------=_NextPart_000_0005_01C818D4.5F9BF990 Content-Type: text/html; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable

hellow pkix-archive

her pussy is screaming for some seriously big=20 dick

http://takipark.com/

chasady Josefsson

------=_NextPart_000_0005_01C818D4.5F9BF990-- From owner-ietf-pkix@mail.imc.org Mon Oct 29 06:42:33 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImS4n-0004cp-9l for pkix-archive@lists.ietf.org; Mon, 29 Oct 2007 06:42:33 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImS4Z-0006wD-Af for pkix-archive@lists.ietf.org; Mon, 29 Oct 2007 06:42:27 -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 l9T9ZHuh095742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Oct 2007 02:35:17 -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 l9T9ZHdG095741; Mon, 29 Oct 2007 02:35:17 -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 smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9T9ZFLg095727 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 29 Oct 2007 02:35:16 -0700 (MST) (envelope-from stefans@microsoft.com) Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.222.3; Mon, 29 Oct 2007 09:35:14 +0000 Received: from EA-EXMSG-C320.europe.corp.microsoft.com ([65.53.221.77]) by dub-exhub-c302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Mon, 29 Oct 2007 09:35:13 +0000 From: Stefan Santesson To: Stefan Santesson , "ietf-pkix@imc.org" Date: Mon, 29 Oct 2007 09:35:07 +0000 Subject: RE: Call for agenda items - Vancouver IETF Thread-Topic: Call for agenda items - Vancouver IETF Thread-Index: AcgU0hCHXWJbPwVPT7+3o4MRnK6r3wFPKLeA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E75F200AF1718F45B2024A88C3141A1D06478B0E9DEAEXMSGC320eu_" MIME-Version: 1.0 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-Spam-Score: 0.0 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd --_000_E75F200AF1718F45B2024A88C3141A1D06478B0E9DEAEXMSGC320eu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just a friendly reminder. So far the number of received requests is 0. Thanks. Stefan Santesson Senior Program Manager Windows Security, Standards From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On= Behalf Of Stefan Santesson Sent: den 22 oktober 2007 19:36 To: ietf-pkix@imc.org Subject: Call for agenda items - Vancouver IETF Vancouver IETF is coming up. Please send me requests for agenda slots. As usual I would appreciate if editors of current documents let me know if = they want a slot and their assessment of the current status. I would appreciate requests to be sent to me as soon as possible and at lat= est Friday November 2nd. Thank you. Stefan Santesson Senior Program Manager Windows Security, Standards --_000_E75F200AF1718F45B2024A88C3141A1D06478B0E9DEAEXMSGC320eu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just a friendly reminder.

So far the = number of received requests is 0.

Thanks.

Stefan Santesson

Senior Program Manager=

Windows Security, Standards<= span lang=3DEN-US style=3D'color:#1F497D'>

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson<= br> Sent: den 22 oktober 2007 19:36
To: ietf-pkix@imc.org
Subject: Call for agenda items - Vancouver IETF

Vancouver IETF is coming up.

Please send me requests for agenda = slots.

As usual I would appreciate if edit= ors of current documents let me know if they want a slot and their assessment of the curre= nt status.

I would appreciate requests to be s= ent to me as soon as possible and at latest Friday November 2^nd.

Thank you.

Stefan Santesson

Senior Program Manager=

Windows Security, Standards<= span lang=3DEN-US style=3D'color:#1F497D'>

--_000_E75F200AF1718F45B2024A88C3141A1D06478B0E9DEAEXMSGC320eu_-- From Bary392@dennisackley.com Mon Oct 29 06:58:34 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImSKI-0003ok-2c for pkix-archive@lists.ietf.org; Mon, 29 Oct 2007 06:58:34 -0400 Received: from adsl-225-85.eunet.yu ([213.198.225.85]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImSKC-0003qD-CU for pkix-archive@lists.ietf.org; Mon, 29 Oct 2007 06:58:28 -0400 Received: from Desktop ([140.190.42.62] helo=Desktop) by adsl-225-85.eunet.yu ( sendmail 8.13.3/8.13.1) with esmtpa id 1mJiIC-000HZS-FW for pkix-archive@lists.ietf.org; Mon, 29 Oct 2007 11:58:42 +0100 Message-ID: <79A86B4C.E85550D6@dennisackley.com> Date: Mon, 29 Oct 2007 11:58:31 +0100 From: "Bary Darris" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: pkix-archive@lists.ietf.org Subject: setiuqin Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.6 (+++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea hey baby pkix-archive shes frustrated when you make love so why dont you sort it out? http://www.tahfm.com/ Bary Darris From magdas@physics.purdue.edu Tue Oct 30 21:08:23 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In24F-0005ZK-7E for pkix-archive@lists.ietf.org; Tue, 30 Oct 2007 21:08:23 -0400 Received: from [190.42.124.241] (helo=ekaf) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1In24A-0008Tr-Qp for pkix-archive@lists.ietf.org; Tue, 30 Oct 2007 21:08:20 -0400 Received: (qmail 3988 invoked from network); Tue, 30 Oct 2007 20:08:06 -0500 Received: from unknown (HELO uyxph) (76.177.26.235) by ekaf with SMTP; Tue, 30 Oct 2007 20:08:06 -0500 Message-ID: <000701c81b5a$7e9eebd0$eb1ab14c@uyxph> From: To: Subject: If your in your office, keep the speakers low, lol Date: Tue, 30 Oct 2007 20:08:06 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.8 (++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 I know you will like this. Heck you might even pass it on. LOL http://76.98.230.239/ From Grattonnhs@alm-bauplanung.de Tue Oct 30 22:41:24 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In3WG-0007Xn-EQ for pkix-archive@lists.ietf.org; Tue, 30 Oct 2007 22:41:24 -0400 Received: from host153-63-dynamic.21-87-r.retail.telecomitalia.it ([87.21.63.153] helo=host129-96-dynamic.1-79-r.retail.telecomitalia.it) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1In3WD-0006Ql-TF for pkix-archive@lists.ietf.org; Tue, 30 Oct 2007 22:41:22 -0400 Received: from sajjad ([198.157.163.58]:10577 "EHLO sajjad" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by host129-96-dynamic.1-79-r.retail.telecomitalia.it with ESMTP id S22TABJVHAFAAFJN (ORCPT ); Tue, 30 Oct 2007 03:42:24 +0100 Message-ID: <000401c81a9e$70c34720$8160014f@sajjad> From: "fdsafsfa Gratton" To: Subject: fadesen Date: Tue, 30 Oct 2007 03:41:57 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C81AA6.D287AF20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.8 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0009_01C81AA6.D287AF20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable whats poppin pkix-archive let your dick do all the talking, just make it bigger! http://www.bbrerto.com/ fdsafsfa Gratton ------=_NextPart_000_0009_01C81AA6.D287AF20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

whats poppin pkix-archive

let your dick do all the talking, just make it = bigger!

http://www.bbrerto.com/

fdsafsfa Gratton

------=_NextPart_000_0009_01C81AA6.D287AF20-- From shoaib.Heshiki@888-5spycam.com Wed Oct 31 17:58:51 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InLaN-00053W-Ug for pkix-archive@lists.ietf.org; Wed, 31 Oct 2007 17:58:51 -0400 Received: from host34-2-static.88-82-b.business.telecomitalia.it ([82.88.2.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InLaH-0006rZ-Gl for pkix-archive@lists.ietf.org; Wed, 31 Oct 2007 17:58:51 -0400 Received: by 10.53.219.88 with SMTP id ZQdRZoqxIUskP; Wed, 31 Oct 2007 23:00:49 +0100 (GMT) Received: by 192.168.78.58 with SMTP id AAqkEmmaghNyFE.7390307994060; Wed, 31 Oct 2007 23:00:47 +0100 (GMT) Message-ID: <5E0E3AB9.56357BD5@888-5spycam.com> Date: Wed, 31 Oct 2007 23:00:44 +0100 From: "shoaib Heshiki" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: pkix-archive@lists.ietf.org Subject: scottano Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea hello mom pkix-archive she said she was impossible to please, may be you can with 3 inches more http://www.chayzy.com/ shoaib Heshiki Received: from [190.41.157.76] ([190.41.157.76]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9VKtsP6014171 for ; Wed, 31 Oct 2007 13:55:58 -0700 (MST) (envelope-from DeOliveiracrqr@idmx.com) Received: from n�utica_radio ([168.159.157.31] helo=n�utica_radio) by [190.41.157.76] ( sendmail 8.13.3/8.13.1) with esmtpa id 1KlYjv-000QCF-Fa for ietf-pkix-archive@imc.org; Wed, 31 Oct 2007 15:56:24 -0500 Date: Wed, 31 Oct 2007 15:55:58 -0500 From: "Akil DeOliveira" Reply-To: "Akil DeOliveira" Message-ID: <989111912790.765073928989@idmx.com> To: Subject: atiot MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original hey you ietf-pkix-archive as far as everyone can see, your dick needs some serious improvement http://babaztag.com/ Akil DeOliveira 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 l9T9ZHuh095742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Oct 2007 02:35:17 -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 l9T9ZHdG095741; Mon, 29 Oct 2007 02:35:17 -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 smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9T9ZFLg095727 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 29 Oct 2007 02:35:16 -0700 (MST) (envelope-from stefans@microsoft.com) Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.222.3; Mon, 29 Oct 2007 09:35:14 +0000 Received: from EA-EXMSG-C320.europe.corp.microsoft.com ([65.53.221.77]) by dub-exhub-c302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Mon, 29 Oct 2007 09:35:13 +0000 From: Stefan Santesson To: Stefan Santesson , "ietf-pkix@imc.org" Date: Mon, 29 Oct 2007 09:35:07 +0000 Subject: RE: Call for agenda items - Vancouver IETF Thread-Topic: Call for agenda items - Vancouver IETF Thread-Index: AcgU0hCHXWJbPwVPT7+3o4MRnK6r3wFPKLeA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E75F200AF1718F45B2024A88C3141A1D06478B0E9DEAEXMSGC320eu_" MIME-Version: 1.0 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --_000_E75F200AF1718F45B2024A88C3141A1D06478B0E9DEAEXMSGC320eu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just a friendly reminder. So far the number of received requests is 0. Thanks. Stefan Santesson Senior Program Manager Windows Security, Standards From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On= Behalf Of Stefan Santesson Sent: den 22 oktober 2007 19:36 To: ietf-pkix@imc.org Subject: Call for agenda items - Vancouver IETF Vancouver IETF is coming up. Please send me requests for agenda slots. As usual I would appreciate if editors of current documents let me know if = they want a slot and their assessment of the current status. I would appreciate requests to be sent to me as soon as possible and at lat= est Friday November 2nd. Thank you. Stefan Santesson Senior Program Manager Windows Security, Standards --_000_E75F200AF1718F45B2024A88C3141A1D06478B0E9DEAEXMSGC320eu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just a friendly reminder.

So far the = number of received requests is 0.

Thanks.

Stefan Santesson

Senior Program Manager=

Windows Security, Standards<= span lang=3DEN-US style=3D'color:#1F497D'>

Vancouver IETF is coming up.

Please send me requests for agenda = slots.

As usual I would appreciate if edit= ors of current documents let me know if they want a slot and their assessment of the curre= nt status.

I would appreciate requests to be s= ent to me as soon as possible and at latest Friday November 2^nd.

Thank you.

Stefan Santesson

Senior Program Manager=

Windows Security, Standards<= span lang=3DEN-US style=3D'color:#1F497D'>

--_000_E75F200AF1718F45B2024A88C3141A1D06478B0E9DEAEXMSGC320eu_-- Received: from 80.178.31.113.adsl.012.net.il (80.178.31.113.adsl.012.net.il [80.178.31.113]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l9R1pSo8041315; Fri, 26 Oct 2007 18:51:30 -0700 (MST) (envelope-from costello@326.cc) Date: Fri, 26 Oct 2007 22:51:47 -0400 From: "Rosalie Monroe" Message-ID: <83618446.06042026@ulysses.com> To: press@imc.org Subject: Good clothes open all doors. MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit If your "prick-horse" is not glad for you and give brake for you come to us. You'll feel that curb "it" is impossible. You must come to us now and you'll be a real cowboy legend. We wait you today, because the hot week of discounts is now. Don't miss your chance. http://ovloxq.partywill.cn/?808817644044 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 l9Q9RrXF045874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Oct 2007 02:27:53 -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 l9Q9Rrhu045873; Fri, 26 Oct 2007 02:27:53 -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 pfepa.post.tele.dk (pfepa.post.tele.dk [195.41.46.235]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9Q9RpO7045864 for ; Fri, 26 Oct 2007 02:27:52 -0700 (MST) (envelope-from era@tdcadsl.dk) Received: from morten (0x503ff080.albnxx10.adsl-dhcp.tele.dk [80.63.240.128]) by pfepa.post.tele.dk (Postfix) with ESMTP id 87826FAC04E; Fri, 26 Oct 2007 11:27:48 +0200 (CEST) From: "Erik Andersen" To: "'Russ Housley'" , "'Hoyt L Kesterson II'" , Subject: RE: Upper Bounds for X.509 Date: Fri, 26 Oct 2007 11:28:41 +0200 Message-ID: <000101c817b2$99ff1db0$0100a8c0@morten> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6822 In-Reply-To: <200710221034.l9MAYKwt097035@balder-227.proper.com> Importance: Normal Thread-Index: AcgUofmawl/U3apHTzSftthhyN1X/gDEF5dg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: PKIX could impose upper bounds on anything they want without this being reflected in the ASN.1, but in English text. Erik Andersen Andersen's L-Service Mobile: +45 20 97 14 90 e-mail: era@tdcadsl.dk http://www.x500standard.com/ http://home20.inet.tele.dk/era/me > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Russ Housley > Sent: 22. oktober 2007 11:34 > To: Hoyt L Kesterson II; ietf-pkix@imc.org > Subject: Re: Upper Bounds for X.509 > > > Hoyt: > > One never knows which non-critical extensions might be put in a > certificate. Remember when Bob Jueneman was advocating pictures in > certificates.... > > Russ > > > At 04:30 AM 10/22/2007, Hoyt L Kesterson II wrote: > > >Steven, I didn't say it was an attractive option. I have always been > >against these limits. > > > >Peter Gutmann recommended that "reasonable" upper bounds be set, > >e.g. thousand characters for a common name. But it appears his > >concern is about erratic operation when the certificate itself it huge. > > > >It may be more reasonable to set a max size on the entire > >certificate than on the individual components that comprise it. > > > > hoyt > > > > >Hoyt, > > > > > >Hoyt L Kesterson II wrote: > > >>Another option is to keep the bounds as we have them and have the > > IETF standard mandate the bounds, choosing any values you like. > > > > > >Then directory deployments would have to choose between being nice > > >to PKIX applications by imposing PKIX's upper bounds, or being > > >nice to other LDAP applications by not imposing upper bounds. > > > > > >Regards, > > >Steven 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 ; 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: <82D5657AE1F54347A734BDD33637C8790987D3BC@EXVS01.ex.dslextreme.net> <20071022143330.GQ4999@mars.cry.pto> <82D5657AE1F54347A734BDD33637C8790987D7E4@EXVS01.ex.dslextreme.net> <20071025084358.GD4999@mars.cry.pto> From: "Santosh Chokhani" To: "Julien Stern" , 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: List-ID: List-Unsubscribe: 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 > > 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 l9P8i7hd079848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Oct 2007 01:44:07 -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 l9P8i7bO079847; Thu, 25 Oct 2007 01:44:07 -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 kraid.nerim.net (smtp-104-thursday.nerim.net [62.4.16.104]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9P8i6WW079839 for ; Thu, 25 Oct 2007 01:44:07 -0700 (MST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog2.pck.nerim.net [213.41.184.9]) by kraid.nerim.net (Postfix) with ESMTP id 95F00CF0AE for ; Thu, 25 Oct 2007 10:44:04 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 2045D4428C for ; Thu, 25 Oct 2007 10:44:04 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at cryptolog.com Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus.cry.pto [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPISboNCw3ck for ; Thu, 25 Oct 2007 10:44:00 +0200 (CEST) Received: from mars.cry.pto (isonoe.cry.pto [10.0.1.15]) by uranus.cry.pto (Postfix) with SMTP id 092DA4427F for ; Thu, 25 Oct 2007 10:43:59 +0200 (CEST) Received: by mars.cry.pto (sSMTP sendmail emulation); Thu, 25 Oct 2007 10:43:59 +0200 From: "Julien Stern" Date: Thu, 25 Oct 2007 10:43:58 +0200 To: ietf-pkix@imc.org Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution of DR320" Message-ID: <20071025084358.GD4999@mars.cry.pto> Mail-Followup-To: Julien Stern , ietf-pkix@imc.org References: <82D5657AE1F54347A734BDD33637C8790987D3BC@EXVS01.ex.dslextreme.net> <20071022143330.GQ4999@mars.cry.pto> <82D5657AE1F54347A734BDD33637C8790987D7E4@EXVS01.ex.dslextreme.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82D5657AE1F54347A734BDD33637C8790987D7E4@EXVS01.ex.dslextreme.net> User-Agent: Mutt/1.5.13 (2006-08-11) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 > > Received: from 202-133-68-138-sat.net.pk (202-133-68-138-sat.net.pk [202.133.68.138] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9NHWbcg072029; Tue, 23 Oct 2007 10:32:40 -0700 (MST) (envelope-from darad@erai.ann.com) Received: from [192.168.0.1] by p5B0746F6.dip.t-dialin.net id PTFW5zgPC2Wx; Tue, 23 Oct 2007 20:32:33 +0300 Received: from 192.168.68.177 ([192.168.68.177]) by 192.168.0.1 (WinRoute Pro 4.2.8) with SMTP; Tue, 23 Oct 2007 20:32:33 +0300 Message-ID: <007a01c8159a$a1936f00$0100a8c0@p5B0746F6.dip.t-dialin.net> From: "Marika" To: "Tim" Subject: i want to know you! Date: Tue, 23 Oct 2007 20:32:33 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 8bit Aloha, my gentleman! Please, open windows into your heart. I know that you are embarrassed, what you can have common with woman from far Ukraine, the country which is situated at the another part of the world. Before writing to you this letter, I was puzzled by this question too till I have not found the answer and you here. We are both lonely and want the same: to find love and to be happy. Am I right? I am not risky person, but I want to risk this time, because it is the one chance to get acquainted with you and to create couple with you. I am kind-hearted, pretty woman who is able to love and take care. If my words touched your heart and you want to find your love, write me here http://russobride.info/?idAff=101 Yourth faithfully Marinochka Received: from [195.22.21.202] ([195.22.21.202]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9NDmsTI049866 for ; Tue, 23 Oct 2007 06:48:57 -0700 (MST) (envelope-from manju@artworkdental.com) Received: from rita ([145.146.3.179]:12115 "EHLO rita" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [195.22.21.202] with ESMTP id S22JVXEVCDUKMZQX (ORCPT ); Tue, 23 Oct 2007 14:44:52 +0100 Message-ID: <000701c8157a$cf047b70$ca1516c3@rita> From: "manju DeBenedictis" To: Subject: 0tnuah Date: Tue, 23 Oct 2007 14:44:18 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C81583.30C8E370" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Antivirus: avast! (VPS 000783-1, 22-10-2007), Outbound message X-Antivirus-Status: Clean ------=_NextPart_000_0006_01C81583.30C8E370 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Watcha! ietf-pkix-archive is she faking it? take care of that and make your dick big http://www.parsno.com/ manju DeBenedictis ------=_NextPart_000_0006_01C81583.30C8E370 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Watcha! ietf-pkix-archive

is she faking it? take care of that and make = your dick=20 big

http://www.parsno.com/

manju DeBenedictis

------=_NextPart_000_0006_01C81583.30C8E370-- 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 l9NBF90l035031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Oct 2007 04:15:09 -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 l9NBF9On035030; Tue, 23 Oct 2007 04:15:09 -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 l9NBF8Vv035024 for ; Tue, 23 Oct 2007 04:15:08 -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: Tue, 23 Oct 2007 04:14:56 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C879098EC07A@EXVS01.ex.dslextreme.net> In-Reply-To: <50643.195.56.169.116.1193132579.squirrel@webmail.cs.tcd.ie> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Liaison Statement, "Liaison to IETF on the resolution of DR320" thread-index: AcgVZEOy4jxvPSLHTGamc53wC8IHXgAAViaA References: <82D5657AE1F54347A734BDD33637C879098EBEB1@EXVS01.ex.dslextreme.net> <50643.195.56.169.116.1193132579.squirrel@webmail.cs.tcd.ie> From: "Santosh Chokhani" To: Cc: "Denis Pinkas" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l9NBF8Vv035025 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It is a bit worse than that. This has become our Autumn Ritual since 2004. May be we should make a movie on this "Same Time, Same Place, Same Debate Next Year" -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of stephen.farrell@cs.tcd.ie Sent: Tuesday, October 23, 2007 5:43 AM To: Santosh Chokhani Cc: Denis Pinkas; ietf-pkix@imc.org Subject: RE: New Liaison Statement, "Liaison to IETF on the resolution of DR320" As pointed out, we discussed this some time ago and ended up with the current 3280bis text. Repeating the arguments will only consume cycles. Stephen. 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 l9N9h7UB025378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Oct 2007 02:43:07 -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 l9N9h7rn025377; Tue, 23 Oct 2007 02:43:07 -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 smtp.cs.tcd.ie (relay.cs.tcd.ie [134.226.32.56]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9N9h14T025369 for ; Tue, 23 Oct 2007 02:43:03 -0700 (MST) (envelope-from stephen.farrell@cs.tcd.ie) Received: from localhost (localhost [127.0.0.1]) by relay.cs.tcd.ie (Postfix) with ESMTP id 26DD438BB; Tue, 23 Oct 2007 10:43:00 +0100 (IST) X-Virus-Scanned: amavisd-new at cs.tcd.ie Received: from smtp.cs.tcd.ie ([127.0.0.1]) by localhost (smtp.cs.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3CleLceDL8Q; Tue, 23 Oct 2007 10:42:59 +0100 (IST) Received: from webmail.cs.tcd.ie (wilde.cs.tcd.ie [IPv6:2001:770:10:200:203:baff:fe96:d2b3]) by smtp.cs.tcd.ie (Postfix) with ESMTP id F15CA384D; Tue, 23 Oct 2007 10:42:51 +0100 (IST) Received: from 195.56.169.116 (SquirrelMail authenticated user sfarrel6) by webmail.cs.tcd.ie with HTTP; Tue, 23 Oct 2007 10:42:59 +0100 (IST) Message-ID: <50643.195.56.169.116.1193132579.squirrel@webmail.cs.tcd.ie> In-Reply-To: <82D5657AE1F54347A734BDD33637C879098EBEB1@EXVS01.ex.dslextreme.net> References: <82D5657AE1F54347A734BDD33637C879098EBEB1@EXVS01.ex.dslextreme.net> Date: Tue, 23 Oct 2007 10:42:59 +0100 (IST) Subject: RE: New Liaison Statement, "Liaison to IETF on the resolution of DR320" From: stephen.farrell@cs.tcd.ie To: "Santosh Chokhani" Cc: "Denis Pinkas" , ietf-pkix@imc.org Reply-To: stephen.farrell@cs.tcd.ie User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As pointed out, we discussed this some time ago and ended up with the current 3280bis text. Repeating the arguments will only consume cycles. Stephen. 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 l9N0BrEn081980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2007 17:11:53 -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 l9N0Bq7A081979; Mon, 22 Oct 2007 17:11:52 -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 elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9N0BoeN081951 for ; Mon, 22 Oct 2007 17:11:51 -0700 (MST) (envelope-from hoytkesterson@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ACQ+pWxKv+MMWTNHLE0AZGWYL+XS6Qj0NPMnZh5srxPyASRMKzRqViKN1FC4qR83; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.53] (helo=elwamui-wigeon.atl.sa.earthlink.net) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Ik7N7-0003vL-Pg; Mon, 22 Oct 2007 20:11:50 -0400 Received: from 143.192.1.185 by webmail.pas.earthlink.net with HTTP; Mon, 22 Oct 2007 20:11:49 -0400 Message-ID: <12352707.1193098309804.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net> Date: Mon, 22 Oct 2007 20:11:49 -0400 (EDT) From: Hoyt L Kesterson II Reply-To: Hoyt L Kesterson II To: ietf-pkix@imc.org Subject: Re: New Liaison Statement, Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 59f3edefb26af0321a6f9084d36cbc6474bf435c0eb9d478100f810b5c66a19032c6ea75cad3e433297c17fac106dbbb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.53 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The ITU is not in disagreement. Its Study Group Plenary sent the IETF (not just PKIX) a liaison stating that it had rejected DR 320. It believes that the problems described by DR 320 would not exist if the concept of unambiguous naming is followed as described in the standard. It believes that if such a problem exists, those environments that permit such duplicate naming should address the problem. If the IETF feels that the problem need not be addressed for whatever reason, then the IETF can respond with that position. I only advise that "words fail me" would not be an understandable response to the folks back in Geneva. hoyt -----Original Message----- >From: Paul Hoffman >Sent: Oct 22, 2007 7:16 PM >To: Denis Pinkas , "ietf-pkix@imc.org" >Cc: Russ Housley >Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution of DR320" > > >At 1:52 PM +0200 10/22/07, Denis Pinkas wrote: >>I agree with what you say. However", Words fail me" may have >>multiple interpretations. >>We are going to invent a mechanism to prevent conflict, e.g. a list >>of existing CA >>names that deployers of new CAs could check for naming conflicts. > >When you say "We", if you mean the IETF, then, yes, you have indeed >gotten the wrong sense of my statement. > >>The implications are that DR 320 has been rejected by the directory >>group on a wrong basis. > >It would be unwise for the PKIX WG to get embroiled in the ITU's >disagreements here. We should wait for a clear statement from them >about what they believe is their response to the issue, then we can >work with that. > >--Paul Hoffman, Director >--VPN Consortium > 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 l9MNIHjr078959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2007 16:18:17 -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 l9MNIHKP078958; Mon, 22 Oct 2007 16:18:17 -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 [165.227.249.203] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9MNHfUd078933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2007 16:17:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 22 Oct 2007 16:16:09 -0700 To: "Denis Pinkas" , "ietf-pkix@imc.org" From: Paul Hoffman Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution of DR320" Cc: "Russ Housley" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 1:52 PM +0200 10/22/07, Denis Pinkas wrote: >I agree with what you say. However", Words fail me" may have >multiple interpretations. >We are going to invent a mechanism to prevent conflict, e.g. a list >of existing CA >names that deployers of new CAs could check for naming conflicts. When you say "We", if you mean the IETF, then, yes, you have indeed gotten the wrong sense of my statement. >The implications are that DR 320 has been rejected by the directory >group on a wrong basis. It would be unwise for the PKIX WG to get embroiled in the ITU's disagreements here. We should wait for a clear statement from them about what they believe is their response to the issue, then we can work with that. --Paul Hoffman, Director --VPN Consortium 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 l9MLhrai071577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2007 14:43:53 -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 l9MLhrYH071576; Mon, 22 Oct 2007 14:43:53 -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 l9MLhoku071567 for ; Mon, 22 Oct 2007 14:43:50 -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="utf-8" Subject: RE: New Liaison Statement, "Liaison to IETF on the resolution of DR320" Date: Mon, 22 Oct 2007 14:43:39 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C879098EBEB1@EXVS01.ex.dslextreme.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Liaison Statement, "Liaison to IETF on the resolution of DR320" thread-index: AcgUu9IEbsO12Gd2RuqXfdVK2x2/lwAFxXjA References: From: "Santosh Chokhani" To: "Denis Pinkas" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by balder-227.proper.com id l9MLhoku071569 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis, I am not sure you and I should be discussing this on the mail list, if the goal of our effort is to facilitate consensus. Last time we did that, we put people to sleep. It is time for others to comment on the topic. I know we are trying to fill a security hole using technical means as opposed to assuming that there are no CA name collisions. As to my proposal, it calls for an exact match of DNs in the certification path, but accounts for self-issued certificates due to CA re-key. I encourage you to look at the detailed briefing presented at PKIX Fall 2004. I assume it is still available via IETF. As to the paper presented at NIST 2005 Research Conference, it is actually NIST 2006 Research Conference. The URL is provided below. This also has been posted on PKIX before. The briefing (NIST workshop, not IETF) is at: http://middleware.internet2.edu/pki06/proceedings/ The full paper is at: http://csrc.nist.gov/publications/nistir/ir-7313/NIST-IR-7313_Final.pdf -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Denis Pinkas Sent: Monday, October 22, 2007 9:37 AM To: ietf-pkix@imc.org Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution of DR320" Santosh, >We have been down this route before. >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, Unless the client software knows by "other means" what to do, this is the default way to make the whole system secure. > we make sure that we ensure that the paths begin at the same trust anchor. This helps, but it is fra from sufficient. > 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. Reducing the risk does not suppress it. > 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. "Constraining" does not mean "identical". Would you be more precise ? > The primary reason to not adopt my suggestion is that it requires change to client software. Since most of the clients are insecure today in case of a DN name collision, it is time to fix it. >Also see our paper in NIST PKI Research Workshop in 2005 for a discussion of this. Would you have a link ? Denis >-----Original Message----- >From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Denis Pinkas >Sent: Monday, October 22, 2007 7:58 AM >To: ietf-pkix@imc.org >Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution of DR320" > > >Russ said: > >>It seems to me that this is a trust anchor configuration concern. > >Not only. > >> If two CAs adopt the same name and a user accepts both of these CAs as >>trust anchors, then there could be a problem. Just don't do it. > >This is correct, but insufficient. This does not prevent two CAs somewhere >under this trust anchor to use the same name in different branches. > >>RFC 3280bis says: > >> While X.509 mandates that names be unambiguous, there is a risk that >> two unrelated authorities will issue certificates and/or CRLs under >> the same issuer name. > >This is correct. This sentence contradicts the response to DR 320. > >> As a means of reducing problems and security >> issues related to issuer name collisions, CA and CRL issuer names >> SHOULD be formed in a way that reduces the likelihood of name >> collisions. > >This recommandation does not *prevent* "problems and security issues". >This sentence should be deleted or changed. > >> Implementers should take into account the possible >> existence of multiple unrelated CAs and CRL issuers with the same >> name. > >This is fully correct. > >> At a minimum, implementations validating CRLs MUST ensure that >> the certification path of a certificate and the CRL issuer >> certification path used to validate the certificate terminate at the >> same trust anchor. > >This "minimum" clause is both insufficient and insecure. >This sentence gives a false sense of security. > >This means that RFC3280bis currently provides no coorect guidance >on how implementers should address this issue. > >The following text is an attempt to address this issue: > >"Implementations validating indirect CRLs MUST make sure that the >certificate of the CRL Issuer is indeed issued by the CA that issued >the certificate to be verified, which means that the sequence of DNs >of the certification path of the CRL issuer, up to the DN of a trust anchor, >must be identical to the the sequence of DNs of the certification path >of the certificate to be verified, up to the DN of the same trust anchor". > >Denis > >>Russ >> >>At 08:12 AM 10/5/2007, ITU-T SG 17 wrote: >> >>>Title: Liaison to IETF on the resolution of DR320 >>>Submission Date: 2007-10-05 >>>URL of the IETF Web page: >>>https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=375 >>>Please reply by 2008-03-01 >>> >>>From: Xiaoya Yang(ITU-T SG 17) >>>To: IETF/PKIX(Russ Housley , Stefan Santesson >>>) >>>Cc: Herbert Bertine >>> >>> >>> >>>Reponse Contact: Xiaoya YANG >>> >>>Technical Contact: >>> >>>Purpose: For action >>>Body: At our recent ITU-T SG17 meeting in Geneva we discussed and >>>rejected Defect Report 320 >>>(http://www.x500standard.com/uploads/Defects/DR_320.pdf) from >>>AFNOR. This DR advanced an argument that Distinguished Names may >>>not be unique and as such, the DN of the Certificate User may not be unique. >>>The directory group believes that Distinguished Name values must be >>>unique and unambiguously identify a single entity, hence the use of >>>the term Distinguished. >>>The DR states â€œthe DN of the issuer name cannot be guaranteed to >>>be uniqueâ€. X.509 takes its definition of DN from X.501. Clause >>>9.2 of X.501 specifies the definition of DistinguishedName. This >>>clause states A name shall be unambiguous, that is, denotes just one object. >>>Clause 9 goes on to state: It is the responsibility of the relevant >>>naming authority for an entry to ensure that this is so by >>>appropriately assigning distinguished attribute values. Allocation >>>of RDNs is considered an administrative undertaking that may or may >>>not require some negotiation between involved organizations or >>>administrations. This Directory Specification does not provide such >>>a negotiation mechanism, and makes no assumption as to how it is performed. >>>The standard takes an axiomatic view of the concept that a >>>distinguished name unambiguously identifies a single entity. Things >>>break if two entities identify themselves using the same name. We >>>don't let two entities have the same domain name or the same email >>>address. Why? - because things wouldn't work. >>>The directory group does not accept the DRâ€™s basic argument. We >>>believe that if two entities present the same name and a CA issues a >>>certificate to each, that CA made a mistake - not a naming authority >>>mistake, since a CA is not an naming authority (although one entity >>>can be both), but an entity to key binding mistake that leads to >>>confusion and even worse, a security risk. >>>We believe that if two entities claim the same name as top level >>>CAs, there is a political/procedural breakdown much like the domain >>>ownership arguments we have seen. No one argues that the Internet >>>protocols should be modified to solve that problem. The conflict is >>>resolved and one entity is assigned the name. The group believes >>>that this is the only reasonable solution for Distinguished >>>Naming. One votes for the CA of choice by configuring it as an anchor. >>>One of the participants in the directory meeting stated that >>>Certification Authorities are being deployed with names not acquired >>>from naming authorities but with names arbitrarily chosen assuming >>>that no other CA is or will be operating under that name. That >>>participant further stated that the IETF provides no guidelines on >>>ensuring that the names of CAs are unambiguous. >>>The directory group requests the IETF PKIX group to comment on this >>>statement. If the statement is correct, we ask the IETF to consider >>>putting a mechanism in place to prevent conflict, e.g. a list of >>>existing CA names that deployers of new CAs could check for naming conflicts. >>>Attachment(s): >>>No document has been attached >> > >Regards, > >Denis Pinkas > > Regards, Denis Pinkas 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 l9MHfUFa047087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2007 10:41:30 -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 l9MHfUUG047086; Mon, 22 Oct 2007 10:41:30 -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 l9MHfRwU047077 for ; Mon, 22 Oct 2007 10:41:30 -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: Mon, 22 Oct 2007 10:41:10 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C8790987D7E4@EXVS01.ex.dslextreme.net> In-Reply-To: <20071022143330.GQ4999@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: AcgUwnff3lW8VmZOQoeRcmJP01PqnAAD/cfQ References: <82D5657AE1F54347A734BDD33637C8790987D3BC@EXVS01.ex.dslextreme.net> <20071022143330.GQ4999@mars.cry.pto> From: "Santosh Chokhani" To: "Julien Stern" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l9MHfUwU047081 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 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 l9MHaVde046714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2007 10:36:31 -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 l9MHaVle046713; Mon, 22 Oct 2007 10:36:31 -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 smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9MHaTIe046703 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 22 Oct 2007 10:36:30 -0700 (MST) (envelope-from stefans@microsoft.com) Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.222.3; Mon, 22 Oct 2007 18:36:28 +0100 Received: from EA-EXMSG-C320.europe.corp.microsoft.com ([65.53.221.77]) by dub-exhub-c302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Mon, 22 Oct 2007 18:36:27 +0100 From: Stefan Santesson To: "ietf-pkix@imc.org" Date: Mon, 22 Oct 2007 18:36:23 +0100 Subject: Call for agenda items - Vancouver IETF Thread-Topic: Call for agenda items - Vancouver IETF Thread-Index: AcgU0hCHXWJbPwVPT7+3o4MRnK6r3w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E75F200AF1718F45B2024A88C3141A1D0647534474EAEXMSGC320eu_" MIME-Version: 1.0 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --_000_E75F200AF1718F45B2024A88C3141A1D0647534474EAEXMSGC320eu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Vancouver IETF is coming up. Please send me requests for agenda slots. As usual I would appreciate if editors of current documents let me know if = they want a slot and their assessment of the current status. I would appreciate requests to be sent to me as soon as possible and at lat= est Friday November 2nd. Thank you. Stefan Santesson Senior Program Manager Windows Security, Standards --_000_E75F200AF1718F45B2024A88C3141A1D0647534474EAEXMSGC320eu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Vancouver IETF is coming up.

Please send me requests for agenda = slots.

As usual I would appreciate if edit= ors of current documents let me know if they want a slot and their assessment of t= he current status.

I would appreciate requests to be s= ent to me as soon as possible and at latest Friday November 2^nd.

Thank you.

Stefan Santesson

Senior Program Manager=

Windows Security, Standards<= span lang=3DEN-US style=3D'color:#1F497D'>

--_000_E75F200AF1718F45B2024A88C3141A1D0647534474EAEXMSGC320eu_-- 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 l9MEtnDG028726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2007 07:55:49 -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 l9MEtn8n028725; Mon, 22 Oct 2007 07:55:49 -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 odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9MEtk4l028715 for ; Mon, 22 Oct 2007 07:55:48 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-mcl1.frcl.bull.fr [129.184.87.20]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA69048 for ; Mon, 22 Oct 2007 17:03:12 +0200 Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2007102216551528:174750 ; Mon, 22 Oct 2007 16:55:15 +0200 Date: Mon, 22 Oct 2007 16:55:12 +0200 From: "Denis Pinkas" To: "ietf-pkix@imc.org" Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution of DR320" X-mailer: Foxmail 5.0 [-fr-] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 22/10/2007 16:55:15, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 22/10/2007 16:55:46, Serialize complete at 22/10/2007 16:55:46 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by balder-227.proper.com id l9MEtn4l028720 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >Denis, > >As you might have seen from some of my old posting on the list, >I initially believed that there was a true "security flaw" in X.509 >regarding revocation. > >Now, my understanding is that the fact there is no name >collision is an _assumption_ in X.509. No name collision is simply an invalid assumption. >If one wants to cope with name collisions there are several >routes one can take depending on what the "adversary" is and >the constraint one wants to put on the PKI topology. > >1) The first one is simply to assume that it can be detected >and fixed. It can't. >2) One can cope with "accidental" name collision: I believe that is >the route currently taken by PKIX by mandating trust anchor matching. Same trust anchor is insufiicient. >3) Your proposed wording copes with less accidental and more malicious >attacks. It addresses the general case. > I believe this is in the same spirit as Santosh Chokani >proposal in 2004, (isn't it ?). No. Santosh was certainly mandating the same trust anchor, but this is not sufficient. But I let Santosh explains. > However, it restricts the PKI topology and It does not. >I believe it is still open to some exotic attacts (see my posting from >early November 2004). I do not recall that you have explained an attack on that scheme. >4) One can put even more restrictions on the PKI topology by mandating >that a CA signs the CRL issuer keys with an explicit "CRL issuer" extension >(similar to OCSP) and that the AuthorityKeyExtension (containing the >hash of the key) be explicitely checked during the path building. The AuthorityKeyExtension is not done for this. >All in all, I believe it is close to impossible to define a general rule >in the standard because some core assumptions regarding the uniqueness >of the DNs and the adversarial model may not be the same between >different PKIs. It is possible to define a default rule. Remember: A DN issued by one CA is unique for that CA, but for that CA only. Only a chain of DNs may be unique, starting from a trust anchor. which means, as Russ noticed, that it is not allowed to have two different roots in a validation policy (or a signature policy) with the same DN. Denis >Regards, > >-- >Julien > >On Mon, Oct 22, 2007 at 03:16:32PM +0200, Denis Pinkas wrote: >> >> Julien, >> >> >On Mon, Oct 22, 2007 at 01:57:33PM +0200, Denis Pinkas wrote: >> >> >> >> [snip] >> > >> >Hi Denis, >> > >> >> This means that RFC3280bis currently provides no coorect guidance >> >> on how implementers should address this issue. >> > >> >Agreed. There is a somewhat "matter of local policy-ish" issue here. >> > >> >> The following text is an attempt to address this issue: >> >> >> >> "Implementations validating indirect CRLs MUST make sure that the >> >> certificate of the CRL Issuer is indeed issued by the CA that issued >> >> the certificate to be verified, which means that the sequence of DNs >> >> of the certification path of the CRL issuer, up to the DN of a trust anchor, >> >> must be identical to the the sequence of DNs of the certification path >> >> of the certificate to be verified, up to the DN of the same trust anchor". >> > >> >Forcing the CA to directly issue the CRL issuer certificate is way too >> >restrictive in my humble opinion. I have an example of a PKI where there >> >is a single (indirect) CRL issuer for about 20 CAs. >> > >> >The CRL issuer certificate is issued by the (Root) CA that issued >> >those 20 CA certificates. >> >> What about: >> >> Unless a local policy states otherwise, implementations validating indirect CRLs >> MUST make sure that the certificate of the CRL Issuer is indeed issued by the CA >> that issued the certificate to be verified, which means that the sequence of DNs >> of the certification path of the CRL issuer, up to the DN of a trust anchor, >> must be identical to the the sequence of DNs of the certification path >> of the certificate to be verified, up to the DN of the same trust anchor". >> >> Denis >> >> >Regards, >> > >> >-- >> >Julien >> > >> >> Denis >> >> >> >> >Russ >> >> > >> >> >At 08:12 AM 10/5/2007, ITU-T SG 17 wrote: >> >> > >> >> >>Title: Liaison to IETF on the resolution of DR320 >> >> >>Submission Date: 2007-10-05 >> >> >>URL of the IETF Web page: >> >> >>https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=375 >> >> >>Please reply by 2008-03-01 >> >> >> >> >> >>From: Xiaoya Yang(ITU-T SG 17) >> >> >>To: IETF/PKIX(Russ Housley , Stefan Santesson >> >> >>) >> >> >>Cc: Herbert Bertine >> >> >> >> >> >> >> >> >> >> >> >>Reponse Contact: Xiaoya YANG >> >> >> >> >> >>Technical Contact: >> >> >> >> >> >>Purpose: For action >> >> >>Body: At our recent ITU-T SG17 meeting in Geneva we discussed and >> >> >>rejected Defect Report 320 >> >> >>(http://www.x500standard.com/uploads/Defects/DR_320.pdf) from >> >> >>AFNOR. This DR advanced an argument that Distinguished Names may >> >> >>not be unique and as such, the DN of the Certificate User may not be unique. >> >> >>The directory group believes that Distinguished Name values must be >> >> >>unique and unambiguously identify a single entity, hence the use of >> >> >>the term Distinguished. >> >> >>The DR states “the DN of the issuer name cannot be guaranteed to >> >> >>be unique”. X.509 takes its definition of DN from X.501. Clause >> >> >>9.2 of X.501 specifies the definition of DistinguishedName. This >> >> >>clause states A name shall be unambiguous, that is, denotes just one object. >> >> >>Clause 9 goes on to state: It is the responsibility of the relevant >> >> >>naming authority for an entry to ensure that this is so by >> >> >>appropriately assigning distinguished attribute values. Allocation >> >> >>of RDNs is considered an administrative undertaking that may or may >> >> >>not require some negotiation between involved organizations or >> >> >>administrations. This Directory Specification does not provide such >> >> >>a negotiation mechanism, and makes no assumption as to how it is performed. >> >> >>The standard takes an axiomatic view of the concept that a >> >> >>distinguished name unambiguously identifies a single entity. Things >> >> >>break if two entities identify themselves using the same name. We >> >> >>don't let two entities have the same domain name or the same email >> >> >>address. Why? - because things wouldn't work. >> >> >>The directory group does not accept the DR’s basic argument. We >> >> >>believe that if two entities present the same name and a CA issues a >> >> >>certificate to each, that CA made a mistake - not a naming authority >> >> >>mistake, since a CA is not an naming authority (although one entity >> >> >>can be both), but an entity to key binding mistake that leads to >> >> >>confusion and even worse, a security risk. >> >> >>We believe that if two entities claim the same name as top level >> >> >>CAs, there is a political/procedural breakdown much like the domain >> >> >>ownership arguments we have seen. No one argues that the Internet >> >> >>protocols should be modified to solve that problem. The conflict is >> >> >>resolved and one entity is assigned the name. The group believes >> >> >>that this is the only reasonable solution for Distinguished >> >> >>Naming. One votes for the CA of choice by configuring it as an anchor. >> >> >>One of the participants in the directory meeting stated that >> >> >>Certification Authorities are being deployed with names not acquired >> >> >>from naming authorities but with names arbitrarily chosen assuming >> >> >>that no other CA is or will be operating under that name. That >> >> >>participant further stated that the IETF provides no guidelines on >> >> >>ensuring that the names of CAs are unambiguous. >> >> >>The directory group requests the IETF PKIX group to comment on this >> >> >>statement. If the statement is correct, we ask the IETF to consider >> >> >>putting a mechanism in place to prevent conflict, e.g. a list of >> >> >>existing CA names that deployers of new CAs could check for naming conflicts. >> >> >>Attachment(s): >> >> >>No document has been attached >> >> > Regards, Denis Pinkas 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 l9MEXdJZ025950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2007 07:33:39 -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 l9MEXd5T025949; Mon, 22 Oct 2007 07:33:39 -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 kraid.nerim.net (smtp-101-monday.nerim.net [62.4.16.101]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9MEXbdY025941 for ; Mon, 22 Oct 2007 07:33:38 -0700 (MST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog2.pck.nerim.net [213.41.184.9]) by kraid.nerim.net (Postfix) with ESMTP id 0902BCF0CE for ; Mon, 22 Oct 2007 16:33:37 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 13C8D4428C for ; Mon, 22 Oct 2007 16:33:37 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at cryptolog.com Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus.cry.pto [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEhfP+H9zqdQ for ; Mon, 22 Oct 2007 16:33:31 +0200 (CEST) Received: from mars.cry.pto (isonoe.cry.pto [10.0.1.15]) by uranus.cry.pto (Postfix) with SMTP id 6726744006 for ; Mon, 22 Oct 2007 16:33:30 +0200 (CEST) Received: by mars.cry.pto (sSMTP sendmail emulation); Mon, 22 Oct 2007 16:33:30 +0200 From: "Julien Stern" Date: Mon, 22 Oct 2007 16:33:30 +0200 To: ietf-pkix@imc.org Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution of DR320" Message-ID: <20071022143330.GQ4999@mars.cry.pto> Mail-Followup-To: Julien Stern , ietf-pkix@imc.org References: <82D5657AE1F54347A734BDD33637C8790987D3BC@EXVS01.ex.dslextreme.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82D5657AE1F54347A734BDD33637C8790987D3BC@EXVS01.ex.dslextreme.net> User-Agent: Mutt/1.5.13 (2006-08-11) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 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 l9MELUn9023305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2007 07:21:31 -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 l9MELUUE023304; Mon, 22 Oct 2007 07:21:30 -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 kraid.nerim.net (smtp-101-monday.nerim.net [62.4.16.101]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9MELTfj023283 for ; Mon, 22 Oct 2007 07:21:29 -0700 (MST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog2.pck.nerim.net [213.41.184.9]) by kraid.nerim.net (Postfix) with ESMTP id E324ACF0E7 for ; Mon, 22 Oct 2007 16:21:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id EEE954428C for ; Mon, 22 Oct 2007 16:21:27 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at cryptolog.com Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus.cry.pto [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43sPUcKST8h7 for ; Mon, 22 Oct 2007 16:21:23 +0200 (CEST) Received: from mars.cry.pto (isonoe.cry.pto [10.0.1.15]) by uranus.cry.pto (Postfix) with SMTP id 91BC144006 for ; Mon, 22 Oct 2007 16:21:22 +0200 (CEST) Received: by mars.cry.pto (sSMTP sendmail emulation); Mon, 22 Oct 2007 16:21:22 +0200 From: "Julien Stern" Date: Mon, 22 Oct 2007 16:21:22 +0200 To: "ietf-pkix@imc.org" Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution of DR320" Message-ID: <20071022142122.GP4999@mars.cry.pto> Mail-Followup-To: Julien Stern , "ietf-pkix@imc.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis, As you might have seen from some of my old posting on the list, I initially believed that there was a true "security flaw" in X.509 regarding revocation. Now, my understanding is that the fact there is no name collision is an _assumption_ in X.509. If one wants to cope with name collisions there are several routes one can take depending on what the "adversary" is and the constraint one wants to put on the PKI topology. 1) The first one is simply to assume that it can be detected and fixed. 2) One can cope with "accidental" name collision: I believe that is the route currently taken by PKIX by mandating trust anchor matching. 3) Your proposed wording copes with less accidental and more malicious attacks. I believe this is in the same spirit as Santosh Chokani proposal in 2004, (isn't it ?). However, it restricts the PKI topology and I believe it is still open to some exotic attacts (see my posting from early November 2004). 4) One can put even more restrictions on the PKI topology by mandating that a CA signs the CRL issuer keys with an explicit "CRL issuer" extension (similar to OCSP) and that the AuthorityKeyExtension (containing the hash of the key) be explicitely checked during the path building. All in all, I believe it is close to impossible to define a general rule in the standard because some core assumptions regarding the uniqueness of the DNs and the adversarial model may not be the same between different PKIs. Regards, -- Julien On Mon, Oct 22, 2007 at 03:16:32PM +0200, Denis Pinkas wrote: > > Julien, > > >On Mon, Oct 22, 2007 at 01:57:33PM +0200, Denis Pinkas wrote: > >> > >> [snip] > > > >Hi Denis, > > > >> This means that RFC3280bis currently provides no coorect guidance > >> on how implementers should address this issue. > > > >Agreed. There is a somewhat "matter of local policy-ish" issue here. > > > >> The following text is an attempt to address this issue: > >> > >> "Implementations validating indirect CRLs MUST make sure that the > >> certificate of the CRL Issuer is indeed issued by the CA that issued > >> the certificate to be verified, which means that the sequence of DNs > >> of the certification path of the CRL issuer, up to the DN of a trust anchor, > >> must be identical to the the sequence of DNs of the certification path > >> of the certificate to be verified, up to the DN of the same trust anchor". > > > >Forcing the CA to directly issue the CRL issuer certificate is way too > >restrictive in my humble opinion. I have an example of a PKI where there > >is a single (indirect) CRL issuer for about 20 CAs. > > > >The CRL issuer certificate is issued by the (Root) CA that issued > >those 20 CA certificates. > > What about: > > Unless a local policy states otherwise, implementations validating indirect CRLs > MUST make sure that the certificate of the CRL Issuer is indeed issued by the CA > that issued the certificate to be verified, which means that the sequence of DNs > of the certification path of the CRL issuer, up to the DN of a trust anchor, > must be identical to the the sequence of DNs of the certification path > of the certificate to be verified, up to the DN of the same trust anchor". > > Denis > > >Regards, > > > >-- > >Julien > > > >> Denis > >> > >> >Russ > >> > > >> >At 08:12 AM 10/5/2007, ITU-T SG 17 wrote: > >> > > >> >>Title: Liaison to IETF on the resolution of DR320 > >> >>Submission Date: 2007-10-05 > >> >>URL of the IETF Web page: > >> >>https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=375 > >> >>Please reply by 2008-03-01 > >> >> > >> >>From: Xiaoya Yang(ITU-T SG 17) > >> >>To: IETF/PKIX(Russ Housley , Stefan Santesson > >> >>) > >> >>Cc: Herbert Bertine > >> >> > >> >> > >> >> > >> >>Reponse Contact: Xiaoya YANG > >> >> > >> >>Technical Contact: > >> >> > >> >>Purpose: For action > >> >>Body: At our recent ITU-T SG17 meeting in Geneva we discussed and > >> >>rejected Defect Report 320 > >> >>(http://www.x500standard.com/uploads/Defects/DR_320.pdf) from > >> >>AFNOR. This DR advanced an argument that Distinguished Names may > >> >>not be unique and as such, the DN of the Certificate User may not be unique. > >> >>The directory group believes that Distinguished Name values must be > >> >>unique and unambiguously identify a single entity, hence the use of > >> >>the term Distinguished. > >> >>The DR states “the DN of the issuer name cannot be guaranteed to > >> >>be unique”. X.509 takes its definition of DN from X.501. Clause > >> >>9.2 of X.501 specifies the definition of DistinguishedName. This > >> >>clause states A name shall be unambiguous, that is, denotes just one object. > >> >>Clause 9 goes on to state: It is the responsibility of the relevant > >> >>naming authority for an entry to ensure that this is so by > >> >>appropriately assigning distinguished attribute values. Allocation > >> >>of RDNs is considered an administrative undertaking that may or may > >> >>not require some negotiation between involved organizations or > >> >>administrations. This Directory Specification does not provide such > >> >>a negotiation mechanism, and makes no assumption as to how it is performed. > >> >>The standard takes an axiomatic view of the concept that a > >> >>distinguished name unambiguously identifies a single entity. Things > >> >>break if two entities identify themselves using the same name. We > >> >>don't let two entities have the same domain name or the same email > >> >>address. Why? - because things wouldn't work. > >> >>The directory group does not accept the DR’s basic argument. We > >> >>believe that if two entities present the same name and a CA issues a > >> >>certificate to each, that CA made a mistake - not a naming authority > >> >>mistake, since a CA is not an naming authority (although one entity > >> >>can be both), but an entity to key binding mistake that leads to > >> >>confusion and even worse, a security risk. > >> >>We believe that if two entities claim the same name as top level > >> >>CAs, there is a political/procedural breakdown much like the domain > >> >>ownership arguments we have seen. No one argues that the Internet > >> >>protocols should be modified to solve that problem. The conflict is > >> >>resolved and one entity is assigned the name. The group believes > >> >>that this is the only reasonable solution for Distinguished > >> >>Naming. One votes for the CA of choice by configuring it as an anchor. > >> >>One of the participants in the directory meeting stated that > >> >>Certification Authorities are being deployed with names not acquired > >> >>from naming authorities but with names arbitrarily chosen assuming > >> >>that no other CA is or will be operating under that name. That > >> >>participant further stated that the IETF provides no guidelines on > >> >>ensuring that the names of CAs are unambiguous. > >> >>The directory group requests the IETF PKIX group to comment on this > >> >>statement. If the statement is correct, we ask the IETF to consider > >> >>putting a mechanism in place to prevent conflict, e.g. a list of > >> >>existing CA names that deployers of new CAs could check for naming conflicts. > >> >>Attachment(s): > >> >>No document has been attached > > 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 l9MDbcpG017855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2007 06:37:38 -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 l9MDbcVP017854; Mon, 22 Oct 2007 06:37:38 -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 odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9MDbWip017829 for ; Mon, 22 Oct 2007 06:37:36 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-mcl1.frcl.bull.fr [129.184.87.20]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA57722 for ; Mon, 22 Oct 2007 15:44:57 +0200 Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2007102215371323:172571 ; Mon, 22 Oct 2007 15:37:13 +0200 Date: Mon, 22 Oct 2007 15:37:09 +0200 From: "Denis Pinkas" To: "ietf-pkix@imc.org" Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution of DR320" X-mailer: Foxmail 5.0 [-fr-] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 22/10/2007 15:37:13, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 22/10/2007 15:37:31, Serialize complete at 22/10/2007 15:37:31 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by balder-227.proper.com id l9MDbcip017849 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Santosh, >We have been down this route before. >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, Unless the client software knows by "other means" what to do, this is the default way to make the whole system secure. > we make sure that we ensure that the paths begin at the same trust anchor. This helps, but it is fra from sufficient. > 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. Reducing the risk does not suppress it. > 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. "Constraining" does not mean "identical". Would you be more precise ? > The primary reason to not adopt my suggestion is that it requires change to client software. Since most of the clients are insecure today in case of a DN name collision, it is time to fix it. >Also see our paper in NIST PKI Research Workshop in 2005 for a discussion of this. Would you have a link ? Denis >-----Original Message----- >From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Denis Pinkas >Sent: Monday, October 22, 2007 7:58 AM >To: ietf-pkix@imc.org >Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution of DR320" > > >Russ said: > >>It seems to me that this is a trust anchor configuration concern. > >Not only. > >> If two CAs adopt the same name and a user accepts both of these CAs as >>trust anchors, then there could be a problem. Just don't do it. > >This is correct, but insufficient. This does not prevent two CAs somewhere >under this trust anchor to use the same name in different branches. > >>RFC 3280bis says: > >> While X.509 mandates that names be unambiguous, there is a risk that >> two unrelated authorities will issue certificates and/or CRLs under >> the same issuer name. > >This is correct. This sentence contradicts the response to DR 320. > >> As a means of reducing problems and security >> issues related to issuer name collisions, CA and CRL issuer names >> SHOULD be formed in a way that reduces the likelihood of name >> collisions. > >This recommandation does not *prevent* "problems and security issues". >This sentence should be deleted or changed. > >> Implementers should take into account the possible >> existence of multiple unrelated CAs and CRL issuers with the same >> name. > >This is fully correct. > >> At a minimum, implementations validating CRLs MUST ensure that >> the certification path of a certificate and the CRL issuer >> certification path used to validate the certificate terminate at the >> same trust anchor. > >This "minimum" clause is both insufficient and insecure. >This sentence gives a false sense of security. > >This means that RFC3280bis currently provides no coorect guidance >on how implementers should address this issue. > >The following text is an attempt to address this issue: > >"Implementations validating indirect CRLs MUST make sure that the >certificate of the CRL Issuer is indeed issued by the CA that issued >the certificate to be verified, which means that the sequence of DNs >of the certification path of the CRL issuer, up to the DN of a trust anchor, >must be identical to the the sequence of DNs of the certification path >of the certificate to be verified, up to the DN of the same trust anchor". > >Denis > >>Russ >> >>At 08:12 AM 10/5/2007, ITU-T SG 17 wrote: >> >>>Title: Liaison to IETF on the resolution of DR320 >>>Submission Date: 2007-10-05 >>>URL of the IETF Web page: >>>https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=375 >>>Please reply by 2008-03-01 >>> >>>From: Xiaoya Yang(ITU-T SG 17) >>>To: IETF/PKIX(Russ Housley , Stefan Santesson >>>) >>>Cc: Herbert Bertine >>> >>> >>> >>>Reponse Contact: Xiaoya YANG >>> >>>Technical Contact: >>> >>>Purpose: For action >>>Body: At our recent ITU-T SG17 meeting in Geneva we discussed and >>>rejected Defect Report 320 >>>(http://www.x500standard.com/uploads/Defects/DR_320.pdf) from >>>AFNOR. This DR advanced an argument that Distinguished Names may >>>not be unique and as such, the DN of the Certificate User may not be unique. >>>The directory group believes that Distinguished Name values must be >>>unique and unambiguously identify a single entity, hence the use of >>>the term Distinguished. >>>The DR states “the DN of the issuer name cannot be guaranteed to >>>be unique”. X.509 takes its definition of DN from X.501. Clause >>>9.2 of X.501 specifies the definition of DistinguishedName. This >>>clause states A name shall be unambiguous, that is, denotes just one object. >>>Clause 9 goes on to state: It is the responsibility of the relevant >>>naming authority for an entry to ensure that this is so by >>>appropriately assigning distinguished attribute values. Allocation >>>of RDNs is considered an administrative undertaking that may or may >>>not require some negotiation between involved organizations or >>>administrations. This Directory Specification does not provide such >>>a negotiation mechanism, and makes no assumption as to how it is performed. >>>The standard takes an axiomatic view of the concept that a >>>distinguished name unambiguously identifies a single entity. Things >>>break if two entities identify themselves using the same name. We >>>don't let two entities have the same domain name or the same email >>>address. Why? - because things wouldn't work. >>>The directory group does not accept the DR’s basic argument. We >>>believe that if two entities present the same name and a CA issues a >>>certificate to each, that CA made a mistake - not a naming authority >>>mistake, since a CA is not an naming authority (although one entity >>>can be both), but an entity to key binding mistake that leads to >>>confusion and even worse, a security risk. >>>We believe that if two entities claim the same name as top level >>>CAs, there is a political/procedural breakdown much like the domain >>>ownership arguments we have seen. No one argues that the Internet >>>protocols should be modified to solve that problem. The conflict is >>>resolved and one entity is assigned the name. The group believes >>>that this is the only reasonable solution for Distinguished >>>Naming. One votes for the CA of choice by configuring it as an anchor. >>>One of the participants in the directory meeting stated that >>>Certification Authorities are being deployed with names not acquired >>>from naming authorities but with names arbitrarily chosen assuming >>>that no other CA is or will be operating under that name. That >>>participant further stated that the IETF provides no guidelines on >>>ensuring that the names of CAs are unambiguous. >>>The directory group requests the IETF PKIX group to comment on this >>>statement. If the statement is correct, we ask the IETF to consider >>>putting a mechanism in place to prevent conflict, e.g. a list of >>>existing CA names that deployers of new CAs could check for naming conflicts. >>>Attachment(s): >>>No document has been attached >> > >Regards, > >Denis Pinkas > > Regards, Denis Pinkas 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 l9MDIlv2015692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2007 06:18:47 -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 l9MDIlar015691; Mon, 22 Oct 2007 06:18:47 -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 l9MDIkKn015685 for ; Mon, 22 Oct 2007 06:18:46 -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="utf-8" Subject: RE: New Liaison Statement, "Liaison to IETF on the resolution of DR320" Date: Mon, 22 Oct 2007 06:18:22 -0700 Message-ID: <82D5657AE1F54347A734BDD33637C8790987D3BC@EXVS01.ex.dslextreme.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Liaison Statement, "Liaison to IETF on the resolution of DR320" thread-index: AcgUrOA/zJMTWYymSuqXK8WAICIFXAAAGv4w References: From: "Santosh Chokhani" To: "Denis Pinkas" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by balder-227.proper.com id l9MDIlKn015686 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: We have been down this route before. 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. Also see our paper in NIST PKI Research Workshop in 2005 for a discussion of this. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Denis Pinkas Sent: Monday, October 22, 2007 7:58 AM To: ietf-pkix@imc.org Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution of DR320" Russ said: >It seems to me that this is a trust anchor configuration concern. Not only. > If two CAs adopt the same name and a user accepts both of these CAs as >trust anchors, then there could be a problem. Just don't do it. This is correct, but insufficient. This does not prevent two CAs somewhere under this trust anchor to use the same name in different branches. >RFC 3280bis says: > While X.509 mandates that names be unambiguous, there is a risk that > two unrelated authorities will issue certificates and/or CRLs under > the same issuer name. This is correct. This sentence contradicts the response to DR 320. > As a means of reducing problems and security > issues related to issuer name collisions, CA and CRL issuer names > SHOULD be formed in a way that reduces the likelihood of name > collisions. This recommandation does not *prevent* "problems and security issues". This sentence should be deleted or changed. > Implementers should take into account the possible > existence of multiple unrelated CAs and CRL issuers with the same > name. This is fully correct. > At a minimum, implementations validating CRLs MUST ensure that > the certification path of a certificate and the CRL issuer > certification path used to validate the certificate terminate at the > same trust anchor. This "minimum" clause is both insufficient and insecure. This sentence gives a false sense of security. This means that RFC3280bis currently provides no coorect guidance on how implementers should address this issue. The following text is an attempt to address this issue: "Implementations validating indirect CRLs MUST make sure that the certificate of the CRL Issuer is indeed issued by the CA that issued the certificate to be verified, which means that the sequence of DNs of the certification path of the CRL issuer, up to the DN of a trust anchor, must be identical to the the sequence of DNs of the certification path of the certificate to be verified, up to the DN of the same trust anchor". Denis >Russ > >At 08:12 AM 10/5/2007, ITU-T SG 17 wrote: > >>Title: Liaison to IETF on the resolution of DR320 >>Submission Date: 2007-10-05 >>URL of the IETF Web page: >>https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=375 >>Please reply by 2008-03-01 >> >>From: Xiaoya Yang(ITU-T SG 17) >>To: IETF/PKIX(Russ Housley , Stefan Santesson >>) >>Cc: Herbert Bertine >> >> >> >>Reponse Contact: Xiaoya YANG >> >>Technical Contact: >> >>Purpose: For action >>Body: At our recent ITU-T SG17 meeting in Geneva we discussed and >>rejected Defect Report 320 >>(http://www.x500standard.com/uploads/Defects/DR_320.pdf) from >>AFNOR. This DR advanced an argument that Distinguished Names may >>not be unique and as such, the DN of the Certificate User may not be unique. >>The directory group believes that Distinguished Name values must be >>unique and unambiguously identify a single entity, hence the use of >>the term Distinguished. >>The DR states â€œthe DN of the issuer name cannot be guaranteed to >>be uniqueâ€. X.509 takes its definition of DN from X.501. Clause >>9.2 of X.501 specifies the definition of DistinguishedName. This >>clause states A name shall be unambiguous, that is, denotes just one object. >>Clause 9 goes on to state: It is the responsibility of the relevant >>naming authority for an entry to ensure that this is so by >>appropriately assigning distinguished attribute values. Allocation >>of RDNs is considered an administrative undertaking that may or may >>not require some negotiation between involved organizations or >>administrations. This Directory Specification does not provide such >>a negotiation mechanism, and makes no assumption as to how it is performed. >>The standard takes an axiomatic view of the concept that a >>distinguished name unambiguously identifies a single entity. Things >>break if two entities identify themselves using the same name. We >>don't let two entities have the same domain name or the same email >>address. Why? - because things wouldn't work. >>The directory group does not accept the DRâ€™s basic argument. We >>believe that if two entities present the same name and a CA issues a >>certificate to each, that CA made a mistake - not a naming authority >>mistake, since a CA is not an naming authority (although one entity >>can be both), but an entity to key binding mistake that leads to >>confusion and even worse, a security risk. >>We believe that if two entities claim the same name as top level >>CAs, there is a political/procedural breakdown much like the domain >>ownership arguments we have seen. No one argues that the Internet >>protocols should be modified to solve that problem. The conflict is >>resolved and one entity is assigned the name. The group believes >>that this is the only reasonable solution for Distinguished >>Naming. One votes for the CA of choice by configuring it as an anchor. >>One of the participants in the directory meeting stated that >>Certification Authorities are being deployed with names not acquired >>from naming authorities but with names arbitrarily chosen assuming >>that no other CA is or will be operating under that name. That >>participant further stated that the IETF provides no guidelines on >>ensuring that the names of CAs are unambiguous. >>The directory group requests the IETF PKIX group to comment on this >>statement. If the statement is correct, we ask the IETF to consider >>putting a mechanism in place to prevent conflict, e.g. a list of >>existing CA names that deployers of new CAs could check for naming conflicts. >>Attachment(s): >>No document has been attached > Regards, Denis Pinkas 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 l9MDHBLU015515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2007 06:17:11 -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 l9MDHBdc015514; Mon, 22 Oct 2007 06:17:11 -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 odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9MDH5Zh015494 for ; Mon, 22 Oct 2007 06:17:07 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-mcl1.frcl.bull.fr [129.184.87.20]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA35980 for ; Mon, 22 Oct 2007 15:24:31 +0200 Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2007102215163459:172002 ; Mon, 22 Oct 2007 15:16:34 +0200 Date: Mon, 22 Oct 2007 15:16:32 +0200 From: "Denis Pinkas" To: "ietf-pkix@imc.org" Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution of DR320" X-mailer: Foxmail 5.0 [-fr-] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 22/10/2007 15:16:34, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 22/10/2007 15:17:05, Serialize complete at 22/10/2007 15:17:05 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by balder-227.proper.com id l9MDHBZh015509 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Julien, >On Mon, Oct 22, 2007 at 01:57:33PM +0200, Denis Pinkas wrote: >> >> [snip] > >Hi Denis, > >> This means that RFC3280bis currently provides no coorect guidance >> on how implementers should address this issue. > >Agreed. There is a somewhat "matter of local policy-ish" issue here. > >> The following text is an attempt to address this issue: >> >> "Implementations validating indirect CRLs MUST make sure that the >> certificate of the CRL Issuer is indeed issued by the CA that issued >> the certificate to be verified, which means that the sequence of DNs >> of the certification path of the CRL issuer, up to the DN of a trust anchor, >> must be identical to the the sequence of DNs of the certification path >> of the certificate to be verified, up to the DN of the same trust anchor". > >Forcing the CA to directly issue the CRL issuer certificate is way too >restrictive in my humble opinion. I have an example of a PKI where there >is a single (indirect) CRL issuer for about 20 CAs. > >The CRL issuer certificate is issued by the (Root) CA that issued >those 20 CA certificates. What about: Unless a local policy states otherwise, implementations validating indirect CRLs MUST make sure that the certificate of the CRL Issuer is indeed issued by the CA that issued the certificate to be verified, which means that the sequence of DNs of the certification path of the CRL issuer, up to the DN of a trust anchor, must be identical to the the sequence of DNs of the certification path of the certificate to be verified, up to the DN of the same trust anchor". Denis >Regards, > >-- >Julien > >> Denis >> >> >Russ >> > >> >At 08:12 AM 10/5/2007, ITU-T SG 17 wrote: >> > >> >>Title: Liaison to IETF on the resolution of DR320 >> >>Submission Date: 2007-10-05 >> >>URL of the IETF Web page: >> >>https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=375 >> >>Please reply by 2008-03-01 >> >> >> >>From: Xiaoya Yang(ITU-T SG 17) >> >>To: IETF/PKIX(Russ Housley , Stefan Santesson >> >>) >> >>Cc: Herbert Bertine >> >> >> >> >> >> >> >>Reponse Contact: Xiaoya YANG >> >> >> >>Technical Contact: >> >> >> >>Purpose: For action >> >>Body: At our recent ITU-T SG17 meeting in Geneva we discussed and >> >>rejected Defect Report 320 >> >>(http://www.x500standard.com/uploads/Defects/DR_320.pdf) from >> >>AFNOR. This DR advanced an argument that Distinguished Names may >> >>not be unique and as such, the DN of the Certificate User may not be unique. >> >>The directory group believes that Distinguished Name values must be >> >>unique and unambiguously identify a single entity, hence the use of >> >>the term Distinguished. >> >>The DR states “the DN of the issuer name cannot be guaranteed to >> >>be unique”. X.509 takes its definition of DN from X.501. Clause >> >>9.2 of X.501 specifies the definition of DistinguishedName. This >> >>clause states A name shall be unambiguous, that is, denotes just one object. >> >>Clause 9 goes on to state: It is the responsibility of the relevant >> >>naming authority for an entry to ensure that this is so by >> >>appropriately assigning distinguished attribute values. Allocation >> >>of RDNs is considered an administrative undertaking that may or may >> >>not require some negotiation between involved organizations or >> >>administrations. This Directory Specification does not provide such >> >>a negotiation mechanism, and makes no assumption as to how it is performed. >> >>The standard takes an axiomatic view of the concept that a >> >>distinguished name unambiguously identifies a single entity. Things >> >>break if two entities identify themselves using the same name. We >> >>don't let two entities have the same domain name or the same email >> >>address. Why? - because things wouldn't work. >> >>The directory group does not accept the DR’s basic argument. We >> >>believe that if two entities present the same name and a CA issues a >> >>certificate to each, that CA made a mistake - not a naming authority >> >>mistake, since a CA is not an naming authority (although one entity >> >>can be both), but an entity to key binding mistake that leads to >> >>confusion and even worse, a security risk. >> >>We believe that if two entities claim the same name as top level >> >>CAs, there is a political/procedural breakdown much like the domain >> >>ownership arguments we have seen. No one argues that the Internet >> >>protocols should be modified to solve that problem. The conflict is >> >>resolved and one entity is assigned the name. The group believes >> >>that this is the only reasonable solution for Distinguished >> >>Naming. One votes for the CA of choice by configuring it as an anchor. >> >>One of the participants in the directory meeting stated that >> >>Certification Authorities are being deployed with names not acquired >> >>from naming authorities but with names arbitrarily chosen assuming >> >>that no other CA is or will be operating under that name. That >> >>participant further stated that the IETF provides no guidelines on >> >>ensuring that the names of CAs are unambiguous. >> >>The directory group requests the IETF PKIX group to comment on this >> >>statement. If the statement is correct, we ask the IETF to consider >> >>putting a mechanism in place to prevent conflict, e.g. a list of >> >>existing CA names that deployers of new CAs could check for naming conflicts. >> >>Attachment(s): >> >>No document has been attached 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 l9MCsB8b012038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2007 05:54:11 -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 l9MCsBZo012037; Mon, 22 Oct 2007 05:54:11 -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 mallaury.nerim.net (smtp-101-monday.noc.nerim.net [62.4.17.101]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9MCs9jL012028 for ; Mon, 22 Oct 2007 05:54:10 -0700 (MST) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog2.pck.nerim.net [213.41.184.9]) by mallaury.nerim.net (Postfix) with ESMTP id 79F9D4F3CA for ; Mon, 22 Oct 2007 14:53:54 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 5BC4E4428C for ; Mon, 22 Oct 2007 14:54:02 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at cryptolog.com Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus.cry.pto [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuQXUuKMRvNf for ; Mon, 22 Oct 2007 14:53:54 +0200 (CEST) Received: from mars.cry.pto (isonoe.cry.pto [10.0.1.15]) by uranus.cry.pto (Postfix) with SMTP id EA24B44006 for ; Mon, 22 Oct 2007 14:53:53 +0200 (CEST) Received: by mars.cry.pto (sSMTP sendmail emulation); Mon, 22 Oct 2007 14:53:53 +0200 From: "Julien Stern" Date: Mon, 22 Oct 2007 14:53:53 +0200 To: "ietf-pkix@imc.org" Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution of DR320" Message-ID: <20071022125353.GO4999@mars.cry.pto> Mail-Followup-To: Julien Stern , "ietf-pkix@imc.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, Oct 22, 2007 at 01:57:33PM +0200, Denis Pinkas wrote: > > [snip] Hi Denis, > This means that RFC3280bis currently provides no coorect guidance > on how implementers should address this issue. Agreed. There is a somewhat "matter of local policy-ish" issue here. > The following text is an attempt to address this issue: > > "Implementations validating indirect CRLs MUST make sure that the > certificate of the CRL Issuer is indeed issued by the CA that issued > the certificate to be verified, which means that the sequence of DNs > of the certification path of the CRL issuer, up to the DN of a trust anchor, > must be identical to the the sequence of DNs of the certification path > of the certificate to be verified, up to the DN of the same trust anchor". Forcing the CA to directly issue the CRL issuer certificate is way too restrictive in my humble opinion. I have an example of a PKI where there is a single (indirect) CRL issuer for about 20 CAs. The CRL issuer certificate is issued by the (Root) CA that issued those 20 CA certificates. Regards, -- Julien > Denis > > >Russ > > > >At 08:12 AM 10/5/2007, ITU-T SG 17 wrote: > > > >>Title: Liaison to IETF on the resolution of DR320 > >>Submission Date: 2007-10-05 > >>URL of the IETF Web page: > >>https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=375 > >>Please reply by 2008-03-01 > >> > >>From: Xiaoya Yang(ITU-T SG 17) > >>To: IETF/PKIX(Russ Housley , Stefan Santesson > >>) > >>Cc: Herbert Bertine > >> > >> > >> > >>Reponse Contact: Xiaoya YANG > >> > >>Technical Contact: > >> > >>Purpose: For action > >>Body: At our recent ITU-T SG17 meeting in Geneva we discussed and > >>rejected Defect Report 320 > >>(http://www.x500standard.com/uploads/Defects/DR_320.pdf) from > >>AFNOR. This DR advanced an argument that Distinguished Names may > >>not be unique and as such, the DN of the Certificate User may not be unique. > >>The directory group believes that Distinguished Name values must be > >>unique and unambiguously identify a single entity, hence the use of > >>the term Distinguished. > >>The DR states “the DN of the issuer name cannot be guaranteed to > >>be unique”. X.509 takes its definition of DN from X.501. Clause > >>9.2 of X.501 specifies the definition of DistinguishedName. This > >>clause states A name shall be unambiguous, that is, denotes just one object. > >>Clause 9 goes on to state: It is the responsibility of the relevant > >>naming authority for an entry to ensure that this is so by > >>appropriately assigning distinguished attribute values. Allocation > >>of RDNs is considered an administrative undertaking that may or may > >>not require some negotiation between involved organizations or > >>administrations. This Directory Specification does not provide such > >>a negotiation mechanism, and makes no assumption as to how it is performed. > >>The standard takes an axiomatic view of the concept that a > >>distinguished name unambiguously identifies a single entity. Things > >>break if two entities identify themselves using the same name. We > >>don't let two entities have the same domain name or the same email > >>address. Why? - because things wouldn't work. > >>The directory group does not accept the DR’s basic argument. We > >>believe that if two entities present the same name and a CA issues a > >>certificate to each, that CA made a mistake - not a naming authority > >>mistake, since a CA is not an naming authority (although one entity > >>can be both), but an entity to key binding mistake that leads to > >>confusion and even worse, a security risk. > >>We believe that if two entities claim the same name as top level > >>CAs, there is a political/procedural breakdown much like the domain > >>ownership arguments we have seen. No one argues that the Internet > >>protocols should be modified to solve that problem. The conflict is > >>resolved and one entity is assigned the name. The group believes > >>that this is the only reasonable solution for Distinguished > >>Naming. One votes for the CA of choice by configuring it as an anchor. > >>One of the participants in the directory meeting stated that > >>Certification Authorities are being deployed with names not acquired > >>from naming authorities but with names arbitrarily chosen assuming > >>that no other CA is or will be operating under that name. That > >>participant further stated that the IETF provides no guidelines on > >>ensuring that the names of CAs are unambiguous. > >>The directory group requests the IETF PKIX group to comment on this > >>statement. If the statement is correct, we ask the IETF to consider > >>putting a mechanism in place to prevent conflict, e.g. a list of > >>existing CA names that deployers of new CAs could check for naming conflicts. > >>Attachment(s): > >>No document has been attached > > > > Regards, > > Denis Pinkas > > 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 l9MC1Z9B005347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2007 05:01:36 -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 l9MC1ZRn005346; Mon, 22 Oct 2007 05:01:35 -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 odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9MC1Xr9005326 for ; Mon, 22 Oct 2007 05:01:34 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-mcl1.frcl.bull.fr [129.184.87.20]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA11860 for ; Mon, 22 Oct 2007 14:08:55 +0200 Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2007102213573596:169728 ; Mon, 22 Oct 2007 13:57:35 +0200 Date: Mon, 22 Oct 2007 13:57:33 +0200 From: "Denis Pinkas" To: "ietf-pkix@imc.org" Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution of DR320" X-mailer: Foxmail 5.0 [-fr-] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 22/10/2007 13:57:35, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 22/10/2007 14:01:22, Serialize complete at 22/10/2007 14:01:22 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by balder-227.proper.com id l9MC1Zr9005341 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ said: >It seems to me that this is a trust anchor configuration concern. Not only. > If two CAs adopt the same name and a user accepts both of these CAs as >trust anchors, then there could be a problem. Just don't do it. This is correct, but insufficient. This does not prevent two CAs somewhere under this trust anchor to use the same name in different branches. >RFC 3280bis says: > While X.509 mandates that names be unambiguous, there is a risk that > two unrelated authorities will issue certificates and/or CRLs under > the same issuer name. This is correct. This sentence contradicts the response to DR 320. > As a means of reducing problems and security > issues related to issuer name collisions, CA and CRL issuer names > SHOULD be formed in a way that reduces the likelihood of name > collisions. This recommandation does not *prevent* "problems and security issues". This sentence should be deleted or changed. > Implementers should take into account the possible > existence of multiple unrelated CAs and CRL issuers with the same > name. This is fully correct. > At a minimum, implementations validating CRLs MUST ensure that > the certification path of a certificate and the CRL issuer > certification path used to validate the certificate terminate at the > same trust anchor. This "minimum" clause is both insufficient and insecure. This sentence gives a false sense of security. This means that RFC3280bis currently provides no coorect guidance on how implementers should address this issue. The following text is an attempt to address this issue: "Implementations validating indirect CRLs MUST make sure that the certificate of the CRL Issuer is indeed issued by the CA that issued the certificate to be verified, which means that the sequence of DNs of the certification path of the CRL issuer, up to the DN of a trust anchor, must be identical to the the sequence of DNs of the certification path of the certificate to be verified, up to the DN of the same trust anchor". Denis >Russ > >At 08:12 AM 10/5/2007, ITU-T SG 17 wrote: > >>Title: Liaison to IETF on the resolution of DR320 >>Submission Date: 2007-10-05 >>URL of the IETF Web page: >>https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=375 >>Please reply by 2008-03-01 >> >>From: Xiaoya Yang(ITU-T SG 17) >>To: IETF/PKIX(Russ Housley , Stefan Santesson >>) >>Cc: Herbert Bertine >> >> >> >>Reponse Contact: Xiaoya YANG >> >>Technical Contact: >> >>Purpose: For action >>Body: At our recent ITU-T SG17 meeting in Geneva we discussed and >>rejected Defect Report 320 >>(http://www.x500standard.com/uploads/Defects/DR_320.pdf) from >>AFNOR. This DR advanced an argument that Distinguished Names may >>not be unique and as such, the DN of the Certificate User may not be unique. >>The directory group believes that Distinguished Name values must be >>unique and unambiguously identify a single entity, hence the use of >>the term Distinguished. >>The DR states “the DN of the issuer name cannot be guaranteed to >>be unique”. X.509 takes its definition of DN from X.501. Clause >>9.2 of X.501 specifies the definition of DistinguishedName. This >>clause states A name shall be unambiguous, that is, denotes just one object. >>Clause 9 goes on to state: It is the responsibility of the relevant >>naming authority for an entry to ensure that this is so by >>appropriately assigning distinguished attribute values. Allocation >>of RDNs is considered an administrative undertaking that may or may >>not require some negotiation between involved organizations or >>administrations. This Directory Specification does not provide such >>a negotiation mechanism, and makes no assumption as to how it is performed. >>The standard takes an axiomatic view of the concept that a >>distinguished name unambiguously identifies a single entity. Things >>break if two entities identify themselves using the same name. We >>don't let two entities have the same domain name or the same email >>address. Why? - because things wouldn't work. >>The directory group does not accept the DR’s basic argument. We >>believe that if two entities present the same name and a CA issues a >>certificate to each, that CA made a mistake - not a naming authority >>mistake, since a CA is not an naming authority (although one entity >>can be both), but an entity to key binding mistake that leads to >>confusion and even worse, a security risk. >>We believe that if two entities claim the same name as top level >>CAs, there is a political/procedural breakdown much like the domain >>ownership arguments we have seen. No one argues that the Internet >>protocols should be modified to solve that problem. The conflict is >>resolved and one entity is assigned the name. The group believes >>that this is the only reasonable solution for Distinguished >>Naming. One votes for the CA of choice by configuring it as an anchor. >>One of the participants in the directory meeting stated that >>Certification Authorities are being deployed with names not acquired >>from naming authorities but with names arbitrarily chosen assuming >>that no other CA is or will be operating under that name. That >>participant further stated that the IETF provides no guidelines on >>ensuring that the names of CAs are unambiguous. >>The directory group requests the IETF PKIX group to comment on this >>statement. If the statement is correct, we ask the IETF to consider >>putting a mechanism in place to prevent conflict, e.g. a list of >>existing CA names that deployers of new CAs could check for naming conflicts. >>Attachment(s): >>No document has been attached > Regards, Denis Pinkas 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 l9MC1Yml005339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2007 05:01:34 -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 l9MC1Ywq005338; Mon, 22 Oct 2007 05:01:34 -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 odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9MC1S8o005306 for ; Mon, 22 Oct 2007 05:01:29 -0700 (MST) (envelope-from denis.pinkas@bull.net) Received: from MSGA-001.frcl.bull.fr (msga-mcl1.frcl.bull.fr [129.184.87.20]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA100800; Mon, 22 Oct 2007 14:08:52 +0200 Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2007102213524618:169607 ; Mon, 22 Oct 2007 13:52:46 +0200 Date: Mon, 22 Oct 2007 13:52:42 +0200 From: "Denis Pinkas" To: "ietf-pkix@imc.org" Cc: "Russ Housley" Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution of DR320" X-mailer: Foxmail 5.0 [-fr-] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 22/10/2007 13:52:46, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 22/10/2007 14:01:16, Serialize complete at 22/10/2007 14:01:16 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by balder-227.proper.com id l9MC1Y8o005332 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul, I agree with what you say. However", Words fail me" may have multiple interpretations. We are going to invent a mechanism to prevent conflict, e.g. a list of existing CA names that deployers of new CAs could check for naming conflicts. We are not going either to mandate the use of the DC naming attribute to guarantee DN uniqueness. The text from DR 320 is: On page 12, the current text states �serialNumber is an integer assigned by the CA to each certificate. The value of serialNumber shall be unique for each certificate issued by a given CA (i.e., the issuer name and serial number identify a unique certificate).� The text inside the parenthesis should be deleted: the DN of the issuer name cannot be guaranteed to be unique (the collision may be deliberate or accidental) and therefore the issuer name and serial number cannot uniquely identify a certificate. The text of the answer to DR 320 states: "This DR advanced an argument that Distinguished Names may not be unique and as such, the DN of the Certificate User may not be unique. The directory group believes that Distinguished Name values must be unique and unambiguously identify a single entity, hence the use of the term Distinguished". The implications are that DR 320 has been rejected by the directory group on a wrong basis. Denis >The ITU statement says the following: >>>One of the participants in the directory meeting stated that >>>Certification Authorities are being deployed with names not >>>acquired from naming authorities but with names arbitrarily chosen >>>assuming that no other CA is or will be operating under that name. >That is, of course, true. There is no central repository for CA names >because there is no central authority for CAs. >>>That participant further stated that the IETF provides no >>>guidelines on ensuring that the names of CAs are unambiguous. >That is true. >>>The directory group requests the IETF PKIX group to comment on this >>>statement. >Should we make a consensus call on "that is true"? >>>If the statement is correct, we ask the IETF to consider putting a >>>mechanism in place to prevent conflict, e.g. a list of existing CA >>>names that deployers of new CAs could check for naming conflicts. >Words fail me. >--Paul Hoffman, Director >--VPN Consortium 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 l9MAYLxR097042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2007 03:34:21 -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 l9MAYLOm097041; Mon, 22 Oct 2007 03:34:21 -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 woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l9MAYKwt097035 for ; Mon, 22 Oct 2007 03:34:21 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200710221034.l9MAYKwt097035@balder-227.proper.com> Received: (qmail 27076 invoked by uid 0); 22 Oct 2007 10:34:19 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (193.0.2.29) by woodstock.binhost.com with SMTP; 22 Oct 2007 10:34:19 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 22 Oct 2007 06:33:38 -0400 To: Hoyt L Kesterson II , ietf-pkix@imc.org From: Russ Housley Subject: Re: Upper Bounds for X.509 In-Reply-To: References: <6077526.1192816179346.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> <471C1CF5.8090803@eb2bcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hoyt: One never knows which non-critical extensions might be put in a certificate. Remember when Bob Jueneman was advocating pictures in certificates.... Russ At 04:30 AM 10/22/2007, Hoyt L Kesterson II wrote: >Steven, I didn't say it was an attractive option. I have always been >against these limits. > >Peter Gutmann recommended that "reasonable" upper bounds be set, >e.g. thousand characters for a common name. But it appears his >concern is about erratic operation when the certificate itself it huge. > >It may be more reasonable to set a max size on the entire >certificate than on the individual components that comprise it. > > hoyt > > >Hoyt, > > > >Hoyt L Kesterson II wrote: > >>Another option is to keep the bounds as we have them and have the > IETF standard mandate the bounds, choosing any values you like. > > > >Then directory deployments would have to choose between being nice > >to PKIX applications by imposing PKIX's upper bounds, or being > >nice to other LDAP applications by not imposing upper bounds. > > > >Regards, > >Steven 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 l9M8YaSm087562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2007 01:34:36 -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 l9M8Yahi087561; Mon, 22 Oct 2007 01:34:36 -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 elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9M8YZnf087555 for ; Mon, 22 Oct 2007 01:34:35 -0700 (MST) (envelope-from hoytkesterson@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=nJBCUXwc6/xe9SVqztYqG2NmrNgqiv1Zh2dFCy7a0uxaoFtEo5T5d23xRpSQO+kC; h=Received:Mime-Version:Message-Id:In-Reply-To:References:Date:To:From:Subject:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [151.118.180.188] (helo=[192.168.0.4]) by elasmtp-masked.atl.sa.earthlink.net with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1Ijsk6-00022S-W9 for ietf-pkix@imc.org; Mon, 22 Oct 2007 04:34:35 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <471C1CF5.8090803@eb2bcom.com> References: <6077526.1192816179346.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> <471C1CF5.8090803@eb2bcom.com> Date: Mon, 22 Oct 2007 01:30:50 -0700 To: ietf-pkix@imc.org From: Hoyt L Kesterson II Subject: Re: Upper Bounds for X.509 Content-Type: text/plain; charset="us-ascii" X-ELNK-Trace: 59f3edefb26af0321a6f9084d36cbc6474bf435c0eb9d478100f810b5c66a190b0a6111f7b49939cfbdb5738f082ee71350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 151.118.180.188 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Steven, I didn't say it was an attractive option. I have always been against these limits. Peter Gutmann recommended that "reasonable" upper bounds be set, e.g. thousand characters for a common name. But it appears his concern is about erratic operation when the certificate itself it huge. It may be more reasonable to set a max size on the entire certificate than on the individual components that comprise it. hoyt >Hoyt, > >Hoyt L Kesterson II wrote: >>Another option is to keep the bounds as we have them and have the IETF standard mandate the bounds, choosing any values you like. > >Then directory deployments would have to choose between being nice >to PKIX applications by imposing PKIX's upper bounds, or being >nice to other LDAP applications by not imposing upper bounds. > >Regards, >Steven 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 l9M3k3kR065609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Oct 2007 20:46:03 -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 l9M3k3gY065608; Sun, 21 Oct 2007 20:46:03 -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 host.eb2bcom.com (host.eb2bcom.com [72.232.34.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9M3k1sO065602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 21 Oct 2007 20:46:02 -0700 (MST) (envelope-from steven.legg@eb2bcom.com) Received: from [202.164.192.219] (helo=[192.168.99.100]) by host.eb2bcom.com with esmtpa (Exim 4.68) (envelope-from ) id 1IjoEs-0000P2-6e; Mon, 22 Oct 2007 13:46:02 +1000 Message-ID: <471C1CF5.8090803@eb2bcom.com> Date: Mon, 22 Oct 2007 13:45:57 +1000 From: Steven Legg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hoyt L Kesterson II CC: PKIX Subject: Re: Upper Bounds for X.509 References: <6077526.1192816179346.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> In-Reply-To: <6077526.1192816179346.JavaMail.root@elwamui-lapwing.atl.sa.earthlink.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.eb2bcom.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - eb2bcom.com X-Source: X-Source-Args: X-Source-Dir: Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hoyt, Hoyt L Kesterson II wrote: > Another option is to keep the bounds as we have them and have the IETF standard mandate the bounds, choosing any values you like. Then directory deployments would have to choose between being nice to PKIX applications by imposing PKIX's upper bounds, or being nice to other LDAP applications by not imposing upper bounds. Regards, Steven 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 l9M3WSqp064972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Oct 2007 20:32:28 -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 l9M3WSTk064971; Sun, 21 Oct 2007 20:32:28 -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 host.eb2bcom.com (host.eb2bcom.com [72.232.34.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9M3WRIH064965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 21 Oct 2007 20:32:27 -0700 (MST) (envelope-from steven.legg@eb2bcom.com) Received: from cust3803.vic01.dataco.com.au ([202.164.192.219] helo=[192.168.99.100]) by host.eb2bcom.com with esmtpa (Exim 4.68) (envelope-from ) id 1Ijo1j-0008M6-4F; Mon, 22 Oct 2007 13:32:27 +1000 Message-ID: <471C19C5.3070902@eb2bcom.com> Date: Mon, 22 Oct 2007 13:32:21 +1000 From: Steven Legg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Russ Housley CC: PKIX Subject: Re: Upper Bounds for X.509 References: <001401c8125b$17c96e60$0100a8c0@morten> <200710191707.l9JH7bYE004435@balder-227.proper.com> In-Reply-To: <200710191707.l9JH7bYE004435@balder-227.proper.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.eb2bcom.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - eb2bcom.com X-Source: X-Source-Args: X-Source-Dir: Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, Russ Housley wrote: > I understand that an unbounded directory string may be useful in many > contexts, but is it going to help interoperability to remove the bounds > on naming attributes? As I recall, it was an upper bound on a naming attribute that we first bumped up against, and which prompted us to ignore all the upper bounds. Ignoring the upper bounds also allows us to claim conformance with LDAP, which imposes no upper bounds. Clearly there is the potential for interoperability problems if we interwork with an implementation that imposes upper bounds. To the best of my knowledge such problems haven't arisen with respect to our implementation. I assume that in each instance of interworking the other system also ignores the upper bounds, or else the shared data happen to be within that other system's upper bounds. Nonetheless, the potential for interoperability problems diminishes if the upper bounds are discarded. Regards, Steven > > Russ > > At 10:19 AM 10/19/2007, Erik Andersen wrote: >> Hi Folks, >> >> As mentioned in a liaison statement from the directory meeting, >> September 2007 in Geneva, we have decided to remove the Upper Bounds >> from any occurrence. A majority of those are on DirectoryString, which >> is also specified for many attribute types. >> >> At one type we were considering removing the Upper Bound by the Defect >> Report procedure, but found the change to heavy for that procedure. By >> the Defect Report procedure we corrected a inconsistency in the Upper >> Bounds and expressed that Upper Bounds are only provided as examples. >> >> It is our intention to remove the Upper Bound from the sixth edition >> of the Directory Specification. We gave a possible approach in the >> liaison statement, but that may not be the final solution. Be assured >> that whatever we do, it will be valid ASN.1. The example we came up >> with is actual valid ASN.1 by using parameterized specification. >> However, we are faced with the problem that directory object class >> definitions will be parameterized. This does not change the definition >> as such, but only the ASN.1 appearance. This could be a problem for >> implementations parsing such object class definitions to set-up the >> directory schema. >> >> Our fall-back solution is to define a new variant of DirectoryString >> that is unbounded. >> >> Erik Andersen >> Andersen's L-Service >> Mobile: +45 20 97 14 90 >> e-mail: era@tdcadsl.dk >> http://www.x500standard.com/ >> http://home20.inet.tele.dk/era/me >> 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 l9M1pXJf060105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Oct 2007 18:51:33 -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 l9M1pX9h060104; Sun, 21 Oct 2007 18:51:33 -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 host.eb2bcom.com (host.eb2bcom.com [72.232.34.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9M1pWTq060097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 21 Oct 2007 18:51:33 -0700 (MST) (envelope-from steven.legg@eb2bcom.com) Received: from [202.164.192.219] (helo=[192.168.99.100]) by host.eb2bcom.com with esmtpa (Exim 4.68) (envelope-from ) id 1IjmS4-0003rf-2t; Mon, 22 Oct 2007 11:51:32 +1000 Message-ID: <471C021F.2000006@eb2bcom.com> Date: Mon, 22 Oct 2007 11:51:27 +1000 From: Steven Legg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Tom Gindin CC: "ietf-pkix@imc.org" Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution of DR320" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.eb2bcom.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - eb2bcom.com X-Source: X-Source-Args: X-Source-Dir: Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tom Gindin wrote: > I know this response is a little late, but the main reason that > there is no central repository for CA names is that there is no world-wide > directory using X.500 names. For reasons which have been discussed many > times on this list, there probably never will be. Of course, the IETF > knows of an existing registry which could be used to avoid conflicts > between CA names. > How about the following wording: "Certificate Authorities SHOULD > NOT use a value in the Organization or Common Name attribute of their > Distinguished Name which is syntactically legal as a dNSName (i.e. an IA5 > string containing one or more periods but no spaces) unless they are > operated by an organization which has registered the domain name > controlling that dNSName. Certificate Authorities wishing to ensure a > globally unique issuer name MAY use an IA5 FQDN controlled by their > organization in either the Organization or the Common Name attribute." ... or use the dc naming attribute defined in RFC 4519. Regards, Steven > Does anybody want to add Organizational Unit into the mix, and possibly > even make it a SHOULD for newly allocated CA's? > Given my unfamiliarity with non-alphabetic scripts, I hesitate to > discuss internationalized DNS names in this connection unless Punycode is > relevant. However, even without considering DR 320, using somebody else's > domain name as your CN or O attribute is misleading. > > Tom Gindin > > P.S. - The opinions above are mine, and not necessarily those of my > employer > > > > Ryan Hurst > Sent by: owner-ietf-pkix@mail.imc.org > 10/09/2007 08:47 PM > > To > Paul Hoffman