|
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: Conforming implementations MUST use the
LDAP StringPrep profile, as specified in [RFC 4518], as the basis
for comparison of distinguished 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:
owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Stefan Santesson 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. |