Juan Rodriguez-Torrent wrote: > > Massimiliano, the issue of suspension was discussed several times during the > last few years and the bottom line is that nobody was able to show a > reasonable business case for it. In other words, there is not enough > interest in suspension mechanisms to generate income or help sales of a > specific PKI because of that feature. I'm sure the additional complexity > that Russ brings to our attention would be less of a deterrent if someone > was willing to make suspension mechanisms attractive to the vendors. Let's > not forget the ISVs (Independent Software Vendors) that have to add yet > another level of complexity to their products to enable suspension and they > also have to be convinced. Also, let's not forget the additional complexity > to be stated on the policies with the corresponding legal issues arising > from that added feature. I could go on for a while on that subject but I > think you got my point. I know, adding complexity is never a feature... at least when that complexity is not needed. My thinking about it are very clear... we need something to provide such service ... > Let me add that the reason you stated for having a certificate suspension > list is trivial and raises fundamental questions: > > 1. If the CA is offline WHO WOULD create the suspension list? The OCSP server could do that as it is a trusted suorce of information and it have to keep track of the 'validity' of the certificates. So you can retrieve the certificate status by getting the OCSP response about it, or just get the CSL/CRL pair in this case you'll know exaclty wich certificates are suspended and/or revoked). > 2. Since without a trusted authority a suspension list will be worthless, > why bother? It appears that the only reason for having a suspension list is > because the CA is offline and want to avoid bringing the CA online to issue > a CRL but the suspension lists needs to be issued by the CA ... (?) You NEVER bring your CA on-line... the CSL indeed is not issued by the CA itself as it is needed to provide a new CSL when a user asks for its suspension... he CSL issuing should be tied to an on-line authority (as described at point 1). > 3. Also why do you think that offline CAs are any different than CAs that > only issue CRLs at fixed time intervals (i.e. every 8 hours, every hour or > every minute). There will always be a time gap between CRL instances, > independently if the CA is online or not, and that's were policies -of > relaying parties, CAs, etc.- have a role. CSLs are not CRLs... when the user asks for a suspension the status gets to suspended in a metter of seconds (or less). This suspends the certificates immediately and if the certificate will get revoked then track of this suspension will be held and if some misusage of the certificate arise than you can prove that should not be trusted as an authorized usage because it was suspended. > If your environment needs a high level of responsiveness, a more reasonable > approach is to solve the problems you did not state (e.g. why the CA has to > be offline?) and bring your CA on-line using mechanisms and protocols > appropriate for the application. Trying to develop new protocols to solve an > apparently trivial environment/operations issue adds, as stated above, > complexity and also interoperability issues to an already complex and less > that interoperable environment. > To me the only way of being sure about avoiding network attacks is to have the CA disconnected from ANY network (being it internal to the organization only or not) and this to provide an high security profile... This causes the problems related to the suspension/revoking of certificates and time delays between the request being received and the real revoking time of the certificate. If you are not using this CA model than you do not suffer of such a problem (this is obvious). As we do use this kind of structure we lack a way of providing this service... :-D C'you, Massimiliano Pala (madwolf@openca.org)
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature