Subject: Re: Matching rule review comment on 3280bis

From: Sam Hartman <[email-masked]>
Date: Fri, 07 Sep 2007 15:28:31 -0400

>>>>> "Russ" == Russ Housley <[email-masked]> writes:

    Russ> The caseIgnoreMatch with white space compression rule is
    Russ> fine for PrintableString.  The proposed text does not
    Russ> capture this point.  I'd prefer text that invoked StringPrep
    Russ> only for the Unicode string types.

Russ, it's my understanding that both the existing 7.1 and the new
text invoke the ldap preparation algorithm for everything.  Am I
missing something or are you proposing additional changes that go
beyond fixing Kurt's comment?  It's fine if you are, I'm just trying
to understand the discussion.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Fri, 07 Sep 2007 15:26:47 -0400

>>>>> "Kemp," == Kemp, David P <[email-masked]> writes:

    Kemp,> If the goal is to be completely general, then the suggested
    Kemp,> rewording of the last paragraph would be better.  However,
    Kemp,> if the goal is to give useful, practical advice to
    Kemp,> developers, the existing wording is better. Just as a
    Kemp,> compiler optimizes out dead code, the ?override? optimizes
    Kemp,> out attributes that do not exist.

The problem here is that I don't think certificates are limited to
attributes defined in x.520 or for that matter even defined in any
standard at all.  At least as I read 3280, I can potentially use an
attribute specific to my organization in a certificate.

My preference as an individual is to be completely general in the text
and provide appropriate additional guidance where that would help
implementations.

As an AD, I require that the spec be accurate.  It is inappropriate to
describe something as a clarification of ldap's preparation algorithm
if it is not in fact a clarification.  So, if the WG is going to keep
the current text it needs to at least make clear that it is not simply
a clarification of the ldap algorithm.

--Sam

---

From: Tim Polk <[email-masked]>
Date: Fri, 7 Sep 2007 16:45:51 -0400

My initial take on this thread matched David Kemp's.  I did a little  
more
research and now I agree with Sam.  It turns out that PKIX documents
specify at least one attribute for naming where the matching rule is
caseExactMatch: pseudonym.

As a result, we do need some rewording to cover both cases.  I will  
try to
propose language on Monday.  (I am too burned out to reread 4518 and
get the text right at this point on a Friday... and just couldn't get  
to it earlier
in the week.)

Tim

---

From: Kurt Zeilenga <[email-masked]>
Date: Sat, 8 Sep 2007 08:48:14 +0200

On Aug 29, 2007, at 8:54 PM, Russ Housley wrote:

> The caseIgnoreMatch with white space compression rule is fine for
> PrintableString.

What's formally "white space" in PrintableString?

> The proposed text does not capture this point.
> I'd prefer text that invoked StringPrep only for the Unicode
> string types.

As designed, LDAPprep applies to the particular rules regardless of  
which DirectoryString choice is made.  However, note that the  
LDAPprep specification says that implementations only need to match  
the behavior of the specified algorithm.  That is, an implementation  
may "short cut" the specified algorithm in the PrintableString  
choice, or various other cases, so long as the resulting matching  
behavior is the same.

As an implementor, I will simply note that one needs to be careful in  
what short-cuts one make.

-- Kurt

