Subject: Globally unique DNs - Why?

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 1 Feb 2002 17:27:58 +0100

List,
In certain, rather "animated" discussions, the statement that an
X509.v3 Subject DN (if specified) must be globally unique in order
to be "conformant".

In my view this is not the case.  Referring to my own "citizen-ID"
with a DN like

     CN=Anders Rundgren, C=SE, serialNumber=nnnnnnnnnnnnnn

which indeed have been created by "PKIX-aware" people, I
would not call that a globally unique name.

It is unique within its own name-space which happens to be Swedish
citizen numbers but without that knowledge it could equally well
be a member certificate of a more obscure community.

But, and that the important thing, it is still a globally unique name
when using the CA as a name-space indicator.

Anders Rundgren

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 01 Feb 2002 17:58:16 +0100

Anders,

> X509.v3 Subject DN (if specified) must be globally unique in order

Please read section  "4.1.2.6  Subject" page 24 from 
<draft-ietf-pkix-new-part1-12.txt>

The DN MUST be unique for each subject entity certified by the one CA 
as defined by the issuer name field.

Denis

---

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 1 Feb 2002 21:36:33 +0100

Denis,
Note that the word *global* is completely absent from the
document you refer to.

That DNs must be unique vs a certain CA is something that it is chrystal-
clear, but that DNs must be (by themselves) be globally unique is as far I can see
neither a requirement for general PKIX compliency, nor for QC compliency.

Anders

>> List,
>> In certain, rather "animated" discussions, the statement is that an

---

From: Stephen Kent <[email-masked]>
Date: Fri, 1 Feb 2002 16:07:25 -0500

>when using the CA as a name-space indicator.

DNs are directory distinguished names, formally. the directory tie-in 
implies that a DN sequence represents a path in a directory tree 
structure. X.500 assumes a universal tree, the DIT, and thus a DN 
consistent with the semantics of X.500 would be globally unique. The 
DIT is not a reality, and probably will never be, but one can still 
note considerable advantages to DNs that are globally unique.  No 
syntactic requirement in X.500 mandates such uniqueness, any more 
than it mandates common sense re what directory attributes can be 
used in forming a DN. It is certainly legitimate to construct private 
directory trees that would not produce globally unique DNs. but, 
experience with other name spaces (e.g., Lotus Notes name spaces) has 
shown that often what was assumed to be "private" ultimately becomes 
more widely connected, and the collisions that arise due to a lack of 
effort to attempt to ensure global uniqueness come back to haunt 
system designers/administrators.

Steve

P.S.  I don't know from which end the example DN above is intended to 
be read, but either direction yields a pretty odd graph :-)

---

From: "Anders Rundgren" <[email-masked]>
Date: Sat, 2 Feb 2002 14:16:41 +0100

Re: Globally unique DNs - Why?Steve,
  DNs are directory distinguished names, formally. the directory tie-in implies that a DN sequence represents a path in a directory tree structure. X.500 assumes a universal tree, the DIT, and thus a DN consistent with the semantics of X.500 would be globally unique. The DIT is not a reality, and probably will never be, but one can still note considerable advantages to DNs that are globally unique.  No syntactic requirement in X.500 mandates such uniqueness, any more than it mandates common sense re what directory attributes can be used in forming a DN. It is certainly legitimate to construct private directory trees that would not produce globally unique DNs. but, experience with other name spaces (e.g., Lotus Notes name spaces) has shown that often what was assumed to be "private" ultimately becomes more widely connected, and the collisions that arise due to a lack of effort to attempt to ensure global uniqueness come back to haunt system designers/administrators.

  Steve

  P.S.  I don't know from which end the example DN above is intended to be read, but either direction yields a pretty odd graph :-)
Actually it was a little bit incorrect, as C=SE has recently been skipped, so now it is just CN=Name, serialNumber=nnnnn.  I.e. the DN became even more "private".  But one could also rightfully claim that a redundant DN item has been removed, as the certificate anyway requires knowledge of the regime (name-space) it was issued in.

