[OpenCA-Devel] DBI rewrite
Hi, after some small discussions with Martin and Chris I started a rewrite of OpenCA::DBI. The reason is very simple - OpenCA::DBI was a spin-off from the old OpenCA::DB. This means that it was optimized for one backend with a lot of limitations. We do not support DBM any longer. so there is no reason for such a behaviour. I just commited the first code from friday. It has of course not the full functionality like the old code because the new clean design requires a lot of new code. The basic idea is a monolith interface like now but with a multilayer architecture below the surface. OpenCA::DBI is like now the user interface but below there is a four level architecture: 1. OpenCA::DBI::Object 2. OpenCA::DBI::Hash 3. OpenCA::DBI::SQL 4. OpenCA::DBI::DBH The first object layer is the original object handling. The second layer implements the table handling on a hash base. The third layer build the SQL queries. The fourth layer is the connection to Perl's DBI. I used four layers to get cleaner code. The old code implements a lot of compensation hacks. It is much easier to maintain such fixes if they are isolated in the correct layer and not mixed up with other fixes perhaps in the worng order. Perhaps the most significant new feature is that new code parts are documented via pod. This means that you can run "perldoc OpenCA::DBI::SQL" or "perldoc SQL.pm" to see the documented interface. BTW I found during the beginning rewrite the performance problem of the dataexchange from the stable version. getNextItem selects all items greater or equal the last item and then it takes the second item as result but the primary select returns at average 50 percent of the rows. Regards Michael -- ___ Michael BellHumboldt-Universitaet zu Berlin Tel.: +49 (0)30-2093 2482 ZE Computer- und Medienservice Fax: +49 (0)30-2093 2704 Unter den Linden 6 [EMAIL PROTECTED] D-10099 Berlin ___ smime.p7s Description: S/MIME Cryptographic Signature
Re: [OpenCA-Devel] Certificate revocation status (was: relevance of CRL serial)
Hi, >> Consequently, the certificate status should be set to REVOKED >> immediately >> after final approval in the RA, I think. >> > hmm, i don't know - a certificat isn't issued just becouse someone at > the ra approved it - only the ca can do this - so for removal > > but removing may be considered a specially critical operation > it would also mean - anyone able to compromise the ra may set > certificates to revoked states - even if your ca is still in a valid > state of operation - so i don't know, this could rise other > vulnurabilities to the whole infrastructure, since the ra has to be as > secure as the ca-systems - since it ca revoke certificates... personally I disagree on this issue. RFC 2459 defines CRLs as "one method of revocation": X.509 defines one method of certificate revocation. This method involves each CA periodically issuing a signed data structure called a certificate revocation list (CRL). This specifically does not mean that CRLs are the canonical way of revocation, they are just are the most common and happen to be cryptographically protected by Digital Signatures. In our context the future version of OpenCA will offer the possibility to have signed or unsigned handles/approvals for individual operations in the database, so the status in the database does in fact reflect the most up-to-date revocation state. No need to involve the CA here, and in particular no need to make it more complicated than really necessary. BTW: if somebody compromises the RA, you are in deep trouble anyway... cu, Martin --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click ___ OpenCA-Devel mailing list OpenCA-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openca-devel
Re: [OpenCA-Devel] Certificate revocation status
Martin Bartosch wrote: Consequently, the certificate status should be set to REVOKED immediately after final approval in the RA, I think. hmm, i don't know - a certificat isn't issued just becouse someone at the ra approved it - only the ca can do this - so for removal but removing may be considered a specially critical operation it would also mean - anyone able to compromise the ra may set certificates to revoked states - even if your ca is still in a valid state of operation - so i don't know, this could rise other vulnurabilities to the whole infrastructure, since the ra has to be as secure as the ca-systems - since it ca revoke certificates... personally I disagree on this issue. RFC 2459 defines CRLs as "one method of revocation": X.509 defines one method of certificate revocation. This method involves each CA periodically issuing a signed data structure called a certificate revocation list (CRL). This specifically does not mean that CRLs are the canonical way of revocation, they are just are the most common and happen to be cryptographically protected by Digital Signatures. In our context the future version of OpenCA will offer the possibility to have signed or unsigned handles/approvals for individual operations in the database, so the status in the database does in fact reflect the most up-to-date revocation state. No need to involve the CA here, and in particular no need to make it more complicated than really necessary. Perhaps another usage example. We use online/offline components the following way. Operators can approve what they want on the RA. Only the CA is able to move an object from approved to archived (positive final state). The reason is simple. The final state change is nothing else then a four eye principle combined with the security of an offline machine. A solution could be to create two functions approve_crr and revoke_cert. revoke_cert would be configurable (revoke_cert/crr_state ::= pending/approved). You can execute revoke_cert on pending, signed and approved CRRs. After Ives' Mail we reviewed our own processes and now we think that we need the two processes to get a safe dataexchange because we do not allow the import of archived objects into our CA database. Michael -- ___ Michael BellHumboldt-Universitaet zu Berlin Tel.: +49 (0)30-2093 2482 ZE Computer- und Medienservice Fax: +49 (0)30-2093 2704 Unter den Linden 6 [EMAIL PROTECTED] D-10099 Berlin ___ smime.p7s Description: S/MIME Cryptographic Signature
