Peter,
Peter Gutmann wrote:
You forgot the most important one: What proportion of them are of any use in SSL? Using the X.509 CRL reason codes as usage cases, "key compromise" is unlikely to be useful unless the attacker helpfully informs the server administrator that they've stolen their key, "affiliation changed" is handled by obtaining a new certificate for the changed server URL, "superseded" is handled in the same way, and "cessation of operation" is handled by shutting down the server. In none of these cases is revocation of much use.
(It does however make a nice distraction from addressing security UI issues :-).
From the point of view of SSL, all the reason codes are equal. If a serial number is listed on a full CRL, the cert is considered revoked, regardless of the reason code. The SSL library doesn't care why it was revoked. In fact, it was discovered 2 days ago that there isn't even an NSS public function to get at the reason code currently :-). See bug 287052 . That omission doesn't prevent revocation checking from working in NSS.
It's probably a waste of time to put together a browser UI that distinguishes revocation reason codes . The concept of revocation alone is probably too much to grasp for most browser users, anyway.
That doesn't mean some other applications (eg. servers) might not some day want to log the reason codes when a login attempt with a revoked client certificate occurs.
As far as cases like "key compromise", obviously it wouldn't be the attacker reporting that he stole the key ! But the legitimate owner of a key might at some point become aware of a risk and report it to the CA to have his own cert revoked . Eg. he has a software key on his hard drive, and the computer gets stolen . Or his smartcard gets stolen. There is no proof that the key is actually compromised in those cases (the thief would still need to crack the database or smartcard password to use the key), but there is a risk and strong suspicion, so the reason code has very valid uses.
Once the cert is revoked, a server may be able to log any attempt made by the thief to login with the stolen cert and key, - it would appear in the server log as "revoked cert for [EMAIL PROTECTED] - reason : key compromise" and the server administrator could take action such as tracing the IP address of the thief.
In many cases, the problem with a cert will be discovered after an initial attack. And in other cases not at all. If a problem is discovered, revocation is very useful to limit the damage to the (hopefully short) period of time that elapses before somebody becomes aware of the problem and reports it to the CA for revocation.
Without revocation checking, nobody has any way of knowing there is a problem with certs until the cert expires. That can be a very long period of time (a year, or more) and more than enough for an attacker do a lot of bad things.
_______________________________________________
mozilla-crypto mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-crypto
