Juan Rodriguez-Torrent wrote: > > Russ, I cannot agree more. I'm just trying to figure out if these are real > customer requirements or some folks in a glass house tinkering with > possibilities. Sorry but I'm quite serious. Although I'm a university professor, I'm also a practical engineer and I'm not sitting in a glass house tinkering with possibilities. We are actively developing a PKI here in Italy and we have requirements from partners. One of them asked us for suspending the cert validity associated to a signing engine that cannot be easily removed from the host, because that engine should operate only during the physical presence of the person legally in charge of the signature. I know that the easiest solution would be to switch off the machine (and to physically secure it so that nobody can switch it on) but that cannot be done because the machine offers other services too. In turn, you could suggest to duplicate the machine. But I was wondering if there was nothing simpler like just suspending the certificate. If it turns out that suspension is a nightmare, fine: I'll suggest to duplicate the machine, switch it off, and lock it. But wait a moment: the italian law requires every legally binding CA: - to mantain a "signed list of revoked certificates" (they do use the world CRL and refer to the ISO standard) - to mantain a "signed list of suspended certificates" (they do use the world CSL, but they don't define it) - to permit inquiries over the net to those lists (they don'use the world OCSP or CRL/CSL distribution over HTTP or FTP) so there are lots of CAs here in Italy that are inventing their own format for CSL. I just wanted to investigate if teh it was given enough thoughts to certificate suspension. I'm mildly unsatisfied of the recent discussion over this list. It appears that everybody is against certificate suspension, given its associated cost. I think that, when speaking technically, we should abide from the associated costs of operation, because those costs are quite sensitive to the perceived needs from the users (otherwise we would never define or adopt strong security measures because they are surely too expensive :-) Moreover, some mails suggest to use CRL with the OnHold reason for suspension, and later remove the certificate if it is not actually revoked. What??? I have some really bad feeling about this solution because my understanding is: 1. "revoked" means revoked, i.e. the cert is no more valid for any use starting from a certain date 2. once a cert is inserted into a CRL, it can *never* be deleted from it If these principles are not true, then please change the name of CRL to something else, as it doesn't store revoked certs but temporarly invalid certs. There is nothing more bad about a standard than using words in a counterintuitive way. I ASK FOR A FINAL AUTHORITATIVE WORD HERE: POINT 1 AND 2 ARE TRUE OR NOT? Someone advocates more extended usage of OCSP. Apart from the same terminology issue (the "revoked" status that may be returned from OCSP doesn't actually mean revoked, hey we are all joking! if the secondary code is OnHold, check later and may be it was actually revoked or not) I dislike this approach because it applies only to on-line transactions: if I receive a transaction request, then I check the status of the requesting cert with OCSP and I store the signed answer as a proof. But there are organizations that want to be *autonomously* able to perform checks about cert validity at a certain point in time. Currently, they periodically request CRLs from their trusted CAs and store them locally. So even in the case the CA vanishes, they have their own proof. Given these considerations, I'm here advocating the technical need for some kind of "cert history". For example, we could extend CRLs (to become a CRSL) to allow each entry to represent a certificate that has been revoked or suspended at least once (so, no need to insert good certificates that expire for natural reasons) and to append a list of suspension periods. For example: CERT #123 suspended from 14-jan-2000 17:30 GMT+1 to 17-jan-2000 09:00 GMT+1 suspended from 21-jan-2000 17:30 GMT+1 to 24-jan-2000 09:00 GMT+1 revoked on 02-feb-2000 09:02 GMT+1 That would allow anybody to locally store data and be able to always verify (even offline or in the future) the validity of the certs issued by a certain CA. Thanks for your attention. Antonio Lioy
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature