I think that CSL is a real need in several cases and that it cannot be easily substituted with CRL or OCSP. First of all OCSP is out of question is it is not a trust source but rather a delivery channel for fast trust information. For non-repudiation service, it needs to be backed up by long-term data such as those of a CRL. CRL is not good either due to revokation costs, that are among the highest ones in the PKI world. So I would like to minimize the number of revokations, especially if followed by a re-issue of the same certificate with a different key pair (especially difficult to work with those remote friends that have stored remotely my cert to send me encrypted e-mail while off-line) Finally, I'd like to give my users the autonomous ability to suspend and then re-activate their certificates. Let's imagine the following scenario: - I don't want to take my smart-card with me and I leave it at the office (or I use a software PSE installed on my PC at work) - as I don't trust the company in charge of cleaning up the office (or may be my co-workers), I'd like to suspend the cert validity during week-ends, vacation, or even during night hours - I'd like to do this by just clicking on a button on a secure Web page (with client authentication) or sending a signed S/MIME message to an automatic responder - the responder (or the Web server) could in turn provide me with a one-time token to re-activate the cert at my will There are other similar scenarios (like I forgot where I put my smart-card, and later I find it) where I don't want to have the burden of revoking and reissuing certs. So I'd like to see this scenario supported by the following technical details: - a status code returned by an OCSP server to tell that a cert is SUSPENDED - a long term memory that a cert was suspended during a certain period of time; this should be provided by a CSL, which closely resembles the format (but not the meaning) of a CRL Opinions? Antonio Lioy
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature