Subject: DN comparison

From: Laurence Lundblade <[email-masked]>
Date: Mon, 10 Jun 2002 10:53:35 -0700

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: "David A. Cooper" <[email-masked]>
Date: Mon, 10 Jun 2002 16:27:21 -0400

At 10:53 AM 6/10/02 -0700, Laurence Lundblade wrote:

>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.
>
>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.

The DNs that you list are not all the same. I believe that 1 and 3 are the same, but the others are not. A DN is defined in X.509 as follows (see section 4.1.2.4 in RFC 3280):

            Name ::= CHOICE {
              RDNSequence }

            RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

            RelativeDistinguishedName ::=
              SET OF AttributeTypeAndValue

            AttributeTypeAndValue ::= SEQUENCE {
              type     AttributeType,
              value    AttributeValue }

            AttributeType ::= OBJECT IDENTIFIER

            AttributeValue ::= ANY DEFINED BY AttributeType

A DN is a SEQUENCE of RDNs. So, in order to two DNs to be the same, they must contain the same RDNs in the same order. Each individual RDN is a SET of attribute-type and value pairs. Since an RDN consists of a SET of AV pairs, the ordering of the pairs is unimportant (note, however, that DER requires the AV pairs in an RDN to be encoded in a specific order).

In your examples above, DNs 2 and 4 contain the same set of RDNs, however, the RDNs are not in the same order. Since a DN is a SEQUENCE of RDNs, the different ordering makes them different DNs. While DNs 1 and 2 contain the same set of AV pairs, the RDNs are not the same.

So, the general rule is as follows:

1) Two DNs are the same if they contain the same sequence of RDNs (note that the order of the RDNs in the DN counts).
2) Two RDNs are the same if the contain the same set of AV pairs (order of AV pairs within RDN not important)
3) Two AV pairs are the same if their Attribute types (i.e., OIDs) are the same and their attribute values match according to the matching rules for the corresponding attribute type (e.g., directoryString).

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 11 Jun 2002 13:46:55 -0400

Laurence:

>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.

I agree that a companion document would be useful.

Russ

---

From: David Chadwick <[email-masked]>
Date: Thu, 27 Jun 2002 00:19:38 +0100

Sorry for being late in on this, but here's my two penneth.

>   1) (O=fish-tacos, OU=fish, OU=halibut), (CO=mexico,ST=baja)

Illegal DN. YOu are not allowed to have the same attribute type twice in
an RDN

>   3) (OU=halibut,O=fish-tacos, OU=fish) (ST=baja,CO=mexico)

Illegal DN

> RDN's are in (). I would think/hope they're all the same. 

Sorry. None of them are the same. The reason is that ordering is
important, just as in DNS names.

Also, to clear up the confusion over the word "corresponding". Once you
know that RDN ordering is important within a DN (a DN is a SEQUENCE of
RDNs), then the meaning of corresponding also becomes clear. It has the
normal English meaning that the nth RDN in one DN corresponds with the
nth RDN in another DN. Its that simple.

David

>From reading the

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: +44 161 295 5351  Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************