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 Bell Humboldt-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
