Re: CA DB Support
For simple DB stuff, you can use ODBC libraries, they are available/compilable on all platforms. - Original Message - From: Dr Stephen Henson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, December 07, 1999 9:30 AM Subject: Re: CA DB Support Massimiliano Pala wrote: Bruce Stephens wrote: I haven't tested. I'd guess index.txt would cause some things to slow performance (but possibly not---I'm assuming there are linear searches around). The public keys seem to be kept in separate files in a directory: however they get used, that's going to cause some prblems on some filesystems. However, I'd guess the current design is probably fine for, say, 1 certificates. Specific applications might find the scalability a problem, but for most purposes it's fine. I have tested it with 500.000 certificates and gave me no problems, but our question is about 5/10 Millions of certificates. What about file system capabilities (let's say for UNiX systems like Linux/SunOS/FreeBSD/ etc... ) ??? Someone has ever got to think about similar problems ??? index.txt is stored in an in memory database: the extended memory requirements may cause problems if huge numbers of certificates used. When the database is changed the whole thing is written to disk: again potential problems of corruption. Additional problems can arise if you store copies of certificates in the same directory: a few million files in a directory is not advisable! 'ca' was not initially meant to be used for a full blown CA it was just a demo. I've often considered using some kind of database for certificates. One problem is getting something that compiles on all platforms. In the longer term it might be better if things like req, ca, x509 functionality was exposed to something like perl which could make things a bit friendlier. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Celo Communications: http://www.celocom.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] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: CA DB Support
Massimiliano Pala [EMAIL PROTECTED] writes: I was discussing with some people from the OpenCA project and we do think that a DB support (like Berkeley DB, NDBM, GDBM) should be added to the ca application to store certificates' information and assure scalability. What do you know about openssl ca's scalability ? How many certificates currently supports ?? I haven't tested. I'd guess index.txt would cause some things to slow performance (but possibly not---I'm assuming there are linear searches around). The public keys seem to be kept in separate files in a directory: however they get used, that's going to cause some prblems on some filesystems. However, I'd guess the current design is probably fine for, say, 1 certificates. Specific applications might find the scalability a problem, but for most purposes it's fine. -- Bruce Stephens [EMAIL PROTECTED] MessagingDirect(UK) Ltd URL:http://www.MessagingDirect.com/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: CA DB Support
but our question is about 5/10 Millions of certificates. You might look at what typical (traditional?) Usenet implementations do... __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: CA DB Support
Massimiliano Pala wrote: Bruce Stephens wrote: I haven't tested. I'd guess index.txt would cause some things to slow performance (but possibly not---I'm assuming there are linear searches around). The public keys seem to be kept in separate files in a directory: however they get used, that's going to cause some prblems on some filesystems. However, I'd guess the current design is probably fine for, say, 1 certificates. Specific applications might find the scalability a problem, but for most purposes it's fine. I have tested it with 500.000 certificates and gave me no problems, but our question is about 5/10 Millions of certificates. What about file system capabilities (let's say for UNiX systems like Linux/SunOS/FreeBSD/ etc... ) ??? Someone has ever got to think about similar problems ??? index.txt is stored in an in memory database: the extended memory requirements may cause problems if huge numbers of certificates used. When the database is changed the whole thing is written to disk: again potential problems of corruption. Additional problems can arise if you store copies of certificates in the same directory: a few million files in a directory is not advisable! 'ca' was not initially meant to be used for a full blown CA it was just a demo. I've often considered using some kind of database for certificates. One problem is getting something that compiles on all platforms. In the longer term it might be better if things like req, ca, x509 functionality was exposed to something like perl which could make things a bit friendlier. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Celo Communications: http://www.celocom.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]
Re: CA DB Support
Bruce Stephens wrote: Massimiliano Pala [EMAIL PROTECTED] writes: I was discussing with some people from the OpenCA project and we do think that a DB support (like Berkeley DB, NDBM, GDBM) should be However, I'd guess the current design is probably fine for, say, 1 certificates. Specific applications might find the scalability a problem, but for most purposes it's fine. Depends on how you're using it. IMHO the main performance-related issue is the client access: searching for certificates (by any attributes like CN, Email etc.), loading of certificates, doing on-line verification etc. Well, you can keep that away from OpenSSL's index.txt by storing the certs on a LDAP server like OpenLDAP which is optimized for such kind of stuff. You might wanna use a HTTP/LDAP gateway for providing the cert data via HTTP to clients not capable of LDAP (e.g. use my package web2ldap found on http://sites.inka.de/ms/python/web2ldap/). Currently I'm thinking about stripping down my package web2ldap for doing exactly this job. Ciao, Michael. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: CA DB Support
Dr Stephen Henson wrote: I've often considered using some kind of database for certificates. One problem is getting something that compiles on all platforms. We could get cooperation from the OpenLDAP people as they had to do it and I think they done a very good job. However I could say we can take in charge to add this functionality to OpenSSL/ca program (if you say it will be added to the project) or distribute something in parallel in our own package. I know the ca app was not meant to fully run a ca but as you might think our project is strictly related to the OpenSSL layer and the ca app could be a very useful link (so we do not have to distribute patches to OpenSSL instead we could use it as it was compiled by the user) between our web- based interface and the crypto layer. What do you think about it ??? C'you, Massimiliano Pala ([EMAIL PROTECTED]) S/MIME Cryptographic Signature
CA DB Support
Hi all, I was discussing with some people from the OpenCA project and we do think that a DB support (like Berkeley DB, NDBM, GDBM) should be added to the ca application to store certificates' information and assure scalability. What do you know about openssl ca's scalability ? How many certificates currently supports ?? C'you, Massimiliano Pala ([EMAIL PROTECTED]) S/MIME Cryptographic Signature
