> A simple question, but not a least: > instead of using the index.txt file as database of registered certificates, > could it be possible to use a SQL database "e.g. PostgreSQL" as the > engine version of openssl can with HSM "e.g. nCipher"
My PKIX extensions to PostgreSQL 7.1.x provide "native" support for certificates, CRLs and key (PKCS8) objects. It also supports PKCS7 encrypted objects. The external representation is always PEM (with accessor functions to get most of the fields), the internal representation is ASN.1, and the data is "TOASTable" so you aren't bound by the usual 8k limitations. The library is mostly "glue" between the PostgreSQL backend and the OpenSSL library. The intention was provable consistency, not raw performance. For instance, in the cert repository mentioned below I recommend a referential integrity check that requires the issuer of a cert also be in the database. The latest version also has a simple Jave JSP/servlet cert repository, with certificate authority and registration authority on the way. It supports all of the search criteria recommended by Gutman, and besides the "direct" mode it can produce XML. The goal is to use XML and XSLT to produce results in whatever format you want. On the C side, it should be easy to create a wrapper library that uses ESQL/C (ecpg) to access the database. Just use a host variable and the BIO routines that use memory buffers. With ESQL/C, it would be easy to migrate to a different RDBMS if necessary. Long term, it would be best to create an abstraction layer that would allow any backend to be used. I can think of multiple common storage formats: text files, DBM files, LDAP, RDBMS. But that's definitely not a 0.9.7 task! libpkixpq is available at: http://www.dimensional.com/~bgiles/ ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
