Hi there,
Just a couple of thoughts on this ticket [#11].. [[EMAIL PROTECTED] - Thu May 30 17:39:08 2002]: > "Richard Levitte via RT" <[EMAIL PROTECTED]> writes: > > > 1. could this engine be considered a general PKCS#11 engine, or are > > there specific ties to Trustway. I'd prefer to see a general > > PKCS#11 engine. > > This engine is a general PKCS#11 engine. I tested it first with the > PKCS#11 library developped by Lutz Behnke (libgpkcs11.so) and > its software token (libceay_tok.so). It is possible to make a general > PKCS#11 engine and just put specific ties, if any, for multiple hardwares. > In Trustway case, the only specific tie is the name of PKCS#11 library > to load and some controls added when loading it. > Our code depends on gpkcs11 include files (cryptoki.h, pkcs11.h, ...); > it is possible to add them to our patch. It would be great to have a generic pkcs#11 ENGINE going into the base openssl source, certainly moreso than having a new one added for each particular implementation/token type. W.r.t. requiring different controls, well yes - that's the whole point of having string-based controls for ENGINEs, it lets the user/admin get any kind of settings through to any kind of ENGINE without OpenSSL having to understand it all. With Steve's recent work on (auto)configuration through openssl.cnf, arbitrary controls can be specified for loading/configuring ENGINEs on initialisation. For a generic "pkcs11" ENGINE, one of these controls of course would identify the library/driver/token/location of the corresponding device. > > 2. Those extra functions in the RSA method, are they really needed? > > I understand that they provide a lot of automagic things, but then > > it should be added in the ENGINE framework as something that would > > be potentially available for any hardware (that supports that extra > > functionality). Also, when it comes to loading keys, the current > > modus operandi is to explicitely use the ENGINE key loading > > functions rather than having some implicit functionality going on. > > The reason is that we'd prefer not to surprise the users too much. > > The Bull Trustway CC2000 isn't only a cryptographic accelerator card, > it is a high level security hardware providing key generation and storage > in secure memory. That's why we can't use ENGINE key loading functions. > Yes those extra functions are really needed when using this kind of > hardware. I'm not convinced - the nCipher support in OpenSSL works fine with their HSM keys. As for adding key generation and/or key-loading changes to *generic* parts of OpenSSL - I would much prefer we keep that issue orthogonal to the ENGINE implementations for now. Adding/changing ENGINEs is a localised process with virtually zero regression risk. Meddling with generic code risks affecting oodles of apps and users who don't even care about ENGINEs, hardware, etc. And yes I agree, they don't know what they're missing out on, but nonetheless we need to treat ENGINE development differently to how we approach changing non-ENGINE APIs. Anyhow - right now it makes sense for hardware key-generation to be handled by external hardware-specific utilities. The possible configuration requirements for arbitrary hardware is too vague to define in general terms, for now at least, and people using hardware need to have hardware-specific drivers and support software anyhow - so why not put hardware-specific key-gen utils in there with that? NB: That's not to say that some of the other points aren't important - I agree completely that it would be useful for RSA "classes" (ie. ENGINE implementations of RSA_METHOD) to have their own key-gen callback. For one thing, this would make it possible to have hardware-generated (and perhaps hardware-protected too) keys used as ephemeral/temporary keys in SSL/TLS cipher-suites. However that would immediately require that the ENGINE knows how to generate "generic" keys because you cannot possibly ask the admin to enter a smart-card and/or PIN when an in-progress SSL handshake needs an ephemeral key ... general hardware key generation could require anything the manufacturer manages to dream up; biometrics, smart cards, PINs, luck, and other equally useful tools of the trade (no cynicism, of course:-). Could you possibly resubmit a non-intrusive version of your pkcs11 engine implementation (ie. without changing other openssl code) and I'll look at integrating it. That at least will give us a base of code in the CVS snapshots for us and everyone else to work from. Perhaps a bit further down the line, we could look at opening up a independant ticket and discussion about changes to the OpenSSL APIs (extending RSA_METHOD, etc), but I don't think they need affect PKCS11 support for now. Cheers, Geoff -- Geoff Thorpe, RT/openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
