Hi Victor,
Not sure if this is a useful response, but here it is anyway!
In the context of both this thread and your other I had two key
difficulties in making pkcs#11, OpenSSL and apache play well together:
The first lay in the the fight to make the later two meet the
requirement that there be exactly one application library context per
process [p 17 PKCS #11 v2.2 6.6.1]. Given you are talking about apache
support of some kind, that problem remains regardless of whether you are
"under" or "over" openssl.
The second was password management, apache mod_ssl is *very* wedded to
PEM files and password protection thereof. For my case (Hardware
Security Modules) I simply wanted to turn it all off. In your case you
may be looking at providing coverage for all the password management
cases that are presently supported by apache. The httpd-dev list can
definitely better advise you on this one. IMV it is far from trivial.
http://www.mail-archive.com/[EMAIL PROTECTED]/msg36902.html
http://issues.apache.org/bugzilla/show_bug.cgi?id=42687
http://issues.apache.org/bugzilla/show_bug.cgi?id=42688
To be clear, I am _not_ an apache developer nor even a contributer. I
once upon a time submitted a patch (commercially sponsored) and I don't
believe its gathered any interest from the community.
Other notes from the trenches:
* I found the lifecycle api and internal reference counting model used
by openssl's internals excessively complicated to deal with.
* Just precisely how some of openssl's process global state interacts
with apache's process, worker threads and shared memory is something I
still don't understand.
* Using bang up to date (trunk) apache for feasabillity work is a good idea.
* Pick a single apache MPM and don't bother about the others.
My guess is that this thread really belongs on http-dev, but in my view
the issues of mod_ssl development straddle many camps.
Best of luck ;-)
Robin
Victor B. Wagner wrote:
I was asked by one user if we are planning to provide PKCS#11 module,
based on OpenSSL (it was in the context of adding GOST algorithms
support to the Mozilla-based software).
I doubt is this solution is technically feasable.
As far as I know, most people do it other way around - write interfaces
which allow to USE PKCS#11 modules from within OpenSSL. I've seen at
least two engines which interface external PKCS#11 modules, and both are
incomplete, so if there is a PKCS#11 module which implements new public
key algorithm, they wouldn't allow to use it.
But question is - is it a good idea to write PKCS#11 module which uses
OpenSSL (with all its engine support) for cryptography and supports
everything OpenSSL supports.
I haven't studied PKCS#11 specification in great detail - it is very huge.
From the first glance it looks like just a big enough coding effort -
OpenSSL contains all neccessary cryptography routines and ASN.1 support
to provide PKCS#11 interface.
May be someone on this list hav dug a bit deeper in the PKCS#11
specification and can give more arguments pro or contra?
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
