Subject: Re: DN comparison

From: "Tom Gindin" <[email-masked]>
Date: Tue, 11 Jun 2002 07:45:47 -0400

Laurence:

      It's no more mundane than many other questions here, and while it
might be better on an LDAP group it is certainly relevant to us.  The
primary definition is X.501v4 section 13.5 or X.501v3 section 12.5.2.  The
difficulty with the definition is the word "corresponding".  Here are a few
simple rules:
1     The order of attributes inside an RDN is irrelevant to a comparison.
You can find this in X.501v4 section 9.4.
2     The grouping of attributes within RDN's is important.  It tends to be
standardized, but it does matter.  In particular, the meaning of a few
attributes such as serialNumber and DNQualifier is not guaranteed to be the
same when grouped with a personal name as when in an RDN by themselves.
3     Whether the ordering of RDN's matters is much less clear.  It appears
that "corresponding RDN's" need to match for equality, but it isn't obvious
to me whether corresponding RDN's are ones in the same position or ones
with the same attributes.  DN's are matched as sequences of RDN's rather
than as sets.  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.

      Thus only #1 and #3 of your examples match.

            Tom Gindin

Laurence Lundblade <[email-masked]>@mail.imc.org on 06/10/2002 01:53:35
PM

Sent by:    [email-masked]

To:    [email-masked]
cc:
Subject:    DN comparison

I know this question is much more mundane than usual fair here, but I'm
going to ask anyway as I think I've done a decent job reviewing RFC's,
X.500, discussion archives, etc.

What I want to know is how to compare DN's (subject with issuer). I found
all the stuff about the string processing in 2459 and am happy to see
that's reasonably dealt with. What I can't find is whether the order of
RDN's or the order of the parts of the RDN's matter or not. Also I haven't
been able to determine if the grouping of parts in RDN's matter or not.

To be specific, which of these are the same in these DN's?
  1) (O=fish-tacos, OU=fish, OU=halibut), (CO=mexico,ST=baja)
  2) (O=fish-tacos, OU=fish), (OU=halibut), (CO=mexico), (ST=baja)
  3) (OU=halibut,O=fish-tacos, OU=fish) (ST=baja,CO=mexico)
  4) (CO=mexico), (ST=baja), (OU=halibut), (O=fish-tacos, OU=fish)

RDN's are in (). I would think/hope they're all the same. From reading the
source, it looks like OpenSSL doesn't care about the grouping of RDN's, but

does care about the order.

And more of a standard question, how should I have found the answer to this

question? From my current perspective it seems an addition to RFC-3280
would be helpful.

LL

---

From: Bruce Stephens <[email-masked]>
Date: Tue, 11 Jun 2002 17:39:59 +0100

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

[...]

> Personally, I have some difficulty understanding how two

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: Laurence Lundblade <[email-masked]>
Date: Tue, 11 Jun 2002 10:30:49 -0700

Thanks for the responses. The concept my brain glossed over was the 
difference between SET and SEQUENCE. Having that I can now make sense of 
the X.500 text.  If you take the DNS example that finance.yahoo.com is 
different from yahoo.finance.com it's pretty easy to see why ordering is 
important.

BTW, some folks, who'll remain anonymous, suggested that a straight binary 
compare of the DN's was adequate since enough implementations do it which 
motivates any cert issuer to never change the order, string types, etc. 
Given my main goal is client-side SSL on a cell phone I suspect I could get 
away with the binary compare. I don't expect to be dealing with end user 
certs, LDAP etc. It is tempting because the object code is smaller and 
because it will execute faster.

Thanks again, LL