Jan Meijer wrote: > I still have some doubts however regarding the feasibility of implementing > this thing. It seems to me you open your CA to a nice little DoS attack if > you do not carefully authorize the certificate suspension. How to take care > of the certificate suspension (signature of course, problem solved). You are right when you say a DoS attack is possible, but the problem, to me, it is internal to every organization. Let me explain. How CSL is generated (got from the 24/h phone service, passwd authenticate service... ) this is something you should solve within the organization and the software you are using, it is not a matter of standards... Some time ago we have talked about this problems, one solution would have been sending an encrypted mail when the certificate is issued with a 'suspension/ revokation' code/passwd (indeed the true path is more complex, anyway lets cut off details), but this is only ONE solution... :-D > Second possible problem, how to trust the CSL. I can trust the CSL because > it has been signed by the CA on the offline certification server (sorry, had > to use the term ;). I cannot ever trust the CSL because it cannot have been > generated on the offline certification server (because of arguments given > before). I don't see a solution to this. The CSL could be signed by a certificate allowed to sign CSLs. This could be the same OCSP server: when a certificate is to be moved from one state to another a new CSL is issued and signed. This could be useful in OCSP implementations as the OCSP responder can keep informations in the couple CSL/CRL. When a certificate is found to be suspended, as suggested by many people, a response of 'revoke' can be given by the OCSP responder with reason extention set to certificateHold... > Third possible problem, how do you recognize the true owner of a certificate > if he wants to turn his status back to "OK". Someone explicitly (and > probably with client authentication or something similar) stated his > certificate has possibly been compromised. You will need a good mechanism > to make sure that the certificate owner is telling the truth when stating > his certificate has not been compromised. This might be more of a > procedural thing, still is important to think about. Once a certificate has > been marked as possibly compromised, how to trust it again? > > Jan Turning his certificate back to OK could be a feature, supported or not by the organization, requiring more than one pass to be accomplished or not. I think this is a procedural matter within the organization... Many (and different) aknoledgemnt methods can be used ( phone, e-mail, fax, meeting in person) can be adopted to check the ID to be the authorized one. C'you, Massimiliano Pala (madwolf@openca.org)
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature