In an earlier message I discussed what I saw as a serious deficiency
in OpenSSL: its lack of a key, certificate and CRL database API. In this
message I'll mention more info and the general API requirements and why
the nearest thing we have at present is not adequate IMHO.
There is already a partial solution which is currently under
utilised. That is X509_LOOKUP_METHOD. This is an API which allows
certificate stores to be set up and use various lookup techniques. As
usual this isn't very well documented but the stuff in crypto/x509,
(particularly x509_vfy.h, x509_lu.c, by_file.c, by_dir.c) and the
behaviour of applications like apps/verify.c gives some idea of how this
could be used.
There is some unimplemented or under used code which looks like it could
handle lookups of CRLs, and private keys as well.
It doesn't quite fit all the requirements unfortunately. Some of the
enhancements needed are considerable so there are really two options.
1. Radically enhance the X509_LOOKUP_METHOD structure.
2. Add a totally new API e.g. X509_DB.
Here are some of the ways in which X509_LOOKUP_METHOD is suitable.
1. A user will want to refer to a certificate or private key using some
"friendly name" which will typically be a human readable string. The
method 'get_by_alias' seems to be suitable for this.
2. The software will need to retrieve matching private keys for
certificates (when available). This can be handled by either the
"get_by_alias" or "get_by_fingerprint" with the requirement that
matching keys and certificates have the same value.
3. Various kinds of lookup are needed for general SSL and (for example)
S/MIME use, typically lookup by subject name or issuer and serial
number. Both of these can be readily handled.
Here are some of the problems with using X509_LOOKUP_METHOD as it
stands.
1. There is no way to determine the "properties" of an object, that is
after retrieving a certificate you can't find the associated alias for
example.
2. The API will only return one object based on the lookup criteria. It
is possible that a user might have different objects with the same
criteria: for example the same subject name with several certificates
from different CAs.
3. There is no general method to 'enumerate' all the objects of a given
type in a store. There are several situations where this is either
desirable or essential. Examples include presenting a list of acceptable
certificates to a user or finding a list of acceptable CAs for SSL
client authentication.
4. There is no way to lookup by other methods, for example lookup by
subject key id (needed for proper certificate chain verification) or
lookup by issuer name (needed to find matching certificates in an SSL
client when authentication is requested). To add new lookup methods you
need to add new function pointers to the X509_LOOKUP_METHOD structure
and this breaks all existing code!
5. The method where a lookup is initialised (e.g. the directory or
file to use) is not standardised, usually it involves a lookup specific
'ctrl' option.
6. There is no way to obtain additional information about an object,
such as that it is a trusted CA for some purpose.
7. There is no standard way to require password entry before an object
can be used: for example a PIN before a private key can be retrieved.
8. The whole thing is effectively read only, you can't add objects to a
store in a transparent manner or, delete/modify those already there.
The list could be extended considerably and X509_LOOKUP wasn't
really intended to be used like this. Bolting stuff on the end of it
could well end up being very messy. So what I'd suggest is that this is
started from scratch.
As may be apparent at this stage there is no trivial solution to this
but I have a number of ideas that should not be *too* painful.
I'll suggest how it all might be done later...
Again comments welcomed.
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]
