From: Jueneman(_at_)gte(_dot_)com
To: Mr Rhys Weatherley <rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au>,
Rhys said, re the use of LDAP for certificate retrieval:
It is a little different. When the certificate is converted into a
string, the subject and issuer DN's lose their string tags. When you
reconstruct it, should you use PrintableString, T61String, NumericString,
IA5String, or what? Try every possible combination until the signature
verifies?
Rhys, I think you have an excellent point. I have not looked at the RFC for
LDAP, but this would clearly be unacceptable. Even after we migrate to v3, an
important part of the semantics of the DN are carried in the string tags, and
obviously it will be more important with v3.
Hi. I'm somewhat new to this discussion, having just joined when I
heard there were some questions being raised about the use of LDAP for
storing and retrieving certificates, so bear with me. I'm one of the
primary LDAP developers, and chair the IETF ASID working group which is
shepherding LDAP (and various other directory protocols) through the
standards process.
LDAP uses the string representation of distinguished names defined by
RFC 1485. This representation preserves the attribute types associated
with each RDN component. This representation of a DN should not be
confused with the "user friendly naming" specification, which in most
cases omits the attribute names. An example LDAP dn might be
cn=Tim Howes, o=University of Michigan, c=US
Such a DN should be fully reconstructable into its original form, as
carried by DAP, so one should be able to reconstruct the original DER
encoded version of the certificate and verify the signature (as Warwick
has described, I believe).
So, the summary is that LDAP should work ok for storing and retrieving
verifiable certificates. At least, this was certainly the intention
when it was designed! If there is some flaw that makes this impossible,
we would certainly want to fix it. -- Tim