-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-ID-Asymmetric: MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDE
kMCIGA1UEChMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwh
HbGVud29vZA==,31
MIC-Info: RSA-MD5,RSA,dplkfoucRpcYuqce2OCIfvCq1+zg8gDsiHgKcxbScub
BrEH8vko/q3hvf0cd0pobVw5s8GO4HAClX590S3SqLLOZ5slgT6DPkWGubsWQNyo
z7vYWpMuxwywBMb6AC/Mq
Paul,
I belive the canonical representation of a DN is specified by
the DER and the search rules you describe do not affect that
representation. I've seen nothing in the discussion of certificate
processing that would call for cannonicalization of the attribute
values within a subject or issuer DN in a certificate as part of
checking a signature. Thus I interpret your comment as relevant to
local processing relative to a search requested by the user through
his interface, rather than based on any incoming certificate info,
e.g., from a received PEM message or from a DUA transaction. In that
context, I would expect it to be more useful to map from local aliases
and DNS names to certificates, a feature that seems to be sorely
lacking in all of the PEM implementations I've seen to date.
Steve,
Unfortunately, I think the DER only affect the ordering of the AVAs
within each RDN. The problem I thought we were discussing pertains
to the canonicalization of attribute *values* based upon OID syntax.
Please help me out here if I am mistaken.
An implementation may not wish to assume that the issuer+serial
which appears in a PEM header will exactly match what is stored
in the local database. Therefore some process of canonicalization
for attribute values is required if the database is to be keyed
by issuer+serial.
With regard to aliasing,I cannot speak for implementations other
than our own which uses aliases of the form:
paul(_at_)tis(_dot_)com/CN=US/ST=MD/O=Trusted Information Systems/
OU=Glenwood/CN=Paul C. Clark/
These mappings can be stored in ~/.pemalias and are used
both when sending confidential messages and by administrative
tools. Please note that since the dname values are generally
user-entered, it is important to canonicalize these values
prior to lookup as well.
I hope this helps,
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-----