Re: Matching rule review comment on 3280bis

["David A. Cooper" <[e-mail]>]

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.