Subject: Re: DN comparison

From: "Tom Gindin" <[email-masked]>
Date: Wed, 12 Jun 2002 07:54:54 -0400

Bruce:

      I know, and I think many of us do, that a DN's original use is as an
index to an X.500 or LDAP entry, that these are tree-structured databases,
and that DN's are defined in X.501 as ordered sets (or sequences) of RDN's.
However, I would like to see someone come up with a plausible example of
two DN's which consist of different orderings of the same set of RDN's
while referring to different entities.  Your point about directory access
properties is valid, but is hardly relevant to a comparison of two
different DN's.
      In any case, if a DN is assigned as part of a certificate issuance
process, and that certificate is then published using the procedures in
draft-ietf-pkix-certstore-http, the directory structure are not strongly
involved in the processing of that certificate at any stage of its life
cycle.

            Tom Gindin

Bruce Stephens <[email-masked]> on 06/11/2002 12:39:59
PM

To:    Tom Gindin/Watson/IBM@IBMUS
cc:    Laurence Lundblade <[email-masked]>, [email-masked]
Subject:    Re: DN comparison

"Tom Gindin" <[email-masked]> writes:

[...]

> Personally, I have some difficulty understanding how two
> DN's which differ only in the RDN sequence can refer to different
objects,
> at least in those common cases in which DN's consist essentially of
> locality attributes, organizational attributes, and personal attributes.
> However, that's how section 9.7 of X.501 seems to want it.

Because in the X.500 world (and LDAP world), the DN says how you find
an entry in a tree, so the RDNs are very much ordered.

Presuming a little-endian representation, my entry in our directory
(which may or may not be linked usefully into whatever you might
easily access, because there isn't really a global Directory) is
"cn=Bruce Stephens,l=Richmond Office, o=MessagingDirect, c=CA".  And
internal to our directory, things are definitely stored in a tree, and
I can look at the l=Richmond Office, o=MessagingDirect, c=CA entry and
see how many subordinate entries it has (our directory implementation
keeps that as a pseudo attribute).  The administrative properties are
also arranged hierarchically, so l=Richmond Office,..., might have
separate administrative properties (including a separate set of
administrators) to l=Edmonton Office,..., for example (although I
can't remember if they actually do).

In short, the DN model sort of presumes a global directory---a tree
which gives a unique name to everything that you might want to give a
name to, and that name can point to an entry in the global directory
which you can find (possibly, depending on permissions) and interact
with (possibly), by following defined processes from your local
directory.  And all of this has features for delegated administration,
shadowing (to allow for more local copies of data), chaining (to allow
you to find things that aren't stored locally), and so on.

The global directory never really happened, and probably never can,
but that's why the ordering in RDNs matters: because it's showing the
reader how to follow a path down a tree, and the naming of attributes
at the various levels is a delegated consideration, although there are
some conventions.

[...]

--
Bruce Stephens
[email-masked]
ACI Worldwide/MessagingDirect        <URL:http://www.MessagingDirect.com/>

---

From: Bruce Stephens <[email-masked]>
Date: Wed, 12 Jun 2002 13:28:55 +0100

Tom Gindin <[email-masked]> writes:

>       I know, and I think many of us do, that a DN's original use is
> as an index to an X.500 or LDAP entry, that these are
> tree-structured databases, and that DN's are defined in X.501 as
> ordered sets (or sequences) of RDN's.  However, I would like to see
> someone come up with a plausible example of two DN's which consist
> of different orderings of the same set of RDN's while referring to
> different entities.

It's tricky to come up with examples, yes.  If an organisation did use
DNs such that reordering RDNs would cause confusion, then probably
they're doing something confusing.

> Your point about directory access properties is valid, but is hardly
> relevant to a comparison of two different DN's.

From a theoretical point of view the history is important, because
distinguished names come from that background, and are still used
there, and have their own comparison rules.  If PKI uses them
differently, then there's a significant opportunity for confusion.

> process, and that certificate is then published using the procedures
> in draft-ietf-pkix-certstore-http, the directory structure are not
> strongly involved in the processing of that certificate at any stage
> of its life cycle.

That's true.  In such a situation, probably there should be an
alternative to a DN, and so comparisons would be performed on that
alternative identification (which would have its own rules for
comparison).

[...]

-- 
Bruce Stephens			[email-masked]
ACI Worldwide/MessagingDirect	<URL:http://www.MessagingDirect.com/>

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 12 Jun 2002 07:39:20 -0700

>properties is valid, but is hardly relevant to a comparison of two

In the DNS world order is pretty important as seen from my previous example 
of finance.yahoo.com vs yahoo.finance.com. It's more of a big deal in the 
DNS world though I think because the parts of the domain name aren't 
tagged. Given that hint how about this example?

(ou=finance)(ou=it)(o=moderatelyconfused)
(ou=it)(ou=finance)(o=moderatelyconfused)

IT can have it's own finance department and finance can have it's own IT 
department.

On the parsing implementation side dealing with a SEQUENCE is easier than a 
SET as someone already mentioned. Dunno about the server/CA side 
implementation.

Didn't seem that anyone is seriously considering changing this, but the 
fact that it could matter, that a change would complicate implementations a 
little, and a change would add more confusion (let me personally serve as 
an example of confusion :-), it seems a change would be very bad.

LL