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

[Russ Housley <[e-mail]>]

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) <[e-mail]>
>To: IETF/PKIX(Russ Housley <[e-mail]>, Stefan Santesson 
><[e-mail]>)
>Cc: Herbert Bertine <[e-mail]>
><[e-mail]>
><[e-mail]>
><[e-mail]>
>Reponse Contact: Xiaoya YANG <[e-mail]>
><[e-mail]>
>Technical Contact: <[e-mail]>
><[e-mail]>
>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