From: Oscar Jacobsson <[EMAIL PROTECTED]>
oscar> OpenSSL currently has separate APIs, as opposed to flags or profiles,
oscar> for handling EVP_PKEYs, X509s and X509_CRLs because they are
oscar> fundamentally different types supporting fundamentally different
oscar> operations. The stores they reside in will mirror this disparity: a key
oscar> store's (e.g. a smart card's or cryptographic hardware's) very raison
oscar> d'être is to keep its keys hidden, a PKI repository's (e.g. a directory
oscar> server's or RDBMS's) is to make its certificates and CRLs known.
oscar>
oscar> I'm not saying we *could not* consolidate both of these feature sets
oscar> into a single API -- I've stumbled upon private keys in public
oscar> directories more than once. I'm merely trying to point out that it might
oscar> not necessarily be the optimal approach.
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).
The framework has some knowlege about what we can store, and provides
a sufficiently common interface to provide storage of all the objects
we're after. Basically, it would be a translator between the
application, which knows very well what is being stored and retreived,
and the plugin, which doesn't know jack shit about the stuff it's
handling (you could compare that to LDAP, which in itself doesn't know
exactly what is stored, except that it's a bunch <of attribute,value>
tuples, basically (and, and perhaps some primary types).
Note, BTW, that we're not just talking directories or large CA
repositories here. We might just as well be talking about small
client-side databases like the stuff that keeps all the certificates
and keys for Netscape Communicator. I know, down on the disk it's
separate dbs for the keys and for the certificates. So? Do you think
it's necessary to know or care about those details at the application
level? (and OK, that might make the plugin less dumb than I pictured
above, which shows that my thoughts still need some revision)
Are the above ideas along the line of what you've done Stephen (I
don't dare misspell your last name again :-))?
--
Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47
\ SWEDEN \ or +46-733-72 88 11
Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, GemPlus: http://www.gemplus.com/
Unsolicited commercial email is subject to an archival fee of $400.
See <http://www.stacken.kth.se/~levitte/mail/> for more info.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
