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

Russ Housley <> Fri, 05 October 2007 14:58 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1Idocy-00054d-L1 for; Fri, 05 Oct 2007 10:58:08 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1Idocn-0000B1-61 for; Fri, 05 Oct 2007 10:57:58 -0400
Received: from (localhost []) by (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
Received: (from majordom@localhost) by (8.13.5/8.13.5/Submit) id l95EAjn5017339; Fri, 5 Oct 2007 07:10:45 -0700 (MST) (envelope-from
X-Authentication-Warning: majordom set sender to using -f
Received: from ( []) by (8.13.5/8.13.5) with SMTP id l95EAhr5017333 for <>; Fri, 5 Oct 2007 07:10:44 -0700 (MST) (envelope-from
Message-Id: <>
Received: (qmail 15799 invoked by uid 0); 5 Oct 2007 14:10:40 -0000
Received: from unknown (HELO ( by with SMTP; 5 Oct 2007 14:10:40 -0000
X-Mailer: QUALCOMM Windows Eudora Version
Date: Fri, 05 Oct 2007 10:10:31 -0400
From: Russ Housley <>
Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution of DR320"
In-Reply-To: <>
References: <>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Precedence: bulk
List-Archive: <>
List-ID: <>
List-Unsubscribe: <>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by 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.


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: 
>Please reply by 2008-03-01
>From: Xiaoya Yang(ITU-T SG 17) <>
>To: IETF/PKIX(Russ Housley <>om>, Stefan Santesson 
>Cc: Herbert Bertine <>
>Reponse Contact: Xiaoya YANG <>
>Technical Contact: <>
>Purpose: For action
>Body: At our recent ITU-T SG17 meeting in Geneva we discussed and 
>rejected Defect Report 320 
>( 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.
>No document has been attached