Re: New Liaison Statement, "Liaison to IETF on the resolution of DR320"
Steven Legg <steven.legg@eb2bcom.com> Mon, 22 October 2007 02:47 UTC
Return-path: <owner-ietf-pkix@mail.imc.org>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjnKG-0007FT-Br for pkix-archive@lists.ietf.org; Sun, 21 Oct 2007 22:47:32 -0400
Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IjnKF-00087b-O0 for pkix-archive@lists.ietf.org; Sun, 21 Oct 2007 22:47: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 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 <ietf-pkix@imc.org>; 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 <steven.legg@eb2bcom.com>) 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 <steven.legg@eb2bcom.com>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Tom Gindin <tgindin@us.ibm.com>
CC: "ietf-pkix@imc.org" <ietf-pkix@imc.org>
Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution of DR320"
References: <OFD6F3557E.1CC1A2EF-ON85257375.00756BC3-85257379.005B3F77@us.ibm.com>
In-Reply-To: <OFD6F3557E.1CC1A2EF-ON85257375.00756BC3-85257379.005B3F77@us.ibm.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: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86
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 <Ryan.Hurst@microsoft.com> > Sent by: owner-ietf-pkix@mail.imc.org > 10/09/2007 08:47 PM > > To > Paul Hoffman <paul.hoffman@vpnc.org>, Russ Housley <housley@vigilsec.com>, > "ietf-pkix@imc.org" <ietf-pkix@imc.org> > cc > > Subject > RE: New Liaison Statement, "Liaison to IETF on the resolution of DR320" > > > > > > > > All of these statements are true. > > Words fail me is as fine a response to that as any... > > ________________________________________ > From: owner-ietf-pkix@mail.imc.org [owner-ietf-pkix@mail.imc.org] On > Behalf Of Paul Hoffman [paul.hoffman@vpnc.org] > Sent: Tuesday, October 09, 2007 3:25 PM > To: Russ Housley; ietf-pkix@imc.org > Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution of > DR320" > > 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 > > >
- Re: New Liaison Statement, "Liaison to IETF on th… Russ Housley
- Re: New Liaison Statement, "Liaison to IETF on th… Paul Hoffman
- RE: New Liaison Statement, "Liaison to IETF on th… Ryan Hurst
- RE: New Liaison Statement, "Liaison to IETF on th… Tom Gindin
- RE: New Liaison Statement, "Liaison to IETF on th… Paul Hoffman
- Re: New Liaison Statement, "Liaison to IETF on th… Steven Legg
- Re: New Liaison Statement, "Liaison to IETF on th… Denis Pinkas
- Re: New Liaison Statement, "Liaison to IETF on th… Denis Pinkas
- Re: New Liaison Statement, "Liaison to IETF on th… Julien Stern
- Re: New Liaison Statement, "Liaison to IETF on th… Denis Pinkas
- RE: New Liaison Statement, "Liaison to IETF on th… Santosh Chokhani
- Re: New Liaison Statement, "Liaison to IETF on th… Denis Pinkas
- Re: New Liaison Statement, "Liaison to IETF on th… Julien Stern
- Re: New Liaison Statement, "Liaison to IETF on th… Julien Stern
- Re: New Liaison Statement, "Liaison to IETF on th… Denis Pinkas
- RE: New Liaison Statement, "Liaison to IETF on th… Santosh Chokhani
- RE: New Liaison Statement, "Liaison to IETF on th… Santosh Chokhani
- Re: New Liaison Statement, "Liaison to IETF on th… Paul Hoffman
- RE: New Liaison Statement, "Liaison to IETF on th… stephen.farrell
- RE: New Liaison Statement, "Liaison to IETF on th… Santosh Chokhani
- Re: New Liaison Statement, "Liaison to IETF on th… Julien Stern
- RE: New Liaison Statement, "Liaison to IETF on th… Santosh Chokhani