Dr Stephen Henson <[EMAIL PROTECTED]> writes:
>If it wouldn't cause massive disruption it would be tempting to rip out the
>whole EVP stuff, make the SSL library talk PKCS#11 and then add a PKCS#11
>interface to the lower level crypto routines.
This is something I really wouldn't recommend. Although PKCS #11 is a very
nice API design, its way of thinking about how an API should look ends up
influencing the way you handle all crypto operations. If you commit to it,
you end up having to push everything through a PKCS #11-shaped hole, and
sometimes you'll find that things don't fit, or that you have to knock off
all the corners to get them to fit (PKCS #11 is a fairly low-level API
providing support for basic building-block type ops, if you've got some
special requirement which isn't satisfied by one of the building blocks,
you're toast).
Having said that, breaking OpenSSL into two parts with PKCS #11 below the
water line and everything else above it would provide a means of detaching
the crypto functionality from the protocol-specific bits of the code,
assuming you can live with the constraints of the PKCS #11 way of doing
things (I've considered this a couple of times for my own stuff, but always
found that when I looked at the details I'd run into problems doing some
things which PKCS #11 didn't allow for, and I wasn't sure that hacking a
C_Ioctl() into an existing implementation would be very nice).
There are already both commercial and freeware PKCS #11 drivers based on
SSLeay, although the last time I looked the free one still needed some work.
I've played with one or two commercial ones, and they're fairly decent,
complete implementations.
Peter.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
