Eric Laroche wrote: > > Dr S N Henson wrote: > > > >Eric Laroche wrote: > >> > >> Yes, I am aware of the OpenSSL engine interface. Our code applies > >> quite similar mechanisms of feeding 'configuration' information (name/ > >> value pairs) from application code. However, the engine command > >> definitions affect the whole engine setting, whereas our configuration > >> affects an abstraction called (key) 'object specification'. Each key > >> or certificate may have quite different settings concerning where to > >> accomplish encryption and which password callbacks to be applied, etc. > >> > >> The PKCS#11 object specification / configuration seems to me to be a > >> different concept compared to the engine configuration. However, the > >> PKCS#11 interface may be seen as a 'PKCS#11' engine. > >> > > > > How could crypto acceleration or querying capabilities be handled in > > this model? > > 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. > > > I was thinking that a possible way to handle this is to map a specific > > PKCS#11 library+token to an ENGINE. This would behave a bit like the > > dynamic ENGINE in that the PKCS#11 ENGINE would be called with a set of > > init commands which would then produce a second ENGINE which would refer > > to the actual PKCS#11 implementation. > > 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. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Gemplus: http://www.gemplus.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: [EMAIL PROTECTED] PGP key: via homepage. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
