I was just using FIPS as one of the examples where PKCS#11 OVER OpenSSL is
a potentially better solution than the engine backends. I'm dealing with
FIPS certification issues all the time, so this was the obvious example -
it's caused me the most pain.
The other obvious problem is where you have to export crypto. code all over
the world - having the engine interface available in OpenSSL makes that
problematic.
I guess it's also potentially one less API for the hardware vendors to
support, they could just concentrate on implementing PKCS#11 - but getting
the OpenSSL PKCS#11 backend working properly would also do that. (I havn't
tried to use that, but I'm assuming from the other comments that there are
problems there now).
To make that really useful though, OpenSSL's SSL layer would have to be
capable of functioning while using PKCS#11 instead of libcrypto. Probably
possible, but it'd require some fairly major surgery. You'd really need
libcrypto. factored into "crypto" and "support" functions (like certificate
parsing/X509/OCSP etc) first.
Peter
From: "Victor B. Wagner" <[EMAIL PROTECTED]>
To: [email protected]
Date: 19/11/2007 21:03
Subject: Re: PKCS#11 wrapper around OpenSSL
On 2007.11.19 at 20:46:36 +1000, Peter Waltenberg wrote:
> There are some things that are "quite hard" problems doing it the other
way
> round. FIPS certification with the OpenSSL engine plugin active is
probably
> the worst.
> With PKCS#11 on top of OpenSSL you have an "industry standard" API, which
> most hardware cards support. So you could swap a FIPS certified hardware
> card with a FIPS certified PKCS#11 on top of OpenSSL. Using OpenSSL with
> the engine code underneath doesn't make much sense in this context.
Since 0.9.9 engine modules can add new algorithms, not only new
implementations (i.e. hardware supported) of existing algorithms.
My problem is actually to use existing implementation of GOST algorithms
(ccgost engine) in the Mozilla-based products. It seems that libnss already
includes some support for these algorithms if their implementation is
provided by PKCS#11 module.
Of course, it has nothing to do with FIPS. In this case, if we would
have to certify our solution it would be quite different certification
body. Actually, in this case we don't need certification of this module
at all (as well as ccgost engine is not certified by Russian
authorities). We need open-source implementation which can work in the
Mozilla and can be used for testing and debugging.
Really, I suppose not all users need FIPS-certified version of
cryptographic module. If server is FIPS-certified, client browser need
to be interoperable, but non neccessary certified. Suppose that client
is under another jurisdiction. It has its own certification bodies.
Or even under same jurisdiction it is not neccessary that private
person's browser has to be certified.
> Note that IBM does have an open source PKCS#11 which sits on top of
> OpenSSL, search for opencryptoki. That doesn't solve the FIPS problem
> though due to some details of it's design.
It is interesting. I'd look into it.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