>
> Russ
>
> At 11:55 AM 8/29/2007, Stefan Santesson wrote:
>> Kurt Zeilenga spotted a problem in section 7.1 of 3280bis and Sam  
>> asked us to discuss it in the WG.
>>
>> 3280bis states in 7.1:
>>
>> 7.1  Internationalized Names in Distinguished Names
>>
>>    Representation of internationalized names in distinguished  
>> names is
>>    covered in sections 4.1.2.4, Issuer Name, and 4.1.2.6, Subject  
>> Name.
>>    Standard naming attributes, such as common name, employ the
>>    DirectoryString type, which supports internationalized names  
>> through
>>    a variety of language encodings.  Conforming implementations MUST
>>    support UTF8String and PrintableString.  RFC 3280 required only
>>    binary comparison of attribute values encoded in UTF8String,  
>> however,
>>    this specification requires a more comprehensive handling of
>>    comparison.  Implementations may encounter certificates and  
>> CRLs with
>>    names encoded using TeletexString, BMPString, or  
>> UniversalString but
>>    support for these is OPTIONAL.
>>
>>    Conforming implementations MUST use the LDAP StringPrep  
>> profile, as
>>    specified in [RFC 4518], as the basis for comparison of  
>> distinguished
>>    name attributes of type DirectoryString.  Name comparisons MUST be
>>    performed as caseIgnoreMatch with white space compression.
>>
>> The problem is with the last sentence
>> “Name comparisons MUST be performed as caseIgnoreMatch with white  
>> space compression.”
>>
>> While all attributes commonly used with X.509 have CaseIgnoreMatch  
>> as matching rule. X.520 allows DirectoryString encoded attributes  
>> to also have CaseExcactMatch.
>>
>> Kurt writes:
>>
>>     Kurt> Naming values in DNs should be compared according to
>>     Kurt> equality matching rule of the attribute.
>>
>>     Kurt> You might simply ask the PKIX WG to explain why they think
>>     Kurt> it appropriate to use the caseIgnoreMatch rule semantics  
>> for
>>     Kurt> attributes defined to have caseExactMatch rule semantics.
>>
>> Personally I think Kurt is right. I see no reason why 3280bis  
>> would need to override the matching rules defined for each attribute.
>> For attributes, encoding and matching rules are defined separately.
>>
>> A better wording of the last paragraph might be:
>>
>>    Conforming implementations MUST use the LDAP StringPrep  
>> profile, as
>>    specified in [RFC 4518], as the basis for comparison of  
>> distinguished
>>    name attributes of type DirectoryString.  Name comparisons MUST be
>>    performed according to the equality matching rule of each  
>> attribute type.
>>
>>
>> Stefan Santesson
>> Senior Program Manager
>> Windows Security, Standards
>>

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 9 Sep 2007 00:55:02 +0100

Tim,

I have proposed a text to the PKIX list, you may want to take a look at that.

Stefan Santesson
Senior Program Manager

> -----Original Message-----
> From: Tim Polk [mailto:[email-masked]]
> Sent: den 7 september 2007 22:46
> To: Sam Hartman
> Cc: Kemp, David P.; Stefan Santesson; pkix
> Subject: Re: Matching rule review comment on 3280bis
>

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 10 Sep 2007 10:42:28 -0400

I fully agree that PKIX specifications should be technically accurate
and consistent with other standards, and remain concerned that
my recommendation might conflict.  However, I believe it is
a desirable goal for Distinguished Name matching in PKIX applications
be uniformly case-insensitive.  What would it be like if DNS names were
as complex as DNs - for example TLDs were case-sensitive but other DCs
were
not - Sun.com matches sun.com but does not match Sun.COM?  What would it
be like if PKIX applications were forced to carry DNs in BER format
rather
than flattening them into single strings because some
currently-undefined
attribute might come along and require special case-matching treatment
for some portions?

As I understand it, RFC 4511 - 4519 specify the operation of directory
systems, whereas RFC 3280 does not constrain (and thus cannot conflict
with) the operation of directories.  I would hope a way could be found
to permit PKIX applications to perform case-insensitive matching for
purposes of, e.g., DN chaining or Issuer/Serial dereferencing, while
admitting the possibility that some chainable certificates might not
be found in a directory search if a case-exact-matching attribute were
ever defined and used in DNs.

Is it possible to word RFC 3280bis so that it can simultaneously 
leverage RFC 4518 from LDAP, use pure case-insensitive matching for
non-directory DN operations, and not conflict with LDAP's (potentially
case-exact) matching for directory operations?  If so, I believe that
is a desirable goal.

V/R,
Dave

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Friday, September 07, 2007 3:27 PM
To: Kemp, David P.
Cc: Stefan Santesson; pkix
Subject: Re: Matching rule review comment on 3280bis

--Sam

---

From: Tim Polk <[email-masked]>
Date: Mon, 10 Sep 2007 12:42:54 -0400

Well, I'm confused now too.  RFC 2985 includes the following text:

   5.2.9 Pseudonym

    The pseudonym attribute type shall contain a pseudonym of a subject.
    The exact interpretation of pseudonyms is intended to be  
specified by
    certificate issuers etc.; no particular interpretation is required.

    pseudonym ATTRIBUTE ::= {
            WITH SYNTAX DirectoryString {pkcs-9-ub-pseudonym}
            EQUALITY MATCHING RULE caseExactMatch
            ID id-at-pseudonym
    }

    Note - The pseudonym attribute has received an object identifier in
    the joint-iso-itu-t object identifier tree.

    The caseExactMatch matching rule is defined in [8].

Things get curiouser and curiouser...

Tim

On Sep 10, 2007, at 11:57 AM, Kemp, David P. wrote:

> Tim,
>
> I'm confused.  X.520 appears to say that "pseudonym" is a subtype
> of "name", which uses caseIgnore:
>
>   5.2.10 Pseudonym
>     The Pseudonym attribute type specifies a pseudonym for an object.
>     It is used for naming an object when it is to be made clear that
>     its name is a pseudonym.
>
>     pseudonym ATTRIBUTE ::= {
>       SUBTYPE OF name
>       WITH SYNTAX DirectoryString {ub-pseudonym}
>       ID id-at-pseudonym }
>
> Dave
>
>
>
> Sent: Friday, September 07, 2007 4:46 PM
> To: Sam Hartman

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 10 Sep 2007 11:57:36 -0400

Tim,

  5.2.10 Pseudonym

Dave

-----Original Message-----
From: Tim Polk [mailto:[email-masked]] 
Sent: Friday, September 07, 2007 4:46 PM
To: Sam Hartman
Cc: Kemp, David P.; Stefan Santesson; pkix
Subject: Re: Matching rule review comment on 3280bis

Tim

---

From: Sam Hartman <[email-masked]>
Date: Mon, 10 Sep 2007 14:00:21 -0400

>>>>> "Kemp," == Kemp, David P <[email-masked]> writes:

    Kemp,> I fully agree that PKIX specifications should be
    Kemp,> technically accurate and consistent with other standards,
    Kemp,> and remain concerned that my recommendation might conflict.
    Kemp,> However, I believe it is a desirable goal for Distinguished
    Kemp,> Name matching in PKIX applications be uniformly
    Kemp,> case-insensitive.  

I'm not entirely sure this is consistent with X.509 but do not know
X.509 well enough to comment one way or another.

Assuming that it is consistent with X.509 and assuming that it is
consistent with the definitions of the attributes that you use, then
making PKIX be case insensitive is something that the WG could choose
to do.

I think you'd need to do so with different text than is currently in
the draft.

---

From: Russ Housley <[email-masked]>
Date: Mon, 10 Sep 2007 17:47:46 -0400

>to understand the discussion.

I think that Section 7.1 is describing the processing for UTF8String.

For PrintableString, I think "caseIgnoreMatch with white space 
compression" is straightforward.  Based on the question from Kurt in 
this thread, it might deserve a sentence or two, but I would not put 
it in a section with a heading of "Internationalized Names in 
Distinguished Names."

Russ

---

From: Russ Housley <[email-masked]>
Date: Mon, 10 Sep 2007 17:32:02 -0400

>What's formally "white space" in PrintableString?

PrintiableString includes upper and lower case letters, digits, 
space, apostrophe, left and right parenthesis, plus sign, comma, 
hyphen, full stop, solidus, colon, equal sign, and question 
mark.  The only "white space" character in this list is space.  My 
understanding is that some code also look for tab characters because 
not every encoder makes sufficient checks to ensure that 
inappropriate characters are prevented from being included.

>what short-cuts one make.

I do not know how to trim the white space in some situations.  In 
PrintableString I do.  How is that a short-cut?

Russ

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 11 Sep 2007 11:40:19 +0200

> X.509 well enough to comment one way or another.

I'm sure it is inconsistent with X.509.  X.509 uses X.500 dnMatch,  
which uses X.500 rdnMatch, which uses the equality rule for the  
naming attribute.  Using caseIgnoreMatch when X.500 calls for some  
other rule to be used is simply wrong.

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 11 Sep 2007 11:33:56 +0200

On Sep 10, 2007, at 11:32 PM, Russ Housley wrote:

> hyphen, full stop, solidus, colon, equal sign, and question mark.   
> The only "white space" character in this list is space.

Note I said "formally".  While it might be viewed as obvious with  
PrintableString what characters are or are not "white space"  
characters, the pre-LDAPprep specifications of caseIgnoreMatch/ 
caseExactMatch were not precise as to which characters were  
considered white space (or spaces).  They basically left it to  
implementors to choose which code points were spaces, which code  
point case folded to the same character, etc..

