Subject: Re: DN comparison

From: "Frank Balluffi" <[email-masked]>
Date: Mon, 10 Jun 2002 18:01:31 -0400

Laurence,

In the following ASN.1, a SEQUENCE OF is ordered and a SET OF is not ordered:

   Name ::= CHOICE {
     RDNSequence }

   RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

   RelativeDistinguishedName ::=
     SET OF AttributeTypeAndValue

1) and 3) contain two RDNs, each of which contain the same AttributeTypeAndValues. Because the RDNs are in the same order, 1) and 3) are equal.

2) and 4) contain the same four RDNs, but the RDNs are in different order. So 2) and 4) are not equal.

Frank

---------------------------------------- Message History ----------------------------------------

From:  Laurence Lundblade <[email-masked]>@mail.imc.org on 06/10/2002 10:53 AM MST

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

--

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

---

From: Torsten Hentschel <[email-masked]>
Date: Tue, 11 Jun 2002 17:34:36 +0200

Tom:

My interpretation of section 9.7 of X.501 is, that it states
indirectly, that two names having just a different ordering of
RDN's are different, because it defines a distinguished name
as an ordered sequence where the order is the decending order
of all its superior entries plus its own. Thus changing the sequence
would denote a different hierarchy of the superior entries.
Because an object entry can have multiple distinguished names
(section 9.1.3) changed sequence does not neccessarily mean
that the corresponding object is a different as well.
I totally agree with you that in real life most cases
would not need a sequence. But im sure there are some,
where it makes sense, *and* enforcing a sequence looks
great for me as a programmer, because otherwise search algorithms
become greedy.

  Torsten

Tom Gindin wrote:

> [...]
> The difficulty with the definition is the word "corresponding".
> [...]
>   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.

---

From: Sharon Boeyen <[email-masked]>
Date: Wed, 12 Jun 2002 10:53:16 -0400

Just to close one loop in this discussion, I want to let you know that
although X.509 
didn't have any specific text on this topic previously that is being changed
and the following
changes are being made in current working document. This ties the matching
of DNs in 509 
to the X.501 matching rule and outlines where the matches occur. Note that
this applies 
regardless of whether or not those DNs in certificates ever get instantiated
as directory 
entries.

Here are the upcoming changes to X.509 on this topic:

1 The following text will be added to clause 7 of X.509:

The distinguishedNameMatch matching rule, defined in 13.5.2 in ITU-T Rec.
X.501|ISO/IEC 9594-2, is used to compare the Distinguished Name (DN) in the
issuer field of one certificate with the DN in the subject field of another.

2 In clause 8.6.2.2, the following will be added as a new paragraph
immediately following the paragraph that begins with "The distributionPoint
component contains.":

If the certificate in question contains a cRLDistributionPoints extension
and the CRL contains an issuingDistributionPoint extension, at least one
name for the distribution point as indicated in the certificate shall match
a name for the distribution point as indicated in the CRL. Note that in both
the certificate and CRL there are default names that may apply to the
distribution point, namely the DN of the CRL issuer (found in the issuer
field of the CRL). Also, it may be the case that only the
nameRelativeToCRLIssuer field is present. In that case, a name comparison
would be done on the full DN, constructed by appending the value of the
nameRelativeToCRLIssuer to the DN found in the issuer field of the CRL.  If
the names being compared are DNs (as opposed to names of other forms within
the GeneralNames construct), the distinguishedNameMatch matching rule is
used to compare the two DNs for equality.
  
3 In clause 8.4.2.2, the following will be added as a new paragraph
immediately following the paragraph that begins with "The maximum field
specifies the lower bound ."

For the directoryName name form, a certificate is considered subordinate to
the base 
(and therefore a candidate to be within the subtree) if the SEQUENCE of
RDNs, which forms the full DN in base, is identical to the initial SEQUENCE
of the same number of RDNs which forms the first part of the DN in the
subject field of the certificate. The DN in the subject field of the
certificate may have additional trailing RDNs in its sequence that do not
appear in the DN in base.

The distinguishedNameMatch matching rule is used to compare the value of
base  with the initial sequence of RDNs in the DN in the subject field of
the certificate.

-----Original Message-----
From: Laurence Lundblade [mailto:[email-masked]]
Sent: Wednesday, June 12, 2002 10:39 AM
To: Tom Gindin; Bruce Stephens
Cc: [email-masked]
Subject: Re: DN comparison

At 07:54 AM 6/12/2002 -0400, Tom Gindin wrote:
>       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 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

---

From: "Tom Gindin" <[email-masked]>
Date: Wed, 12 Jun 2002 16:26:14 -0400

Sharon:

      IMHO the thing which most needs to be clarified in this regard is not
in X.509 at all, but rather the term "corresponding RDN" in section 13.5.2
of X.501(and also in section 9.4).  Is the "corresponding RDN" of a given
RDN in the presented DN the RDN which occupies the same position or is it
the RDN which has the same set of attribute types (with a caveat about
attribute types which occur more than once in a DN)?  Until that's cleared
up, references to the matching rule may not make the responsibilities of an
implementor any clearer.
      Laurence's example with multiple occurrences of the OU attribute is
the closest I've seen to a plausible example in which re-ordering RDN's
could cause two DN's which really refer to different entities to match
inappropriately.  Following one of his hints, a similar and slightly
stronger example could be constructed with multiple occurrences of the DC
attribute as well (DC=com, DC=company, DC=fr vs. DC=fr, DC=company, DC=com
representing the quite legal DNS names fr.company.com and com.company.fr).
However, AFAIK nobody has shown an example in which re-ordering RDN's with
different attribute structures would do this.
      If I were to locate the "corresponding RDN" by a heuristic which said
that two RDN's correspond if they have the same set of attribute types and
if any of those attribute types occur more than once in a DN, the relative
position of the occurrence of the attribute type in each DN is the same, I
would not produce any obviously perverse results but I would match C=CA,
ST=ON, L=Ottawa, O=Entrust with C=CA, O=Entrust, ST=ON, L=Ottawa.  I think
that's why we need clarity as to whether this heuristic is required,
permitted, or forbidden as an interpretation of the term corresponding RDN
within distinguishedNameMatch.

            Tom Gindin

Sharon Boeyen <[email-masked]> on 06/12/2002 10:53:16 AM

To:    "'Laurence Lundblade'" <[email-masked]>, Tom
       Gindin/Watson/IBM@IBMUS, Bruce Stephens
       <[email-masked]>
cc:    [email-masked]
Subject:    RE: DN comparison

Just to close one loop in this discussion, I want to let you know that
although X.509
didn't have any specific text on this topic previously that is being
changed and the following
changes are being made in current working document. This ties the matching
of DNs in 509
to the X.501 matching rule and outlines where the matches occur. Note that
this applies
regardless of whether or not those DNs in certificates ever get
instantiated as directory
entries.

The distinguishedNameMatch matching rule, defined in 13.5.2 in ITU-T Rec.
X.501|ISO/IEC 9594-2, is used to compare the Distinguished Name (DN) in the
issuer field of one certificate with the DN in the subject field of
another.

a name for the distribution point as indicated in the CRL. Note that in
both the certificate and CRL there are default names that may apply to the

-----Original Message-----
From: Laurence Lundblade [mailto:[email-masked]]
Sent: Wednesday, June 12, 2002 10:39 AM
To: Tom Gindin; Bruce Stephens
Cc: [email-masked]
Subject: Re: DN comparison

LL

---

From: Sharon Boeyen <[email-masked]>
Date: Thu, 13 Jun 2002 09:41:36 -0400

DNs are hierarchical names (again regardless of whether they appear in a 
directory or not) and corresponding RDNs are RDNs that are in the same 
position of that hierarchy (in the same position in the sequence of the
syntax).
The attribute types that happen to be used in RDNs are completely irrelevant

from the standpoint of determining which RDNs are 'corresponding'. However,
the 
attribute type&value pair(s) that appear within corresponding RDNs (in the
same element
of the SEQUENCE) must be the same. The order of those attribute type&value
pairs within 
a specific multivalued RDN does not need to be the same, but the order of
RDNs in the DN
must be the same. 
 
If that needs clarification, I'm sure we can add a note to 501 through a
defect 
report. I copied Erik (the editor & ITU Rapporteur) and Hoyt (the ISO
Rapporteur and 
DR registrar) to see if we can get the DR going. 

Sharon

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]]
Sent: Wednesday, June 12, 2002 4:26 PM
To: Sharon Boeyen
Cc: 'Laurence Lundblade'; Bruce Stephens; [email-masked]
Subject: RE: DN comparison

      Sharon:

            Tom Gindin

-----Original Message-----
From: Laurence Lundblade [mailto:[email-masked]]
Sent: Wednesday, June 12, 2002 10:39 AM
To: Tom Gindin; Bruce Stephens
Cc: [email-masked]
Subject: Re: DN comparison

LL

---

From: "Tom Gindin" <[email-masked]>
Date: Fri, 14 Jun 2002 18:00:16 -0400

Sharon:

      Clearly, your answer among my alternatives is that treating
"corresponding" to mean "with the same set of attribute types" is
forbidden, even after making that interpretation workable by matching the
attribute type and relative position within occurrences of that type
instead of the attribute type alone.  The term "corresponding" does not
unambiguously mean "in the same position".  It could equally well mean
"matching the same criterion", and I was suggesting a criterion which would
give slightly more useful semantic results than the rule which is used for
directory lookup.
      I hope this will be an adequate explanation of why X.501needs to be
clarified.  If it isn't, somebody might implement an interpretation of the
matching rule similar to the one I suggested.

            Tom Gindin

Sharon Boeyen <[email-masked]> on 06/13/2002 09:41:36 AM

To:    Tom Gindin/Watson/IBM@IBMUS, Sharon Boeyen
       <[email-masked]>
cc:    "'Laurence Lundblade'" <[email-masked]>, Bruce Stephens
       <[email-masked]>, [email-masked], "Erik
       Andersen (E-mail)" <[email-masked]>
Subject:    RE: DN comparison

The attribute types that happen to be used in RDNs are completely
irrelevant

Sharon

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]]
Sent: Wednesday, June 12, 2002 4:26 PM
To: Sharon Boeyen
Cc: 'Laurence Lundblade'; Bruce Stephens; [email-masked]
Subject: RE: DN comparison

      Sharon:

implementor any clearer.

            Tom Gindin

component contains.":

the base

-----Original Message-----
From: Laurence Lundblade [mailto:[email-masked]]
Sent: Wednesday, June 12, 2002 10:39 AM
To: Tom Gindin; Bruce Stephens
Cc: [email-masked]
Subject: Re: DN comparison

LL

---

From: Sharon Boeyen <[email-masked]>
Date: Mon, 17 Jun 2002 09:01:57 -0400

Tom I agree that it should be clarified in 501 and will follow up with 
Hoyt/Erik to get a DR started.

Thanks, 

Sharon

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]]
Sent: Friday, June 14, 2002 6:00 PM
To: Sharon Boeyen
Cc: Hoyt L. Kesterson II; Erik Andersen; 'Laurence Lundblade'; Bruce
Stephens; [email-masked]
Subject: RE: DN comparison

      Sharon:

            Tom Gindin

Sharon

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]]
Sent: Wednesday, June 12, 2002 4:26 PM
To: Sharon Boeyen
Cc: 'Laurence Lundblade'; Bruce Stephens; [email-masked]
Subject: RE: DN comparison

      Sharon:

implementor any clearer.

            Tom Gindin

component contains.":

the base

-----Original Message-----
From: Laurence Lundblade [mailto:[email-masked]]
Sent: Wednesday, June 12, 2002 10:39 AM
To: Tom Gindin; Bruce Stephens
Cc: [email-masked]
Subject: Re: DN comparison

LL

---

From: Sharon Boeyen <[email-masked]>
Date: Thu, 27 Jun 2002 11:30:59 -0400

David, fyi I have asked Erik/Hoyt to initiate a DR to clarify the meaning 
of corresponding. I agree we can process that in the Sept mtg.

-----Original Message-----
From: David Chadwick [mailto:[email-masked]]
Sent: Thursday, June 27, 2002 10:35 AM
To: Tom Gindin
Cc: Laurence Lundblade; [email-masked]
Subject: Re: DN comparison

Tom Gindin wrote:
> 
>       David:
> 
>       Corresponding's normal English meaning is not "in the same order as"
> but either "in agreement or conformity with" or "similar or analogous to".

Or "matching" as well in my dictionary. I would have thought that to
match something you would have to be in the same order. 1 3 5 does not
match 5 3 1 does it?

> Neither of these meanings is notably closer to "in the same order as" than
> to "having the same structure".  While I know that X.500 databases are
> tree-structured and so RDN order is crucial to finding entries in them, I
> do not think that matching certificate subjects based on an
order-dependent
> rule is more useful than doing so on a structure-dependent rule (i.e. one
> which considers that the order of distinct attribute types such as L and O
> is irrelevant). 

This is where we have another semantic drift. Stucture rules in X.500
are the part of the schema that determine the ordering of RDNs in a DN.
So the structure of a DN and the ordering of RDNs in a DN are
essentially the same thing.

Thus the ordering of L and O attribute types is almost always relevant
in a DN, since a DN is a SEQUENCE of RDNs, which implies ordering. The
only exception is if they are in the same RDN (which comprises a SET of
attribute types, in which case no order exists). 

> Nobody else has thought that this wording was particularly
> clear, even though it appears in an X.500 standard and X.500 implies a
tree
> structure.

I have never had a problem with the wording, probably because I helped
to write it. You often need someone not intimately involved with a
standard to be able to pick up its ambiguities and lack of clarity. So
if you can suggest some alternative wording I will take it to the next
X.500 in September for consideration.

regards

David

> 
>             Tom Gindin
> 
> David Chadwick <[email-masked]>@mail.imc.org on 06/26/2002
> 07:19:38 PM
> 
> Sent by:    [email-masked]
> 
> To:    Laurence Lundblade <[email-masked]>
> cc:    [email-masked]
> Sorry for being late in on this, but here's my two penneth.
> 
> Laurence Lundblade wrote:
> >
> Illegal DN. YOu are not allowed to have the same attribute type twice in
> an RDN
> 
> 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
> 
> *****************************************************************

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

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

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