[EMAIL PROTECTED] wrote: > > Yes. I have a proposal to address this.
I checked the timestamp and it looks like you send this message before I send my answer to your old mail :-D > After a certificate is signed, the signing engine shoud place it in its own > "certificate export" or "Signed certificate" directory. Then use a program > to package it in PKSC#7 or other for export and write to a fd. This > program creates a database that tracks certs that are signed and exported. So you recommend the following: issue cert --> cert_dir --> export to fd and put it into DB Actually we create the cert and put it immediately into our database. The special directory for the export was implemented in some old versions of OpenCA. The problem is that we must track the successful import of the certificate into the RA. Idea for the CA: create cert ----------- 1. issue cert 2. copy cert into database and into directory export_cert CA export --------- 1. copy certs from export_cert to a fd 2. move certs from export_cert to waiting_cert CA import --------- 1. remove all certs in waiting_cert and export_cert which were successfully imported into RA 2. move all certs from waiting_cert to export_cert CA recovery ----------- 1. copy all certs to export_cert Idea for RA ----------- RA import --------- 1. copy cert into database 2. store serial in import_cert.txt RA export --------- 1. send import_cert.txt to the CA This technology we can use for every status of every object which must be exported. It is also a good idea to don't store the hole cert in a directory. It is better if we only store the serial of a certificate in a file like waiting_cert.txt. > Each of the categories listed should have its own directory. What is a category for you? VALID_CERTIFICATE and REVOKED_CERTIFICATE or do you mean roles? > Each item > should have its own system audit trace number and be trackable from the > time of its entry to the time of export or decline. These should also be > tracckable onto a CRL. This may or may not be the certificate serial > number, but does need to be a unique identifier to the system. This sounds like the table log. OpenCA::DBI has a table log where OpenCA::DBI tracks all writeactions of the system. The problem is that this technology is not implemented for OpenCA::DB until now. We use the table log for recovery too (see cmds/replayLog). > The signed certificate directory also creates a repository for archiving > certificates in the event that there are system problems importing or > installing certificates. A secure backup is then available at the CA > (where it belongs). Both the CA and the RA has databases which stores the certificates, CRLs and all requests. OpenCA also has a function to create a backup. > I've seen this in several other CA apps (to varying degrees in each of the > seven CA apps I have most heavily used). It is necessary, especially in > closed systems, to provide a complete audit trail of all certificate and > private key usage activities. Is it enough to track the write actions? There are many readactions, so the logs can be flooded (denial of service). > And for each certificate signed in this > repository, there needs to be an event script. Then there is better > tracing of activity. You mean we should program a script which scan the log for all actions where this cert was used or this cert was changed? Michael -- ------------------------------------------------------------------- Michael Bell Email (private): [EMAIL PROTECTED] Rechenzentrum - Datacenter Email: [EMAIL PROTECTED] Humboldt-University of Berlin Tel.: +49 (0)30-2093 2482 Unter den Linden 6 Fax: +49 (0)30-2093 2959 10099 Berlin Germany http://www.openca.org ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ OpenCA-Devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/openca-devel
