Re: New Liaison Statement, "Liaison to IETF on the resolution of DR320"

"Denis Pinkas" <denis.pinkas@bull.net> Mon, 22 October 2007 12:57 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 1IjwqN-0006s3-IN for pkix-archive@lists.ietf.org; Mon, 22 Oct 2007 08:57:19 -0400
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IjwqB-00081F-Jv for pkix-archive@lists.ietf.org; Mon, 22 Oct 2007 08:57:15 -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 l9MC1Yml005339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2007 05:01:34 -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 l9MC1Ywq005338; Mon, 22 Oct 2007 05:01:34 -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 odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9MC1S8o005306 for <ietf-pkix@imc.org>; Mon, 22 Oct 2007 05:01:29 -0700 (MST) (envelope-from denis.pinkas@bull.net)
Received: from MSGA-001.frcl.bull.fr (msga-mcl1.frcl.bull.fr [129.184.87.20]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA100800; Mon, 22 Oct 2007 14:08:52 +0200
Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2007102213524618:169607 ; Mon, 22 Oct 2007 13:52:46 +0200
Date: Mon, 22 Oct 2007 13:52:42 +0200
From: Denis Pinkas <denis.pinkas@bull.net>
To: "ietf-pkix@imc.org" <ietf-pkix@imc.org>
Cc: Russ Housley <housley@vigilsec.com>
Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution of DR320"
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 22/10/2007 13:52:46, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 22/10/2007 14:01:16, Serialize complete at 22/10/2007 14:01:16
Message-ID: <OFA143DBA4.DC514024-ONC125737C.0041418F@frcl.bull.fr>
Content-Type: text/plain; charset="iso-8859-1"
X-MIME-Autoconverted: from base64 to 8bit by balder-227.proper.com id l9MC1Y8o005332
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>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l9MC1Yml005339
X-Spam-Score: 2.1 (++)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5

Paul,

I agree with what you say. However", Words fail me" may have multiple interpretations.

We are going to invent a mechanism to prevent conflict, e.g. a list of existing CA 
names that deployers of new CAs could check for naming conflicts.

We are not going either to mandate the use of the DC naming attribute to guarantee
DN uniqueness.

The text from DR 320 is:

On page 12, the current text states “serialNumber is an integer assigned 
by the CA to each certificate. The value of serialNumber shall be unique 
for each certificate issued by a given CA (i.e., the issuer name and serial number 
identify a unique certificate).”
 
The text inside the parenthesis should be deleted: the DN of the issuer name 
cannot be guaranteed to be unique (the collision may be deliberate or accidental) 
and therefore the issuer name and serial number cannot uniquely identify a certificate.

The text of the answer to DR 320 states:

"This DR advanced an argument that Distinguished Names may 
not be unique and as such, the DN of the Certificate User may not be unique.

The directory group believes that Distinguished Name values must be 
unique and unambiguously identify a single entity, hence the use of 
the term Distinguished".

The implications are that DR 320 has been rejected by the directory group on a wrong basis.

Denis


>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