Discussion moved from openssl-users... Bear Giles wrote: > > > > I can think of multiple > > > common storage formats: text files, DBM files, LDAP, RDBMS. > > > > why not use an existing database abstraction layer such as libdbi or ODBC? > > Too abstract - queries are done with SQL statements. That's not a > problem with a RDBMS backend, but requires a lot of extra code with > everything else. Even if you identify a set of standard query strings > and use hardcoded strcmp(), maintenance is a nightmare. >
Whatever we do needs to work on all platforms OpenSSL does and not add a substantial overhead. There should ideally be a means of using a lightweight text, file and memory based databases but pluggable with a more sophisticated database where necessary/possible. > All you really need is a simple api: store(), remove(), lookup(), > revoke() (or update()?), maybe a few more, and a dynamic library > loader. And some configuration code that allows the user to specify > which dynamic library to load. (Then again, in this case it may be > okay to just create a symlink from some standard name to the desired > dynamic library.) The "fun" arises when you get to individual details and how to handle them. For example lookup() would end up looking up a variety of things and return multiple matching entities. The "multiple entities" raises the issue of whether matching number of entities should be handled or if its OK to just return a STACK_OF matching entities. Common lookup methods and their uses include... Issuer name: SSL client authentication, ca application. Issuer name and serial number: S/MIME Subject Name: 'ca' application. Alias: to display a human readable list of certificates. Key ID: to find matching certificate and key. Email address: S/MIME. Adding OCSP and in particular OCSP v2 adds lots of other options to that. All sorts of possibilities arise when loading private keys too. Ideally information should be available about a private key (its key ID for example) without entering a password. That's something none of the standard formats support, unfortunately. While it isn't necessary to handle all of this lot at first, the API should be written in such a way that it can be extended without breaking those version which use older versions of the API. 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]
