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