Although there are advantages with globally unique DNs, IMHO the number of drawbacks outnumber the advantages.  To name a few of those drawbacks:
  a.. It probably requires something close to socialism to establish such strictly conforming CAs
  b.. It is in conflict with commercial disjunct name-spaces (e.g. DUNS, VISA etc.)
  c.. It may expose information that you not want to have in public
  d.. And last but not least, it leads to a fragile ID-structure, as the global schemes typically are based on a multitude of attributes used to identify a subject, and if any of these change, the link to the subject is broken.  This is in contrast to my citizen-ID that is relevant as long as I stay a Swedish citizen.  If the CA had been a commercial CA using a private name-space, the ID could very well survive changes in citizenship, name, and sex (there is a gender-tag in our citizen-IDs so transsexuals find them less useful...).
But as PKI except for web-server certificates, is just a long-time promise, both views are equally valid at this stage. I do though see a need for a possible PKIX work-item to support this multi name-space, "anarchistic" type of PKI, and that is a way for CAs to specify what private (or public), name-space their issued DNs belong to.  That would preferably be a URI, like for XML Schemas.  Without such a specifier, we may indeed some day, get the Lotus Notes problem you referred to.  PIs is one way to achieve this, but I'm talking about a more neutral scheme as not everyone likes PIs.

cheers,
Anders

---

From: jim <[email-masked]>
Date: Sat, 02 Feb 2002 23:06:37 -0500

Point of clarification.  There is a difference between the Distinguished Name
(DN) and the Directory Distinguished Name (DDN).  The DN is the X.500 naming
structure that goes from the root naming structure of the directory to the outer
branches and leaf entry for an individual or role.  In LDAP directories, the
structure is still used, but from the individual or role moving up to the root
entry.  The DDN, on the other hand, is the trail of authorizations for a user
moving from the issuing Certification Authority up to the root issuing
authority, be it a Policy Approving Authority in a very hierarchical structure
or the chief CA in a ring set up.  My experience is that confusion of the two,
DN and DDN, almost always leads to lack of understanding of how the system needs
to work.
Jim

Anders Rundgren wrote:

> Steve,
>
>      DNs are directory distinguished names, formally. the directory
>      tie-in implies that a DN sequence represents a path in a directory
>      tree structure. X.500 assumes a universal tree, the DIT, and thus a
>      DN consistent with the semantics of X.500 would be globally unique.
>      The DIT is not a reality, and probably will never be, but one can
>      still note considerable advantages to DNs that are globally unique.
>      No syntactic requirement in X.500 mandates such uniqueness, any more
>      used in forming a DN. It is certainly legitimate to construct
>      private directory trees that would not produce globally unique DNs.
>      but, experience with other name spaces (e.g., Lotus Notes name
>      spaces) has shown that often what was assumed to be "private"
>      ultimately becomes more widely connected, and the collisions that
>      arise due to a lack of effort to attempt to ensure global uniqueness
>      come back to haunt system designers/administrators.
>
>      Steve
>
>      P.S.  I don't know from which end the example DN above is intended
>      to be read, but either direction yields a pretty odd graph :-)
>
> Actually it was a little bit incorrect, as C=SE has recently been skipped, so
> now it is just CN=Name, serialNumber=nnnnn.  I.e. the DN became even more
> "private".  But one could also rightfully claim that a redundant DN item has
> been removed, as the certificate anyway requires knowledge of the regime
> (name-space) it was issued in. Although there are advantages with globally
> unique DNs, IMHO the number of drawbacks outnumber the advantages.  To name a
> few of those drawbacks:
>
>    * It probably requires something close to socialism to establish such
>      strictly conforming CAs
>    * It is in conflict with commercial disjunct name-spaces (e.g. DUNS, VISA
>      etc.)
>    * It may expose information that you not want to have in public
>    * And last but not least, it leads to a fragile ID-structure, as the global
>      schemes typically are based on a multitude of attributes used to identify
>      a subject, and if any of these change, the link to the subject is
>      broken.  This is in contrast to my citizen-ID that is relevant as long as
>      I stay a Swedish citizen.  If the CA had been a commercial CA using a
>      private name-space, the ID could very well survive changes in
>      citizenship, name, and sex (there is a gender-tag in our citizen-IDs so
>      transsexuals find them less useful...).
>
> But as PKI except for web-server certificates, is just a long-time promise,
> both views are equally valid at this stage. I do though see a need for a
> possible PKIX work-item to support this multi name-space, "anarchistic" type
> of PKI, and that is a way for CAs to specify what private (or public),
> name-space their issued DNs belong to.  That would preferably be a URI, like
> for XML Schemas.  Without such a specifier, we may indeed some day, get the
> Lotus Notes problem you referred to.  PIs is one way to achieve this, but I'm
> talking about a more neutral scheme as not everyone likes PIs. cheers,Anders

