Hardware Crypto Support w/ openssl-engine (ITS#1339)

[blair+openldap@devclue.com]

Full_Name: blair christensen.
Version: 2.0.14+
OS: Solaris 8
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (128.135.0.40)


Hello,
We are currently running OpenLDAP on several Solaris/Sparc servers, which of
course do not provide a /dev/(u)random.  In the past we have used the ANDIrand
package which provides a /dev/(u)random (quality of which I'm not entirely
certain).  Now, however, we are purchasing hardware crypto cards to use on all
of our machines. 

The crypto cards do not provide a /dev/(u)random interface, but instead, using
openssl-engine, you can tell openssl to use a specific hardware engine (in our
case "cswift" but there are a few others as well) at run time (*not* compile
time).  The default is to use the "openssl" engine, which basically tells
openssl to behave normally, using a /dev/(u)random if present.

I have currently made changes such that slapd (based upon changes in
libraries/libldap/tls.c and a few other places), if given a TLSCryptEngine
configuration option in slapd.conf, will use the hardware crypto and this seems
to work.  However, I've realized that using my current methods, everything in
$PREFIX/bin, $PREFIX/libexec, and $PREFIX/sbin would probably need to be
explicitly modified to support the hardware crypto engine.  That is *ugly*.  

Which brings me to my question/RFC: Do you have any suggestions/preferences for
how I implement this (as I intend to submit all of my patches) such that is
general enough to work across all binaries?  Should the crypto engine be set at
compile time in libraries/libldap/tls.c (with a possible run time directive to
override this) or should I take a different approach?  Perhaps an option in
ldap.conf for the client tools to explicitly set the engine to use?

Thanks,
blair christensen.