-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-ID-Asymmetric: MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDE
kMCIGA1UEChMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwh
HbGVud29vZA==,31
MIC-Info: RSA-MD5,RSA,gZZZHW1T5Na3PGbT352+EtjX4rE47iCmp7wHMZWTlJ5
XHJwggQ3Dx9Z3UilxT9hgoaA2+QRxI1Zig61q4cgfvIOrxM4RwWaDeFCRIFyVVhs
D3kSh0U7hkiY5egWZmgNv
I think Christian's point was that introducing new attribute
types for DNs into DSAs was a problem, not just DUAs, but maybe I
misunderstood. This was a concern of mine when we changed the initial
key management spec to remove attribute constraints and, instead go
with a list of attribute types for all directory applications, not
just PEM, to be maintained by the IANA, something we still have not
put in place. My general concern was that PEM UAs would not know
the name of the attribute and the syntax type and thus would not be
able to accurately label and display the attribute value.
Agreed. It is possible to display the raw OID (#.#.#.#) and the
attribute value in octal or hex, however, this is not likely to
be meaningful information to the average user.
By the way, I understand the role of matching rules
like "case ignore string" for directory searches. Could you elaborate
on how a PEM implementation needs to make use of these rules?
Steve
Presumably an implementation will have the need to retrieve
locally stored certificates by issuer dname + serial number and
by subject dname (crl's could be retrieved by issuer dname).
A local PEM database which used these values as indices would
need to "canonicalize" the dname prior to lookup or save,
since one dname may potentially have a variety of representations.
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-----