RE: New Liaison Statement, "Liaison to IETF on the resolution of DR320"
Paul Hoffman <paul.hoffman@vpnc.org> Fri, 19 October 2007 18:22 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 1IiwUG-0003HE-Ef for pkix-archive@lists.ietf.org; Fri, 19 Oct 2007 14:22:20 -0400
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiwU4-0003ZV-HB for pkix-archive@lists.ietf.org; Fri, 19 Oct 2007 14:22:10 -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 l9JHLinu005897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Oct 2007 10:21:44 -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 l9JHLioe005896; Fri, 19 Oct 2007 10:21:44 -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 [10.20.30.150] (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 l9JHLWdX005861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Oct 2007 10:21:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p06240806c33e9564cde9@[10.20.30.150]>
In-Reply-To: <OFD6F3557E.1CC1A2EF-ON85257375.00756BC3-85257379.005B3F77@us.ibm.com>
References: <OFD6F3557E.1CC1A2EF-ON85257375.00756BC3-85257379.005B3F77@us.ibm.com>
Date: Fri, 19 Oct 2007 10:21:22 -0700
To: Tom Gindin <tgindin@us.ibm.com>
From: Paul Hoffman <paul.hoffman@vpnc.org>
Subject: RE: New Liaison Statement, "Liaison to IETF on the resolution of DR320"
Cc: ietf-pkix@imc.org
Content-Type: text/plain; charset="us-ascii"; format="flowed"
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: 82c9bddb247d9ba4471160a9a865a5f3
At 12:37 PM -0400 10/19/07, 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. While the latter is obviously true, it is not the "main reason". The "main reason" is that many (most?) CAs could get no real value out of a "world-wide directory using X.500 names". For example, when an organization becomes a CA by making its own trust anchor for internal use, having to register in a "world-wide directory" is a hindrance, not a feature. >For reasons which have been discussed many >times on this list, there probably never will be. "Probably" may be understating the likelihood. >Of course, the IETF >knows of an existing registry which could be used to avoid conflicts >between CA names. We do? > 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." This might be appropriate in an ITU document, but is it really appropriate for a standards-track IETF document? In specific, the latter makes it sound like using your domain name is safe. Might be, might not be. >Does anybody want to add Organizational Unit into the mix, and possibly >even make it a SHOULD for newly allocated CA's? I don't see how this would help. If you look at the OUs in IssuerNames of certificates flying around the net, you can see that few people understand OUs, > 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. True, but I do not think that it is the place of IETF documents to say what is or is not "misleading". --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