-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-ID-Asymmetric: MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDE
kMCIGA1UEChMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwh
HbGVud29vZA==,31
MIC-Info: RSA-MD5,RSA,CKqhA34ZvUxG4fBGZ6sKehNgRLL4beDw0hjo2GOWl4j
GuEQsN3pyw2D8gR16ZyFsMV3txq9Gtj+ZBRaGZIO9TH5rmkaPIXrWMF7HE7dAIrK
uo69JAf04swZrDf0XvcQQ
From the commnets I've seen so far, there is a lot of concern
over the ability to add a new (distinguihsed) attribute type without
causing lots of problems, which disappoints me a bit. I didn't
realize that this would be so big a sticking problem as you and Mike
have suggested, but I defer to your judgement here since my experience
has been with just one DSA product, where it would be trivially easy to
add the attribute.
Steve,
The addition of new attribute types and recognizing "unknown"
OID's is an area which we too have spent a fair amount of
time working on. We found the sticking point to be one of
determining the attribute syntax since this directly affects
the application's ability to compare, and hence lookup
a distinguished name.
For example, the OID for common name (2.5.4.3) has an
assigned syntax of CaseIgnoreString so an incomming dname
with CN="Paul Clark" should compare equal to the same dname
with CN="PAUL CLARK" on retrieval. With an unknown OID
the application will be unable to make the proper conversion(s).
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-----