Skip to main content

Liaison statement
Liaison to IETF on the resolution of DR320

Additional information about IETF liaison relationships is available on the IETF webpage and the Internet Architecture Board liaison webpage.
State Posted
Submitted Date 2007-10-05
From Group ITU-T-SG-17
From Contact Xiaoya Yang
To Group pkix
To Contacts Russ Housley <housley@vigilsec.com>
Stefan Santesson <stefans@microsoft.com>
Cc Herbert Bertine <hbertine@alcatel-lucent.com>
<tsbsg17@itu.int>
<era@tdcadsl.dk>
<hoytkesterson@earthlink.net>
Response Contact Xiaoya YANG <xiaoya.yang@itu.int>
<tsbsg17@itu.int>
Technical Contact <era@tdcadsl.dk>
<hoytkesterson@earthlink.net>
Purpose For action
Deadline 2008-03-01 Action Taken
Attachments (None)
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.