Rhys:
After looking at the LDAP RFC's a little more, I've come to the conclusion
that it isn't very useful at all as a candidate lightweight CA access
protocol in its current form. Certificates are returned using a string
encoding. Except perhaps for simple v1 certificates, this means that the
signature on the certificate won't verify once the string encoding has
been de-mangled. I hold out little hope that v3 certificates would
survive such mangling. I can't as yet see a way to force LDAP to return
binary values. If I've missed anything, LDAP experts are welcome to point
it out to me.
My local LDAP expert explains it as follows. You don't need a binary encoding.
From the character-encoded fields you reconstruct the certificate, DER-encode
it, and check the signature on the DER encoding. This is not, in fact, much
different to the way you would handle a BER-encoded certificate - you need to
parse and re-encode in DER before checking.
There were apparently some problems with the certificate definition in RFC
1488,
but they have been corrected by the LDAP group in a recent revised draft. With
the move to v3 certificate, the RFC 1488 definition will presumably need to be
updated, but this is nothing unsurmountable. It might involve a
character-encoding of the octet string constituting each extension field.
(However, I would prefer to leave such decisions to the LDAP experts.)
Warwick