Greetingss Michael,
Yes. I have a proposal to address this. 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. Each of the categories listed should have its own directory. 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. 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). 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. And for each certificate signed in this repository, there needs to be an event script. Then there is better tracing of activity. I recognize that I'm suggesting quite a bit of development work, but this is the way that commercial CAs I have used operate. Regards, Bill Michael Bell wrote: > Hi Dejan, > > the problem with the mailcounter is fixed now. The problem was a wrong > tar-filter in export-import-lib at exportMails. There is a line "tar -c > *" but "tar -c *.msg" is correct. The fix is available via CVS (but you > can do it by hand too). > > The second problem is a general problem because we have actually no > mechanism to track exports. The problem is that the CA must now during > export which objects are already at the RA and the RA must now during > the export which objects are already at the CA. > > The other problem is that we have actually an unclean export-strategy. > We export pending requests too. > > So there is some work necessary to cleanup this area: > > 1. CA --> RA > VALID_CERT > VALID_CA_CERT > REVOKED_CERT > ARCHIVED_REQUEST > DELETED_REQUEST > ARCHIVED_CRR > CRL > 2. RA --> CA > SUSPENDED_CERT > APPROVED_REQUEST > DELETED_REQUEST > APPROVED_CRR > DELETED_CRR > > The next step is to design a mechanism to track exports. Any ideas? > > Michael > > P.S. Perhaps this is a topic for openca-devel. > -- > ------------------------------------------------------------------- > 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-Users mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/openca-users ------------------------------------------------------- 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
