Hi I just want to give you some background information why AdNovum has choosen the let's call it the 'interceptor-way' of implementing the PKCS#11 functionality.
We are working in an environment where the main purpose of the hardware security modules (HSM) is not crypto acceleration but secure storage of private keys and trust ankers. And in may situations we have more than one (different) device active. For example one for user authentication (removable chipcard) and the other one for server/sevice authentication. The problem with the ENGINE aproach is, that if you load and register an engine for let's say RSA, the ALL RSA operations are directed to this engine. That's not what we expect. We ONLY want the RSA operations bound to the objects (keys, certs) stored on the HSM, be executed on it. Under the cover we also create an ENGINE but we do not register it, but simply use it for the key objects. Our second goal was to implement a solution which was a plug replacement for a 'normal' OpenSSL. That means there is NO need to modify any application to use PKCS#11 instead of file based keys and certs. We 'mangled' all the necessary parameters into one string (like an URL). Our idea was to open the concept of a 'file' to be a 'URL'. We simply intercepted some (by far not all) file operations and switched (hardcoded) to our pkcs#11 code if we encounter an PKCS11 prefix (protocol part of URL). If we would introduce the concept of URL's fundamentaly into OpenSSL (with loadable URL-protocol-handlers) we would gain a whole bunch of new flexibility. (the actual file stuff would be the default builtin handler, which gives complete backward compatibility). It would be possible to write an HTTP- or LDAP- handler with wich we would be able to fetch certs from a central point. Our PKCS#11 code could be put into such an URL-handler. So now I hope you can better understand the intention behind the way our code is integrated into OpenSSL. best regards Matthias > Date: Tue, 13 Aug 2002 11:56:58 +0200 (CEST) > From: Richard Levitte - VMS Whacker <[EMAIL PROTECTED]> > > [NOTE: the following are my thoughts and my thoughts only. Other > members of the OpenSSL development team may have the same opinions, or > different ones] > > OK, I've started to take a look at the PKCS#11 patches the have been > contributed. As far as I've been able to see, there are three > contributions, which I will call the "Advorum", the "Eracom" and the > "Trustway" contributions. > > I'll honestly say that I have a problem with all of them, at least as > far as I understand them (I don't know PKCS#11 that well, but I do > understand the ENGINE framework and the internals of OpenSSL :-)). > The "Eracom" and "Trustway" contributions are engines, and that's a > good thing, but are tied to a specific PKCS#11 implementation. The > "Advorum" contribution seems to be more generic (i.e. it's > specifically designed to be able to talk with any PKCS#11 libary that > comes in it's way). However, it's not designed as an engine according > to the ENGINE framework. Instead, it's hooked into the SSL library > (it seems to be only useable from there, unless one calls the provided > PKCS11 functions. I can see no hooks in the EVP layer or anything > equally useful). > > I've seen some bickering between the different contributors on the > openssl-users lists (IIRC), and I'd like to suggest the you guys stop > the bickering and try to cooperate. > > My wish (and the only thing I'll consider as something PKCS#11-related > to put into OpenSSL) is for something having the generality that the > "Advorum" contribution seems to be designed as, but as an engine (as > pure as possible. Ideally, the only changes should be in the > crypto/engine directory). If there are changes needed in the > algorithm methods, the EVP layer or the ENGINE framework, I'd like > to see it implemented in a *general* way instead of something PKCS#11- > specific, and that it's discussed with us, so we can handle it in an > appropriate way. Who knows, we might need additions to the ENGINE > framework that haven't been thought of yet (public key generation > routines, for example). > > I base everything I've said on the study of the following files: > > Advorum: pkcs11.openssl.adnovum.20010615.patch.gz > pkcs11.openssl.adnovum.20010615.tar.gz > pkcs11-adnovum-20011212.tar.gz > > Eracom: ERACopenssl-engine-0.9.6b.patch.gz > > Trustway: openssl-engine-0.9.6c-tw.patch > > Note: the contributions will not appear in 0.9.6. That branch of > OpenSSL is in freeze, and will only be updated with bug-fixes. > 0.9.7 is a different matter, I'm currently looking at things that I > can insert as demo engines to be built as dynamic libraries that can > get loaded through the "dynamic" engine. > For 0.9.8, we're discussing a change that will make the "dynamic" > engine obsolete and enhance the support of dynamically loadable > engines. +---------------------------------------------------------------------+ Matthias Loepfe mailto:[EMAIL PROTECTED] CTO dipl. El.-Ing. HTL AdNovum Informatik AG http://www.adnovum.ch phone: +41 (0)1 272 6111 Roentgenstrasse 22, CH-8005 Zuerich fax: +41 (0)1 272 6312 +---------------------------------------------------------------------+ AdNovum Software Inc. San Mateo, CA 94404 phone: +1 (650) 525 9322 1400 Fashion Island Boulevard, Suite 309 fax: +1 (650) 525 9324 +---------------------------------------------------------------------+ ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
