Lutz Behnke wrote:
>
> thank you for the post. There are some good idea in that code.
> Unfortunately I cannot use it as intented, since it only patches
> the RSA methods. This is the way to go if you only want to add rsa
> support. We do this on a lower level to have our pkcs11 implementation
> talk to the SC about rsa.
>
> I plan to add PKCS11 directly to SSL, allowing any cryptographic
> method availiabl on the token to be used by the library. This will
> start with RSA, thus seem to make the point moot, but it allows
> for much more flexible and clean insertion of PKCS in the code (IMO)
>
> In order to do this I think, I need to remove all non-evp RSA/DSA/DH
> calls
> from the ssl code. I am wondering whether there is any reason why this
> is not
> a GoodThing.
>
I think this is a good thing but the current OpenSSL EVP stuff isn't
really up to the task there are some other issues as well.
Making the EVP stuff up to the task is IMHO a very good thing.
You might get away with it just for SSL but in general you might have
problems.
Firstly there is the way the EVP stuff works. You tend to have an
EVP_CIPHER structure to describe each cipher. In the case of algorithms
like RC2 this means you have a cipher structure with 40, 64 and 128
bits. The cipher explicitly defines the key length and effective number
of bits. If you want anything other than those supplied you have to do
some nasty low level cipher specific stuff that goes outside EVP. Some
kind of EVP_Cipher_ctrl or such like for cipher specific tweaks would
help.
Another problem is how you 'clone' a context, that is make an
independent copy. One way to do this is to just copy the context
structure. If you do that it will break PKCS#11 because the two would
not be independent. What is needed is some kind of EVPCipherClone and
EVPDigestClone functions and strong recommendations that that is the
*only* supported method and of course fixing broken older code that just
copies the structure.
Another issue is how you would use token objects. Currently IMHO OpenSSL
is rather lacking in this area. All you can really do load in files,
anything else tends to involve an application manually setting up the
necessary callbacks.
What is really needed is a way to reference objects (in particular
private keys) in a general way without an application having to support
them. There is partial support for this kind of thing in X509_STORE but
it is lacking in some areas.
Let me give a random example of how this might work based on something
analagous to URLs. If a private key was needed from a file it could pass
something like file://path/to/filename.pem . If a PKCS#11 private key
was needed it could do pkcs11://other/stuff/to/reference/it. Similarly
somthing like pkcs12://path/to/file.p12 for PKCS#12. The applicaton
doesn't know or need to know anything about PKCS#11, PKCS#12 or the
files: all it needs to know is that it gets back an EVP_PKEY structure
it can use.
What would happen at a lower level is that an individual 'driver' would
register the 'protocol' string (e.g. "pkcs11" in one example) and
process the passed path in some way returning an EVP_PKEY structure set
up to do the right thing.
Going one step further the 'driver' need not even be linked into the
OpenSSL library: it could be loaded as a shared library which would then
register itself.
To do this properly would need an expansion of the the way X509_STORE
works or possibly replacement with something more flexible.
Steve.
--
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant.
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [EMAIL PROTECTED]
NOTE NEW (13/12/98) PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
