RE: New Liaison Statement, "Liaison to IETF on the resolution of DR320"
Tom Gindin <tgindin@us.ibm.com> Fri, 19 October 2007 17:32 UTC
Return-path: <owner-ietf-pkix@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iivhb-0006tL-Ra for pkix-archive@lists.ietf.org; Fri, 19 Oct 2007 13:32:03 -0400
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IivhK-0001QV-Ov for pkix-archive@lists.ietf.org; Fri, 19 Oct 2007 13:31:53 -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 l9JGcn2w001011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Oct 2007 09:38: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 l9JGcnEv001010; Fri, 19 Oct 2007 09:38: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 e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9JGclR5000999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-pkix@imc.org>; Fri, 19 Oct 2007 09:38:48 -0700 (MST) (envelope-from tgindin@us.ibm.com)
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l9JGclHw011826 for <ietf-pkix@imc.org>; Fri, 19 Oct 2007 12:38:47 -0400
Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l9JGc2wD117738 for <ietf-pkix@imc.org>; Fri, 19 Oct 2007 12:38:47 -0400
Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l9JGbqN0026217 for <ietf-pkix@imc.org>; Fri, 19 Oct 2007 12:37:52 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l9JGbqx0025736; Fri, 19 Oct 2007 12:37:52 -0400
In-Reply-To: <FD8C33C9BEC73E4A9034D0B11FA98260B9B3049A39@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com>
To: Ryan Hurst <Ryan.Hurst@microsoft.com>
Cc: Russ Housley <housley@vigilsec.com>, "ietf-pkix@imc.org" <ietf-pkix@imc.org>, Paul Hoffman <paul.hoffman@vpnc.org>
MIME-Version: 1.0
Subject: RE: New Liaison Statement, "Liaison to IETF on the resolution of DR320"
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
From: Tom Gindin <tgindin@us.ibm.com>
Message-ID: <OFD6F3557E.1CC1A2EF-ON85257375.00756BC3-85257379.005B3F77@us.ibm.com>
Date: Fri, 19 Oct 2007 12:37:41 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 7.0.2FP2 IGS702FP2HF2|August 8, 2007) at 10/19/2007 12:37:51, Serialize complete at 10/19/2007 12:37:51
Content-Type: text/plain; charset="US-ASCII"
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: f66b12316365a3fe519e75911daf28a8
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." 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