Hi there, Sorry I haven't piped up before, but I've been too busy to contribute anything of worth to the discussion.
On Wednesday 16 January 2002 12:15, Dr S N Henson wrote: > Eric Laroche wrote: > > Querying capabilities (PKCS#11 calls them 'mechanisms') is already > > implemented in the code's lower level routines. However, since at the > > moment, only asymmetric ciphers access is implemented, a protocol of > > asking all capabilities and setting methods accordingly wasn't yet so > > much an issue. > > I was thinking that this works fairly well if an OpenSSL ENGINE is > mapped to a specific PKCS#11 library and token. The capabilities would > then map to the supported PKCS#11 methods of that token. > > Its not so clear how this would be handled if multiple libraries or > tokens are mapped onto a single ENGINE, perhaps with the same mechanism > supported by multiple tokens. The latter wouldn't really be possible in the form ENGINE is in. Specifically, it is not like the object approach of RSA and friends - where the object itself contains state and a pointer to a method, being essentially the vtable of class functions. An ENGINE object itself is a vtable of functions and state, all in one. So it's more like an instance of a class rather than an instance of an object. The ENGINE_FLAGS_BY_ID_COPY flag was created to be used in the "dynamic" ENGINE to address this - rather than one class of a ENGINE for use by each key/context that needs it, it allowed a new instance of the ENGINE to be created (with its own reference counts, state, etc) each time it was required. In the case of "dynamic" - this is obviously necessary as each one will become, given appropriate commands, a different class altogether when it loads up and binds the shared-library ENGINE implementation. As each "dynamic" ENGINE may go different ways, they needed to be different instances. But any ENGINE that is going to need to maintain state outside of keys/contexts - ie. storing the state *OF* the ENGINE itself and the commands issued to it by the user/application - will need to take a similar approach. The PKCS#11 implementation is an obvious candidate - to access keys, login, etc etc etc ... that may require commands to be issued from the user/application, and may require state to be accumulated in the implementation - if that state is not application global but should be localised to each instance, then this is one way of dealing with that. The alternatives seem grim. > > This sounds like a reasonable approach to a part of the desired > > OpenSSL PKCS#11 - ENGINE integration. > > > > The dynamic engine method resolution may need to be extended or > > complemented, to allow method dispatching on a key basis. This has, > > in our code, been done outside the actual engine code, but the > > (dynamic) engine code might be a more suited place for that. > > Well I wasn't thinking of modifying the dynamic ENGINE as such just > using a method analagous to the dynamic approach. For example any > application which would use such an PKCS#11 ENGINE might do something > like this: > > Lookup engine called "PKCS11", this would give the application a copy of > the PKCS#11 ENGINE. > > Send ctrl commands to the copy, giving details of the token name, ENGINE > name to use(if needed), whether to add to list, PKCS#11 library location > etc. With some defaults like using the first token found if none > specified. > > Send a LOAD ctrl command, this would load the PKCS#11 library, look for > the token name and map such things as mechanisms to OpenSSL methods. > > At this point the ENGINE would become a "real" engine which would map > onto a specific PKCS#11 library and token. > > This would enable things like ENGINE_load_private_key() to lookup a > specific key based solely on its CKA_LABEL for example, rather than > requiring all the parameters in the key_id argument. It would also allow applications to remain largely ignorant of what possible parameters/commands might be issued against the PKCS#11 engine to get it to do whatever is needed - which is a good thing. This approach also provides some light at the end of the tunnel too for another holy grail - generalised hardware key-generation. RSA_METHOD obviously needs to be enhanced to support key generation as a "virtual function". But how to parameterise that adequately to support every conceivably way it might be required (in every conceivable ENGINE) was the problem - some devices will require the user/application to log in, some will support untold options, settings, etc. If the ENGINE itself is instantiated for each key/context (bearing in mind a key structure can be empty prior to key generation), then the key-generation step could itself be quite simple - any advanced prepping could be done beforehand through arbitrary control commands. Cheers, Geoff ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