> My understanding is that some code also look for tab characters  
> because not every encoder makes sufficient checks to ensure that  

This "some code" hints at the interoperability problems that LDAPbis  
WG was trying to address in revising these rules.

> PrintableString I do.  How is that a short-cut?

The LDAP specification detail how to apply caseIgnoreMatch regardless  
of which choices were made in the two involved DirectoryString  
values.   An implementation knowing that two involved strings are  
both of the PrintableString choice, can short the transcode to  
Unicode, apply some equivalent preparation in PrintableString space  
for octet wise matching or otherwise perform the matching.  As long  
as the behavior of this "short-cut" was the same as the specified  
algorithm, all is fine.  But note that the burden to ensure the short- 
cutted algrorithm is equivalent to the specification lies upon the  
implementor.

-- Kurt

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 11 Sep 2007 11:50:57 +0100

Fine with me.

Stefan Santesson
Senior Program Manager

> Sent: den 11 september 2007 12:46
> To: Stefan Santesson
> Cc: Tim Polk; Kemp, David P.; pkix; Kurt Zeilenga
> >>>>> "Stefan" == Stefan Santesson <[email-masked]> writes:
>
>     Stefan> However the wording I proposed works for me:
>
>     Stefan>    Conforming implementations MUST use the LDAP StringPrep
>     Stefan> profile, as specified in [RFC 4518], as the basis for
>     Stefan> comparison of distinguished name attributes of type
>     Stefan> DirectoryString.  Name comparisons MUST be performed
>     Stefan> according to the equality matching rule of each attribute
>     Stefan> type.
> See section 1.3 of RFc 4518.  It is not a stringprep profile; it is
> based on stringprep.
>
> How about  replacing the first sentence with:
>
> Conforming implementations MUST use the rules for preparing
> internationalized directory strings  for comparison as specified in
> [RFC4518].

---

From: Sam Hartman <[email-masked]>
Date: Tue, 11 Sep 2007 06:46:01 -0400

Conforming implementations MUST use the rules for preparing internationalized directory strings  for comparison as specified in [RFC4518].

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 11 Sep 2007 11:03:22 +0100

Tim,

We have simply caught an error in RFC 2985. This should trigger a process to fix 2985 with an errata.
RFC 2985 is not authoritative over the pseudonym attribute, X.520 is, and in X.520 this attribute is simply a subtype of name.

However, I don't think this should be a concern of 3280bis.
I see no reason for 3280bis to mandate a matching rule in section 7 as matching rules are individually defined for different attributes.
3280bis could have an informative text explaining that most common attributes (or a list of common attributes) use the caseIgnoreMatch matching rule.

However the wording I proposed works for me:

   Conforming implementations MUST use the LDAP StringPrep profile, as
   specified in [RFC 4518], as the basis for comparison of distinguished
   name attributes of type DirectoryString.  Name comparisons MUST be
   performed according to the equality matching rule of each attribute type.

Stefan Santesson
Senior Program Manager

> Sent: den 10 september 2007 18:43
> To: Kemp, David P.
> Cc: Sam Hartman; Stefan Santesson; pkix

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 11 Sep 2007 08:29:56 -0400

Well this seems conclusive.   I was hoping (frankly without
much expectation of success) for a loophole that would permit
intuitive and simple DN matching behavior (e.g. the way rfc822
and DNS name matching works), but it appears there is none.

Dave

-----Original Message-----
From: Kurt Zeilenga [mailto:[email-masked]]

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 11 Sep 2007 17:31:49 +0200

On Sep 11, 2007, at 2:29 PM, Kemp, David P. wrote:

> intuitive

Sorry, but I see nothing intuitive of matching an attribute by some  
rule other than its specified equality rule.

> and simple DN matching behavior (e.g. the way rfc822

If an implementation only supports a limited set of attributes (such  
as those listed by some applicability statement), and none of these  
attributes rely on caseExactMatch rule for equality matching, then  
obviously the implementation need not implement caseExactMatch.

That is, the technical specification should be designed for the  
general case.  Implementors however need only implement the  
applicable portions of a technical specification, such as detailed in  
an applicability statement.

-- Kurt

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 11 Sep 2007 12:58:02 -0400

-----Original Message-----

--------------------------

That is because you view (as does X.500) DNs as a collection of general
attributes.  If the creators of X.500 had had the foresight to treat
Distinguished Names specially by restricting entry names to using only
attributes subtyped from "name", then it would be intuitive to regard
Distinguished Names as a homogeneous hierarchical space rather than the
heterogeneous space permitted by the standard.

Filesystems permit *files* to contain any type of content (word,
pdf, video, etc), but do not permit *filenames* of type "image/jpeg"
for example.  The same is true of web content vs. URIs.  X.500 has
the only namespace I am aware of that permits name components
(RDNs) of unrestricted type.  I don't see any possible value of
allowing directory entries to have RDNs of type "protocolInformation"
(X.520 5.9.3), for example, yet X.500 permits them.  The design
philosophy of complete generality has a significant cost, and
good engineering would have balanced cost against required
functionality while developing the standard rather than deferring
such fundamental decisions to community-specific applicability
statements.

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 12 Sep 2007 11:40:21 -0400

The standard should not specify different rules for attributes of

type PrintableString (such as dnQualifier and serialNumber) than for

attributes of type DirectoryString encoded using the PrintableString

choice.  I agree with Russ that StringPrep is unnecessary for

PrintableString because there is only one unambiguous whitespace

character, but I don't believe that treating PrintableString specially

in RFC 3280bis reduces complexity.  Conforming implementations must

include the StringPrep code and must produce the results specified by

StringPrep.  To minimize execution time, code could bypass StringPrep

processing in cases (such as PrintableString) where it can be

guaranteed to have no effect on the answer.

I have two concerns with the proposed last paragraph:

* It does not require attributes of type uTF8String to use StringPrep.

  No such attributes are defined in X.520, but they are theoretically

  possible.

* It requires applications to support attribute comparison using

  caseExactMatch (as well as attribute-specific matching rules).

  No such attributes are defined in X.520, but they are theoretically

  possible.

The following text addresses these concerns:

   name attributes encoded in any of the DirectoryString types.

   Conforming implementations MUST support name comparisons using

   caseIgnoreMatch.  Support for attribute types that use other equality

   matching rules is optional.

Dave

  _____  

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson
Sent: Wednesday, August 29, 2007 11:55 AM

   performed according to the equality matching rule of each attribute
type.

---

From: Russ Housley <[email-masked]>
Date: Wed, 12 Sep 2007 14:07:43 -0400

Dave your text is an improvement, but don't you think that the trimming
of leading and trailing white space deserves mention?

Russ

At 01:48 PM 9/12/2007, Kemp, David P. wrote:

The standard should not specify
different rules for attributes of

character, but I don’t believe that treating PrintableString
specially

in RFC 3280bis reduces complexity.  Conforming implementations
must

include the StringPrep code and must produce the results specified
by

StringPrep.  To minimize execution time, code could bypass
StringPrep

* It does not require attributes of type uTF8String to use
StringPrep.

No such attributes are defined in X.520, but they are
theoretically

possible.

caseExactMatch (as well as attribute-specific matching
rules).

No such attributes are defined in X.520, but they are
theoretically

possible.

name attributes encoded in any of the DirectoryString
types.

Conforming implementations MUST support name comparisons
using

caseIgnoreMatch.  Support for attribute types that use
other equality

Dave

From: [email-masked]
[
mailto:[email-masked]] On Behalf Of Stefan
Santesson

name attributes of type DirectoryString.  Name
comparisons MUST be

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 13 Sep 2007 09:27:39 -0400

Russ,

I optimized it out because it seemed redundant, but don't have any

objection to mentioning it explicitly, for example:

   Conforming implementations MUST use the LDAP StringPrep profile

   (including insignificant space handling), as specified in

   [RFC 4518], as the basis for comparison ...

For PrintableString the first five steps of StringPrep (Transcode,

Map, Normalize, Prohibit, Check bidi) can be bypassed completely,

but the sixth step (Insignificant Space Handling) is required for

all DirectoryString types.  Although RFC 4518 canonicalization

is a bit more verbose than strictly necessary for non-wildcard

equality matching (exactly 1 leading and trailing space and

exactly 2 internal spaces, vs. the traditional no leading/trailing

and 1 internal space), there isn't a downside to using it is there?

Dave

  _____  

From: Russ Housley [mailto:[email-masked]] 
Sent: Wednesday, September 12, 2007 2:08 PM
To: Kemp, David P.; pkix
Subject: RE: Matching rule review comment on 3280bis

Russ

---

From: Russ Housley <[email-masked]>
Date: Thu, 13 Sep 2007 14:02:24 -0400

You are right, but I think it adds very few words to include the
"(including insignificant space handling)" part.

Russ

At 09:27 AM 9/13/2007, Kemp, David P. wrote:

Russ,

I optimized it out because it seemed redundant, but don’t have any

profile

(including insignificant space handling), as specified
in

and 1 internal space), there isn’t a downside to using it is there?

