Re: SQL DB instead of index.txt
On Sun, 27 Jan 2002, Bear Giles wrote: ... 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! why not use an existing database abstraction layer such as libdbi or ODBC? http://libdbi.sourceforge.net/ http://www.unixodbc.org/ -- aspa __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SQL DB instead of index.txt
From: Marko Asplund [EMAIL PROTECTED] aspa On Sun, 27 Jan 2002, Bear Giles wrote: aspa aspa ... aspa Long term, it would be best to create an abstraction layer that aspa would allow any backend to be used. I can think of multiple aspa common storage formats: text files, DBM files, LDAP, RDBMS. But aspa that's definitely not a 0.9.7 task! aspa aspa why not use an existing database abstraction layer such as aspa libdbi or ODBC? From an OpenSSL point of view, that's uninteresting. What is interesting is to offer a layer above that, designed to handle the objects handled by OpenSSL: certificates, keys, crls,... -- 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 User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SQL DB instead of index.txt
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. 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.) __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SQL DB instead of index.txt
on 1/28/02 9:10 AM, [EMAIL PROTECTED] purportedly said: 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. Actually, not necessarily. As with other software that can use DB backends, simply expanding the configuration file options to include table and column names (notwithstanding connectivity parameters) will give a great amount of flexibility and at the same time liberate the details from the core code. 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.) I would imagine this is how it would be done internally in any case, whether as loadable or by a compile-time option. The issue would then be whether the openssl team would create the plugins, or leave it to third party developers. I suppose it is a quality control issue. But functionality such as I mention above will have to be incorporated into the core code or users will have to use whatever schema conventions the authors choose, or be forced to develop their own plugins. Keary Suska Esoteritech, Inc. Leveraging Open Source for a better Internet __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SQL DB instead of index.txt
(Slightly OT, but it is important to anyone looking at storing these objects in a relational database.) with postgres 7.1 the 8k limit is gone anyway. Yes and no. What 7.1 added - and why I don't support older versions - is TOAST support that tells the database server that it's okay to move the user-defined type out of the main record if necessary. By default new user-defined types remain in the main record and that's still limited to 8k. Since the well-defined types (both standard and user-defined) now support this, it's fair for the casual user to say that the 8k limit is gone. But anyone working in the backend needs to deal with this issue. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
SQL DB instead of index.txt
Hi list, I am not C coder! 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 Regards -- # .- ...- . .-. .-. --- . ... .- .-.-.- .- -.-- ... .- # Averroes A. Aysha # Think Linux, Think Slackware! # e-fingerprint = 63:B0:7D:A1:23:BC:25:96:AE:B7:76:36:F3:07:1F:88 # .- ...- . .-. .-. --- . ... .- .-.-.- .- -.-- ... .- __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SQL DB instead of index.txt
From: Averroes [EMAIL PROTECTED] a.averroes A simple question, but not a least: a.averroes instead of using the index.txt file as database of a.averroes registered certificates, could it be possible to use a SQL a.averroes database e.g. PostgreSQL as the engine version of a.averroes openssl can with HSM e.g. nCipher Currently no, but that's honestly a rather cool idea. The reason that it wouldn't work right now is that the engine framework only has the functionality to retrieve keys or key handles from a HSM. No storage capabilities and no certificates on HSM. I don't know what the rest of the development team says about this, but I would for sure be interested into looking at implementing that kind of extension. This won't happen for 0.9.7, however. We already have a lot of new stuff coming with that release, so extensions like the above will have to wait 'til 0.9.8 or later. -- 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 User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SQL DB instead of index.txt
Richard Levitte - VMS Whacker wrote: From: Averroes [EMAIL PROTECTED] a.averroes A simple question, but not a least: a.averroes instead of using the index.txt file as database of a.averroes registered certificates, could it be possible to use a SQL a.averroes database e.g. PostgreSQL as the engine version of a.averroes openssl can with HSM e.g. nCipher Currently no, but that's honestly a rather cool idea. The reason that it wouldn't work right now is that the engine framework only has the functionality to retrieve keys or key handles from a HSM. No storage capabilities and no certificates on HSM. I don't know what the rest of the development team says about this, but I would for sure be interested into looking at implementing that kind of extension. Yes I'd also be interested in doing this. A general key certificate and CRL database API is something I've been looking at for a while but never completed patrly due to a few thorny issues but mainly due to being diverted onto something of higher priority. If this could be usable as a replacement for the highly brain dead X509_LOOKUP stuff that would be great. 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 User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SQL DB instead of index.txt
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]
