In message <[EMAIL PROTECTED]> on Tue, 20 Aug 2002 10:42:51 +0200, Matthias
Loepfe <[EMAIL PROTECTED]> said:
Matthias.Loepfe> I just want to give you some background information
Matthias.Loepfe> why AdNovum has choosen the let's call it the
Matthias.Loepfe> 'interceptor-way' of implementing the PKCS#11
Matthias.Loepfe> functionality.
Matthias.Loepfe>
Matthias.Loepfe> We are working in an environment where the main
Matthias.Loepfe> purpose of the hardware security modules (HSM) is not
Matthias.Loepfe> crypto acceleration but secure storage of private
Matthias.Loepfe> keys and trust ankers. And in may situations we have
Matthias.Loepfe> more than one (different) device active. For example
Matthias.Loepfe> one for user authentication (removable chipcard) and
Matthias.Loepfe> the other one for server/sevice authentication.
Matthias.Loepfe>
Matthias.Loepfe> The problem with the ENGINE aproach is, that if you
Matthias.Loepfe> load and register an engine for let's say RSA, the
Matthias.Loepfe> ALL RSA operations are directed to this
Matthias.Loepfe> engine. That's not what we expect. We ONLY want the
Matthias.Loepfe> RSA operations bound to the objects (keys, certs)
Matthias.Loepfe> stored on the HSM, be executed on it. Under the cover
Matthias.Loepfe> we also create an ENGINE but we do not register it,
Matthias.Loepfe> but simply use it for the key objects.
OK. I haven't done this myself, but I'm fairly sure that it's
possible to load an engine and NOT have the RSA operations hooked in.
The only thing I'm not sure of is how HSM-stored keys will be
handled. It's possible that this is a needed enhancement of the
ENGINE framework... Remember that I said that enhancements to the
ENGINE framework can and should be discussed? The ENGINE framework
works for what it's been built with so far, and definitely needs
further work to be able to addapt to things like your PKCS#11 wishes.
So I'd say, let's discuss it and play with thoughts and code and see
if we can come up with something that safe, works, and doesn't break
current functionality (at least too much :-)).
Matthias.Loepfe> Our second goal was to implement a solution which was
Matthias.Loepfe> a plug replacement for a 'normal' OpenSSL. That means
Matthias.Loepfe> there is NO need to modify any application to use
Matthias.Loepfe> PKCS#11 instead of file based keys and certs. We
Matthias.Loepfe> 'mangled' all the necessary parameters into one
Matthias.Loepfe> string (like an URL).
Matthias.Loepfe>
Matthias.Loepfe> Our idea was to open the concept of a 'file' to be a
Matthias.Loepfe> 'URL'. We simply intercepted some (by far not all)
Matthias.Loepfe> file operations and switched (hardcoded) to our
Matthias.Loepfe> pkcs#11 code if we encounter an PKCS11 prefix
Matthias.Loepfe> (protocol part of URL).
You may have seen that we have implemented something similar in a more
general sense, as string-based control commands and the possibility
for complex identities. As it works now, it's basically only for
engine loading, but we might use your mathod for operation-level
control commands, or something similar to the current complex engine
identity.
Matthias.Loepfe> If we would introduce the concept of URL's
Matthias.Loepfe> fundamentaly into OpenSSL (with loadable
Matthias.Loepfe> URL-protocol-handlers) we would gain a whole bunch of
Matthias.Loepfe> new flexibility. (the actual file stuff would be the
Matthias.Loepfe> default builtin handler, which gives complete
Matthias.Loepfe> backward compatibility). It would be possible to
Matthias.Loepfe> write an HTTP- or LDAP-handler with wich we would be
Matthias.Loepfe> able to fetch certs from a central point.
Hmm, that's something to think about. I've been playing with the
thought, and it has also been discussed here or on openssl-users, of
having enhanced storage engines (I think LDAP-based certificate and
key storage was discussed back then).
I do understand your choices. I just have a very hard time seeing it
fit into our code as is. The way I see it, the ENGINE framework is
the way to go, and that's where needed changes should go.
--
Richard Levitte \ Spannv�gen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47
\ SWEDEN \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Unsolicited commercial email is subject to an archival fee of $400.
See <http://www.stacken.kth.se/~levitte/mail/> for more info.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
