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