Richard Levitte - VMS Whacker wrote:
>
>
> I assume this must be a bit confusing, because we all seem to have
> different ideas on what the different layers are supposed to do.
>
> My idea is that we have three layers:
>
> 0. The application
> 1. The DB framework (which may or may not be part of the ENGINE framework)
> 2. The DB plugin
>
> The plugin doen't really know what the hell we're storing. All it has
> is some simple schema that could fulfill most of our needs (and that's
> flexible enough, I think I've outlined some ideas, but I haven't been
> very specific yet).
Ah now that's a point where we differ. The system I'm considering would
include cases where it would have to know what it was storing at the
plugin level.
An example would be a smart card where when its told to "lookup private
key by key id" would return an appropriate EVP_PKEY structure to the
layer above using the smart card ENGINE.
A PKCS#11 plugin (or a more elaborate one) would translate the lookup
attributes into their PKCS#11 equivalents and translate the returned
PKCS#11 objects attributes into OpenSSL equivalents.
>
> Are the above ideas along the line of what you've done Stephen (I
> don't dare misspell your last name again :-))?
>
That's not quite how I'd see things. Here's a rough example of how
things might got at the application level, with some error checking
omitted:
OBJDB *db;
STACK_OF(OBJDB_ATTR) *search_attrs = NULL;
OBJDB_SEARCH_CTX *ctx;
STACK_OF(X509_OBJECT) *items = NULL;
db = OBJDB_open(/* various parameters */);
/* we are looking up private keys */
OBJDB_add_search_type(&search_attrs, OBJDB_TYPE_PKEY);
/* set lookup alias */
OBJDB_add_search_alias(&search_attrs, "Steve private key");
/* Initialize search for a given database */
OBJDB_search_init(&ctx, db, search_attrs);
/* Just return one match */
if (!OBJDB_search_next(ctx, &items, 1))
/* Search failure */
OBJDB_search_final(ctx);
/* Get EVP_PKEY from items and do somthing with it... */
The above code is effectively doing what ENGINE_load_private_key() does
now.
At the plugin level this stuff is translated into some calls to the
plugins search_init, search_update, search_final calls. At this level
the plugin looks up the attributes and returns zero or more (up to the
search_next imposed limit) matching items. How it actually does the
lookup is totally up to the plugin itself.
As it stands this has the problem that every database would have to
implement some complex searching algorithms making plugin development a
difficult task.
We can solve this in a manner similar to that used by public key
algorithms: where an implementation can just implement modular
exponentiation instead of the full algorithm. This is like having
standard "classes" of plugins which implement a lot of the necessary
functionality and reduce the development required considerably.
One class could be an in memory database which just stores all the
objects in memory and retrieves whichever ones match the search
criteria.
An example which could make use of the in memory class would be a smart
card. It would not do any smart card lookups on the card and just add
all stored objects when the card is inserted and invalidate them when
its removed.
A second class could be a "hash database" class. Here it could store and
retrieve a name+value pair and the database would have no idea what it
was storing. Below this we could have drivers for gdb, Berkeley DB or
some simple file based database (which would work on any platform). This
would be the equivalent of the "Netscape database".
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Gemplus: http://www.gemplus.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]