---

From: "Anders Rundgren" <[email-masked]>
Date: Sun, 3 Feb 2002 07:38:06 +0100

Jim,
Thanx for the information regarding DDNs!  Pardon an ignorant question: Does DDNs in effect set the name-spaces so that the aforementioned name-space contamination (Steve's Lotus Notes problem) does not occur?  I.e. there is actually no problem to solve using one of the method suggested?  Outside of the LDAP-world, I can testify that DN name-space confusion is indeed a serious problem, particularly in conjunction with non-directory-oriented applications.  It gets particularly bad when a single CA-cert/key is used to sign certificates belonging to different name-spaces and entity-types (commercial CAs usually don't do that, protecting them from this short-coming in the X509 system).  Using globally unique DNs there would be no naming problems, but as I tried to show, that may not be a very realistic option.

Anders
  ----- Original Message ----- 
  From: jim 
  To: Anders Rundgren 
  Cc: Stephen Kent ; [email-masked] 
  Sent: Sunday, February 03, 2002 05:06
  Subject: Re: Globally unique DNs - Why?

  Point of clarification.  There is a difference between the Distinguished Name (DN) and the Directory Distinguished Name (DDN).  The DN is the X.500 naming structure that goes from the root naming structure of the directory to the outer branches and leaf entry for an individual or role.  In LDAP directories, the structure is still used, but from the individual or role moving up to the root entry.  The DDN, on the other hand, is the trail of authorizations for a user moving from the issuing Certification Authority up to the root issuing authority, be it a Policy Approving Authority in a very hierarchical structure or the chief CA in a ring set up.  My experience is that confusion of the two, DN and DDN, almost always leads to lack of understanding of how the system needs to work. 
  Jim 
  Anders Rundgren wrote: 

    Steve, 

    Actually it was a little bit incorrect, as C=SE has recently been skipped, so now it is just CN=Name, serialNumber=nnnnn.  I.e. the DN became even more "private".  But one could also rightfully claim that a redundant DN item has been removed, as the certificate anyway requires knowledge of the regime (name-space) it was issued in. Although there are advantages with globally unique DNs, IMHO the number of drawbacks outnumber the advantages.  To name a few of those drawbacks: 

    cheers,
    Anders

---

From: jim <[email-masked]>
Date: Sun, 03 Feb 2002 18:13:16 -0500

Anders,
    The DN is used to find the person in the directory service so that the
electronic path to the recipient (the X.400 address) can be discerned.  The DDN
is used when checking to ensure that the certificate is valid, so I am not sure
that it has much to do with the name-space confusion, but it is used as part of
the validation process overall.  In that regard, globally unique DNs will
enhance the ability of the DDN to be completely accurate.
Jim

Anders Rundgren wrote:

