I've developed a proof-of-concept binding between OpenSSL and Postgres, via user defined types and functions, and am interested in comments whether it would be interesting to others. My binding is *not* ready for primetime yet, but it's far enough along to start asking some intelligent questions.
There seem to be three major benefits: 1) it makes the database PKI-aware, at least to the extent that you can't store an improperly formatted object. 2) it pushes the crypto library into the database engine, so any client can access it. No need to port the library to Perl/Python/Ruby/Visual Basic/whatever. There are three classes of functions: accessors that extract a field from an object, constructors that generate new objects (e.g., DSA parameters or key pairs), and miscellaneous functions that perform some other task. My questions are: 1) is there any interest in storing PKI information in relational databases? Specifically, storing them as PKI objects, not BLOBs or opaque VARCHAR objects. 2) is there any interest in using PKI functions provided by the database? 3) which PKI functions would people want to see? Should the database be able to sign certs? Should it be able to generate keypairs? When thinking about the final item, it's important to remember that the database binding can keep some information private. The most basic example is a password string required to generate keypairs because the private key is always encrypted. This ensures that the encrypted private key is never visible through the database, and the password can be protected by a SSL connection. Of course some idiot could still store their passwords in the database itself.... Alternately, some functions (esp. CA functions) could require a unencrypted private key or password kept elsewhere on the system. Access to these functions would be restricted using the normal database access control mechanism. -- Bear Giles bgiles (at) coyotesong (dot) com ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
