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