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

Russ Housley <housley@vigilsec.com> Fri, 05 October 2007 14:58 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 1Idocy-00054d-L1 for pkix-archive@lists.ietf.org; Fri, 05 Oct 2007 10:58:08 -0400
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Idocn-0000B1-61 for pkix-archive@lists.ietf.org; Fri, 05 Oct 2007 10:57:58 -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 l95EAjlp017340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Oct 2007 07:10:45 -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 l95EAjn5017339; Fri, 5 Oct 2007 07:10:45 -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 woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l95EAhr5017333 for <ietf-pkix@imc.org>; Fri, 5 Oct 2007 07:10:44 -0700 (MST) (envelope-from housley@vigilsec.com)
Message-Id: <200710051410.l95EAhr5017333@balder-227.proper.com>
Received: (qmail 15799 invoked by uid 0); 5 Oct 2007 14:10:40 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (207.236.147.202) by woodstock.binhost.com with SMTP; 5 Oct 2007 14:10:40 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 05 Oct 2007 10:10:31 -0400
To: ietf-pkix@imc.org
From: Russ Housley <housley@vigilsec.com>
Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution of DR320"
In-Reply-To: <E1Idm2x-0000Nw-Cb@ietf.org>
References: <E1Idm2x-0000Nw-Cb@ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; 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>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l95EAjlp017340
X-Spam-Score: 1.5 (+)
X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2

It seems to me that this is a trust anchor configuration concern.  If 
two CAs adopt the same name and a user accepts both of these CAs as 
trust anchors, then there could be a problem.  Just don't do it.

RFC 3280bis says:

    While X.509 mandates that names be unambiguous, there is a risk that
    two unrelated authorities will issue certificates and/or CRLs under
    the same issuer name.  As a means of reducing problems and security
    issues related to issuer name collisions, CA and CRL issuer names
    SHOULD be formed in a way that reduces the likelihood of name
    collisions.  Implementers should take into account the possible
    existence of multiple unrelated CAs and CRL issuers with the same
    name.  At a minimum, implementations validating CRLs MUST ensure that
    the certification path of a certificate and the CRL issuer
    certification path used to validate the certificate terminate at the
    same trust anchor.

Russ

At 08:12 AM 10/5/2007, ITU-T SG 17 wrote:

>Title: Liaison to IETF on the resolution of DR320
>Submission Date: 2007-10-05
>URL of the IETF Web page: 
>https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=375
>Please reply by 2008-03-01
>
>From: Xiaoya Yang(ITU-T SG 17) <tsbsg17@itu.int>
>To: IETF/PKIX(Russ Housley <housley@vigilsec.com>om>, Stefan Santesson 
><stefans@microsoft.com>)
>Cc: Herbert Bertine <hbertine@alcatel-lucent.com>
><tsbsg17@itu.int>
><era@tdcadsl.dk>
><hoytkesterson@earthlink.net>
>Reponse Contact: Xiaoya YANG <xiaoya.yang@itu.int>
><tsbsg17@itu.int>
>Technical Contact: <era@tdcadsl.dk>
><hoytkesterson@earthlink.net>
>Purpose: For action
>Body: At our recent ITU-T SG17 meeting in Geneva we discussed and 
>rejected Defect Report 320 
>(http://www.x500standard.com/uploads/Defects/DR_320.pdf) from 
>AFNOR.  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 DR states “the DN of the issuer name cannot be guaranteed to 
>be unique”.  X.509 takes its definition of DN from X.501.  Clause 
>9.2 of X.501 specifies the definition of DistinguishedName.  This 
>clause states A name shall be unambiguous, that is, denotes just one object.
>Clause 9 goes on to state: It is the responsibility of the relevant 
>naming authority for an entry to ensure that this is so by 
>appropriately assigning distinguished attribute values.  Allocation 
>of RDNs is considered an administrative undertaking that may or may 
>not require some negotiation between involved organizations or 
>administrations.  This Directory Specification does not provide such 
>a negotiation mechanism, and makes no assumption as to how it is performed.
>The standard takes an axiomatic view of the concept that a 
>distinguished name unambiguously identifies a single entity.  Things 
>break if two entities identify themselves using the same name.  We 
>don't let two entities have the same domain name or the same email 
>address.  Why? - because things wouldn't work.
>The directory group does not accept the DR’s basic argument.  We 
>believe that if two entities present the same name and a CA issues a 
>certificate to each, that CA made a mistake - not a naming authority 
>mistake, since a CA is not an naming authority (although one entity 
>can be both), but an entity to key binding mistake that leads to 
>confusion and even worse, a security risk.
>We believe that if two entities claim the same name as top level 
>CAs, there is a political/procedural breakdown much like the domain 
>ownership arguments we have seen.  No one argues that the Internet 
>protocols should be modified to solve that problem.  The conflict is 
>resolved and one entity is assigned the name.  The group believes 
>that this is the only reasonable solution for Distinguished 
>Naming.  One votes for the CA of choice by configuring it as an anchor.
>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 
>participant further stated that the IETF provides no guidelines on 
>ensuring that the names of CAs are unambiguous.
>The directory group requests the IETF PKIX group to comment on this 
>statement.  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.
>Attachment(s):
>No document has been attached