-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-ID-Asymmetric: MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDE
kMCIGA1UEChMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwh
HbGVud29vZA==,31
MIC-Info: RSA-MD5,RSA,bBQMiQ6F90f8rBT5LIrEde9jQEtpfJef7pfdR9mLNlk
dFw/8vnrQTC/UlmCzYuRMlCe0M/RITwIzM9oBwtVcQml0akOMJZ+z4gX6FD92fwU
WpgwE9cZ1UuoQrjBGR6Fb
Paul,
My point was exactly that the DER do not include any rules for
modifying the values of attributes, and the canonicalization you are
describing does involve such modification. Hence the question is
whether there can legitimately exist two distinct DNs that differ in
terms of, for example, capitalization, and which thus are equivalent
in terms of the directory serach rules, but which represent different
entries. If so, then it would be an error to use the search rules for
automatically select a certificate from a cache with an issuer DN that
is not exactly identical to the issuer DN in a received message, but
which does match under the search rules. In general, it would seem
dangerous to declare two DNs equivalent when they match under
search rules but really are not identical.
Steve
Steve,
I agree that X.500 naming is potentially messy business. However,
if two dnames refer to the same object in a directory then I think
it is imperative that a PEM implementation recognize this equivalence
when accessing its locally stored certs and CRLs during message processing.
More importantly, an issuer must take care that a requested subject name
does not refer to a distinct object when creating a certificate.
Thus an implementation must be able to properly compare equivalent
dnames -- according to the X.500 rules.
Paul
_________________________________
Paul Clark
Trusted Information Systems, Inc.
3060 Washington Road
Glenwood, MD 21738
E-Mail: paul(_at_)tis(_dot_)com
Phone: 301.854.6889
FAX: 301.854.5363
_________________________________
-----END PRIVACY-ENHANCED MESSAGE-----