Dave

From: Russ Housley
[
mailto:[email-masked]]

To: Kemp, David P.; pkix

Russ

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 26 Sep 2007 11:18:59 -0400

All,

Below is the text that I propose for section 7.1 of 3280bis.  I have 
included the entire section below, for context, even though changes are 
proposed for only the second and third paragraphs.

This proposal is essentially the text from David Kemp's email, but with 
the following changes:

1) The first sentence of the second paragraph states that LDAP 
StringPrep MUST be used as the basis for comparison of attributes 
encoded in PrintableString and UTF8String, rather than for any of the 
DirectoryString types, since the first paragraph states that conforming 
implementations are only required to support PrintableString and UTF8String.

2) In order to make the third paragraph consistent with the second 
paragraph, I added the phrase "using the caseIgnoreMatch matching rule", 
in order to clarify that the third paragraph does not apply when an 
attribute specifies a different matching rule.

3) In the second bullet in the third paragraph, "Removal" was changed to 
"Handling" in order to correct the title of section 2.6.1 of RFC 4518.

In the text below, those portions of the text where changes are proposed 
have been underlined.

If you have any comments on this proposed change, please submit them to 
the list by Wednesday, October 3.  If there are no objections by that 
point, I will post a new draft with the modified text.

Thanks,

Dave

----------------------------------------------------------------------------------------
7.1  Internationalized Names in Distinguished Names

   Representation of internationalized names in distinguished names is
   covered in sections 4.1.2.4, Issuer Name, and 4.1.2.6, Subject Name.
   Standard naming attributes, such as common name, employ the
   DirectoryString type, which supports internationalized names through
   a variety of language encodings.  Conforming implementations MUST
   support UTF8String and PrintableString.  RFC 3280 required only
   binary comparison of attribute values encoded in UTF8String, however,
   this specification requires a more comprehensive handling of
   comparison.  Implementations may encounter certificates and CRLs with
   names encoded using TeletexString, BMPString, or UniversalString but
   support for these is OPTIONAL.

   Conforming implementations MUST use the LDAP StringPrep profile
   _(including insignificant space handling)_, as specified in [RFC 4518],
   as the basis for comparison of distinguished name attributes _encoded in
   either PrintableString or UTF8String_.  _Conforming implementations
   MUST support name comparisons using caseIgnoreMatch.  Support for
   attribute types that use other equality matching rules is optional_.

   Before comparing names _using the caseIgnoreMatch matching rule_,
   conforming implementations MUST perform the six step string
   preparation algorithm described in [RFC 4518] for each attribute of type
   DirectoryString, with the following clarifications:

      *  In step 2, Map, the mapping shall include case folding as
      specified in appendix B.2 of [RFC 3454].

      *  In step 6, Insignificant Character Removal, perform white space
      compression as specified in section 2.6.1, Insignificant Space
      _Handling_ of [RFC 4518].

   When performing the string preparation algorithm, attributes MUST be
   treated as stored values.

   Comparisons of domainComponent attributes MUST be performed as
   specified in section 7.3.

   Two naming attributes match if the attribute types are the same and
   the values of the attributes are an exact match after processing with
   the string preparation algorithm.  Two relative distinguished names
   RDN1 and RDN2 match if they have the same number of naming attributes
   and for each naming attribute in RDN1 there is a matching naming
   attribute in RDN2.  Two distinguished names DN1 and DN2 match if they
   have the same number of RDNs, for each RDN in DN1 there is a matching
   RDN in DN2, and the matching RDNs appear in the same order in both
   DNs.  A distinguished name DN1 is within the subtree defined by the
   distinguished name DN2 if DN1 contains at least as many RDNs as DN2,
   and DN1 and DN2 are a match when trailing RDNs in DN1 are ignored.