Subject: Matching rule review comment on 3280bis

From: Stefan Santesson <[email-masked]>
Date: Wed, 29 Aug 2007 16:55:11 +0100

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: "Kemp, David P." <[email-masked]>
Date: Wed, 29 Aug 2007 14:13:28 -0400

The attributes defined by X.520 fall in several categories:

1) directoryString types that are subtypes of "name" (e.g., surname,
givenName) and inherit caseIgnoreMatch from name

2) directoryString types (e.g. dnQualifier, serialNumber) that
explicitly use caseIgnoreMatch

3) non-directoryString types (e.g. telephoneNumber, x121Address,
communicationService) that use other matching rules
(telephoneNumberMatch, numericStringMatch, objectIdentifierMatch)

No attribute in X.520 is defined to have caseExactMatch rule semantics,
therefore there is no X.520 attribute to which Kurt's concern applies.
It is possible in principle that some other standard defines an
attribute with directoryString syntax and caseExactMatch matching,
however I am not aware of any such standard.

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

If someone could point to a standard that defines a directoryString
attribute using caseExactMatch that might possibly be useful in a DN,
I'd be more inclined to support the re-wording.

Dave

  _____  

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

...

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:

Personally I think Kurt is right. I see no reason why 3280bis would need
to override the matching rules defined for each attribute.

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

Stefan Santesson

Senior Program Manager

---

From: Russ Housley <[email-masked]>
Date: Wed, 29 Aug 2007 14:54:46 -0400

The caseIgnoreMatch with white space compression rule is fine for

PrintableString.  The proposed text does not capture this
point.

I'd prefer text that invoked StringPrep only for the Unicode

string types.

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:

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

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.

“Name comparisons MUST be performed as caseIgnoreMatch with white space
compression.”

Kurt writes:

Kurt> Naming values in DNs should be compared
according to

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.

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