Hmm, can someone tell me why this handcrafted database thing is so critical to the ca tool in the first place? To me it seems like superflous burden! I assume that even with a couple of hundred certificates, a simple shell script interface would give everyone far greater flexibility. With a small number of certs (10 to a few hundred), the indexing is only moderately helpful. I can search by field using cut, grep or just sed. I can insert, delete, update, sort all with a few lines of scripting.
OTOH, why not using *db, such as gdb? I guess that's because people want to be able to read the file with a text editor. OK. Steve just suggested I use the x509 tool instead of the ca tool. Appears to work except for it not dealing with CRLs at all. That's O.K. for the moment. Thanks Steve, I really hated to dig in the openssl sources again. Anyway for those who care, it looks like the txt_db stuff is used only by apps/ca.c and nothing else. So, whatever changes are necessary will only affect ca. Furthermore, the txt_db thing is quite general, so there are likely no changes needed to txt_db. The ca tool itself is the focal point. Since I have a workaround for now,I can wait for answers on the following questions before I continue hacking on ca.c: - What's the deep rationale behind the unique index on the subject DN? Why not make a unique index on the keyid? Is it revocation? is it recertification (renewal)? You already have the problem that the uniqueness of subject DN index is conditional on the status (only for non-R certs). If keyid was used, a reissued cert after revocation would never have the same keyid! Also, for renewal of the certificate on the same key, it should be no problem if the same certificate file is being used and the same index entry is overwritten because renewal happens at the end of a lifetime of a cert. This issue is only interesting if a real recertification happens, i.e. if the keys remain the same. This is probably not what most CAs would do (?). - Can someone explain why the ca.c defined 6 DB fields: #define DB_type 0 #define DB_exp_date 1 #define DB_rev_date 2 #define DB_serial 3 /* index - unique */ #define DB_file 4 #define DB_name 5 /* index - unique for active */ #define DB_NUMBER 6 but the index.txt files it generates contains only 5 fields, e.g.: 0 | 1 |2| 3 | 4 | 5 V^I021017163211Z^I^I01^Iunknown^I Ah, O.K. it is because my example doesn't have subject DN components. Why the DB_file is always "unknown" is another wonder. Seems like someone has changed his/her mind when suddenly files were supposed to be named after the serial number. So, all it would take for me is to: A either remove the unique index check on the subject DN, [quick, dirty, incompatible] B or change the use of DB_name to DB_keyid (urgh, that entails the consequential change of adding some simple SUBJECT_KEYID utilities to crypto/x509v3 ...) [not so quick, still dirty and incompatible] C or add another field to the database, named DB_keyid and then implement that option in the ca configuration section where one can pick if subject DNs or the keyids be used as the primary key. Suggestions? Is there any interest in such changes at all? regards -Gunther Gunther Schadow wrote: > > Hi, > > regarding my yesterday's post to enable the apps x509 and req to work > with empty subject DNs (as permitted, even suggested by PKIX for certs > with non-human subjects), I found another problem that I'm going to do > something about now. The ca tool depends on the subject DN when using > the index.txt database [crypto/txt_db]. This is a problem. Please, > I appreciate if someone would let me know if what I'm suggesting > is a big mistake: > > I suggest defining a configuration file option index_on= where one > can choose if indexing should use the hashed subject DN or some > other id. I would recommend that indexing be by public key, namely > subjectKeyIdentifier. The keyid is the one essential thing that's > every cert has. > > I'll dive into this again, uh. Will find the dependency upon > the txt_db code and hopefully I can hack this in with a few > moderate changes. > > regards > -Gunther > ______________________________________________________________________ > 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]