>  Jim,Thanx for the information regarding DDNs!  Pardon an ignorant question:
> Does DDNs in effect set the name-spaces so that the aforementioned name-space
> contamination (Steve's Lotus Notes problem) does not occur?  I.e. there is
> actually no problem to solve using one of the method suggested?  Outside of
> the LDAP-world, I can testify that DN name-space confusion is indeed a serious
> problem, particularly in conjunction with non-directory-oriented
> applications.  It gets particularly bad when a single CA-cert/key is used to
> sign certificates belonging to different name-spaces and entity-types
> (commercial CAs usually don't do that, protecting them from this short-coming
> in the X509 system).  Using globally unique DNs there would be no naming
> problems, but as I tried to show, that may not be a very realistic
> option. Anders
>
>       Point of clarification.  There is a difference between the
>      Distinguished Name (DN) and the Directory Distinguished Name (DDN).
>      The DN is the X.500 naming structure that goes from the root naming
>      structure of the directory to the outer branches and leaf entry for
>      an individual or role.  In LDAP directories, the structure is still
>      used, but from the individual or role moving up to the root entry.
>      The DDN, on the other hand, is the trail of authorizations for a
>      user moving from the issuing Certification Authority up to the root
>      issuing authority, be it a Policy Approving Authority in a very
>      hierarchical structure or the chief CA in a ring set up.  My
>      experience is that confusion of the two, DN and DDN, almost always
>      leads to lack of understanding of how the system needs to work.
>      Jim
>
>      Anders Rundgren wrote:
>
>     > Steve,
>     >
>     >      DNs are directory distinguished names, formally. the
>     >      directory tie-in implies that a DN sequence represents a
>     >      path in a directory tree structure. X.500 assumes a
>     >      universal tree, the DIT, and thus a DN consistent with
>     >      the semantics of X.500 would be globally unique. The DIT
>     >      is not a reality, and probably will never be, but one
>     >      can still note considerable advantages to DNs that are
>     >      globally unique.  No syntactic requirement in X.500
>     >      mandates such uniqueness, any more than it mandates
>     >      common sense re what directory attributes can be used in
>     >      forming a DN. It is certainly legitimate to construct
>     >      private directory trees that would not produce globally
>     >      unique DNs. but, experience with other name spaces
>     >      (e.g., Lotus Notes name spaces) has shown that often
>     >      what was assumed to be "private" ultimately becomes more
>     >      widely connected, and the collisions that arise due to a
>     >      lack of effort to attempt to ensure global uniqueness
>     >      P.S.  I don't know from which end the example DN above
>     >      is intended to be read, but either direction yields a
>     >      pretty odd graph :-)
>     >
>     > Actually it was a little bit incorrect, as C=SE has recently been
>     > skipped, so now it is just CN=Name, serialNumber=nnnnn.  I.e. the
>     > DN became even more "private".  But one could also rightfully
>     > claim that a redundant DN item has been removed, as the
>     > certificate anyway requires knowledge of the regime (name-space)
>     > it was issued in. Although there are advantages with globally
>     > unique DNs, IMHO the number of drawbacks outnumber the
>     > advantages.  To name a few of those drawbacks:
>     >
>     >    * It probably requires something close to socialism to
>     >      establish such strictly conforming CAs
>     >    * It is in conflict with commercial disjunct name-spaces (e.g.
>     >      DUNS, VISA etc.)
>     >    * And last but not least, it leads to a fragile ID-structure,
>     >      as the global schemes typically are based on a multitude of
>     >      attributes used to identify a subject, and if any of these
>     >      change, the link to the subject is broken.  This is in
>     >      contrast to my citizen-ID that is relevant as long as I stay
>     >      a Swedish citizen.  If the CA had been a commercial CA using
>     >      a private name-space, the ID could very well survive changes
>     >      in citizenship, name, and sex (there is a gender-tag in our
>     >      citizen-IDs so transsexuals find them less useful...).
>     >
>     > But as PKI except for web-server certificates, is just a long-time
>     > promise, both views are equally valid at this stage. I do though
>     > see a need for a possible PKIX work-item to support this multi
>     > name-space, "anarchistic" type of PKI, and that is a way for CAs
>     > to specify what private (or public), name-space their issued DNs
>     > belong to.  That would preferably be a URI, like for XML Schemas.
>     > Without such a specifier, we may indeed some day, get the Lotus
>     > Notes problem you referred to.  PIs is one way to achieve this,
>     > but I'm talking about a more neutral scheme as not everyone likes
>     > PIs. cheers,Anders
>

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 04 Feb 2002 14:24:36 +0100

Anders,

> Note that the word *global* is completely absent from the

...  hence why I wondered to which "animated" discussions you refer to, 
where the (wrong) statement would have been made.

We are in strong agreement.

Denis

---

From: Stephen Kent <[email-masked]>
Date: Mon, 4 Feb 2002 10:24:45 -0500

Jim,

Could you cite the standard from which your definition of DDN comes? 
I have never heard that characterization before.

Steve