[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Matching rule review comment on 3280bis



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