Reputation: 54084
I have the following question:
In security deployments what is the standard practice, if revocation checks are made to the certificates but for some reason at some specific moment it is not possible to determine the status of the target certificate?
E.g. because the network is down or the OCSP is down etc (any reason that essentially would not give a conclusive indication of what actually is the status of the certificate).
At first, I thought that the certificate should be considered as rejected (and for example drop the session).
On the other hand though, if I was a valid user and was denied access to resources, due to unrelated issues (such as network problems) I would not like it at all.
So I am not sure, what will happen here, will it depend per security environment, or is there actually some standard approach to handle this?
Any input is highly welcome.
Upvotes: 1
Views: 76
Reputation: 20992
Some systems cache revocation lists and/or revocation verification results for a fixed or configurable duration. Some request a user decision. Some do both (i.e.: request user decision only if cached result indicates certificate was not yet revoked).
Upvotes: 0
Reputation: 559
Web browsers have the same issue. When you connect to a site they check the site's certificate against revocation using OCSP. However if the OCSP server is down (which is pretty often occuring as CAs are not competing against OCSP uptime), they cannot. In that case they assume the certificate as valid. Of course it always relates to your use-case and threat model. If the cost of such an assumption is high --i.e. a country goes bankrupt or several people die--, then it might be wise to not assume valid unless revocation is checked.
Upvotes: 1