How does certificate-based encryption solve key revocation problem?

Question

How does certificate-based encryption solve key revocation problem?

For example, if a user accidentally reveals its secret key or an attacker compromises it, the user may request revocation of its certificate. Alternatively, the user's company may request revocation if the user leaves the company or changes position and is no longer entitled to use the key.

My questions are:

1. How can we do this process in certificate-based encryption and how different is it compared to PKE (that uses CRL or OCSP for certificate revocation)?
2. In the case of signature, how can a user verify the validity of verification keys? How can the user check whether the key is valid and not revoked?

Answer 1

1. The revocation status of a certificate is application dependent, meaning that if the application under which you perform the encryption or decryption does not check for revocation status with the CA, then you may still proceed and encrypt or decrypt the message. You should consider the loss of a private key of a certificate as a loss of your password in a symmetric encryption environment. The same argument applies to PKE.

2. The same applies to a signature verifications: a well behaved program should check the revocation list when verifying a signature, but this depends on the application developer interests. I can verify a signature as a valid one in certain programs without consulting a revocation list at all.

   You can easily test this, for example, by checking on a signed windows program on a computer that is not connected to the internet (look at the Digital Signature tab in the Properties pop-up dialog box of a signed executible): The digital signature of the program would be reported as OK (if indeed nobody messed with its bits) even though the revocation list has not been consulted.