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
> 
> 
>