On Fri, Jul 20, 2007 at 12:04:18PM -0400, Patrick Patterson wrote: > Hi Hadmut; > > On Friday 20 July 2007 11:05:37 you wrote: > > On Fri, Jul 20, 2007 at 04:32:08PM +0200, Bernhard Froehlich wrote: > > > Of course it would be possible (though probably a good bit of coding > > > work) to use a LDAP library like OpenLDAP to fetch the certificates and > > > then use them with OpenSSL library functions. > > > > > > Hope it helps. > > > > Not really, this was just the obvious facts. Doing it yourself is what > > always works. > > > > But since storage of certificates in an LDAP tree is state of the art and > > more natural than /etc/ssl/certs (keep in mind that originally these X.509 > > certificates were intended to protect and to be stored in a X.500 > > directory, which of LDAP is a subset), I wonder why this had never been > > implemented.
Possibly because everyone is waiting for you to contribute the code. :-/ > Well, I believe that it was done this way because the OpenSSL /etc/ssl/certs > is just the Unix way of implementing the concept of the Trust Anchor store. > The thing is that since those certificates are "trust anchors", then it would > be highly insecure to not have these certificates locally, and if the user Define "locally". In my LDAP server behind my firewall is one arguably reasonable definition of "locally". > was to have them locally in a local LDAP Server, then they would need to have > an LDAP server that was configured for a very large namespace (it would have > to, in essence, mirror Verisign's, Global Trusts, and all of the other > Certificate authorities LDAP namespace). Okay, why? > Consequently, it is probably highly > undesirable to store these trust anchors as something other than a series of > CA certificates Tell Novell and Microsoft, who've been storing certificates in their directory products since late last century. > (think what would happen if you were to look up these > certificates somewhere other than locally, and someone were to spoof the DNS > entry... since you are looking up these certificates to make a trust > decision, it would be possible for an attacker to spoof both the CA and the > end entity certificates, and that would be a VERY BAD THING :) Well, that's what DNSSEC is for. Not to mention mutual authentication between the directory and client. I don't see why this CANNOT be secured. I agree that it takes careful attention to detail if it is to be secured. -- Mark H. Wood, Lead System Programmer [EMAIL PROTECTED] Typically when a software vendor says that a product is "intuitive" he means the exact opposite.
pgpZJcxMK3gG2.pgp
Description: PGP signature
