Salz, Rich wrote:
>
> >There are two related uses PKCS#11 could be used for in OpenSSL. As a
> >standard for crypto operations and as a standard for a key and
> >certificate database: basically a sophisticated version of X509_LOOKUP.
>
> In my opinion, the first is desireable. The second, less so. But I
> probably don't understand the rationale for PKCS11 as a DB API.
> Can you explain it a bit more?
Well as I said the two uses are related. If it was just a case of
finding a way to store keys, certificates and CRLs in a "conventional"
database then there wouldn't be too many problems.
In the case of keys the storage of a key can be related to the crypto
operations it performs. In a typical hardware implementation the key
will be unextractable, but it will have some kind of identifier which
can be used to perform operations on it. In the case of RSA keys, the
RSA_METHOD can be redirected to these calls and the RSA structure can be
used just like a "normal" RSA structure except the sensitive components
aren't accessible.
This transparency is IMHO highly desirable. An application shouldn't
need to know or care where its private keys (or certificates) come from
it should just be able to look them up and use them. Currently an
application has to handle this stuff itself: maybe with separate code
for DER, PEM or PKCS#12 format keys of certificates. If it needs to
handle hardware keys then it has to do all the work itself including
messing round with the RSA_METHOD structure.
In the case of PKCS#11, the crypto functionality is there (but with the
problem of lack of parallel functionality) unfortunately there aren't
quite enough attributes and a few other "quirks" that don't easily
interface with the OpenSSL "model" for the database. The OpenSSL model
itself has enough "quirks" of its own.
So in the case of a database I was considering PKCS#11 because its one
of the models I know quite well it is also tantalisingly close to what
is needed but not quite there alas.
I suspect in the end there will be no choice but to invent a new
cryptographic API: expecting something to slot cleanly into the OpenSSL
model (which itself is unique) is asking rather a lot. However this
doesn't force anyone to use it or learn the API: at some point a PKCS#11
"module" could be added that can talk to any PKCS#11 compatible library.
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Celo Communications: http://www.celocom.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]
