Olle Mulmo writes:
we recommend that applications behave as if they would had they received a Revoked state with revocationReason certificateHold (that is, a temporal revocation state).
This seems so close to the very poor behavior we have had with CRLs and non-updated or missing CRL's that I just don't think it is the rite thing to do. I realize the security profs want this. I just think it leads to annoying problems, particularly when the OCSP service isn't available (like, for instance, the local net becomes scrambled, just at the moment your batch job enters the queue.) Reading Netscape mail in offline mode on an airplane, with OCSP enabled, was quite annoying! I think Netscape/Mozilla logged some bugs on this but don't know numbers or resolution, if any. I interpret this recommendation as trying to fail safe, but think it will result in more practical harm than good.
Search revocation information in preference order clients should validate local Trusted OCSP responders first, Authorized OCSP responders next and then CRLs First final answer ends the search. (understanding by final answer a valid or invalid one).
I think it is hard to make one rite answer & don't have a strong opinion on this, but why _wouldn't_ the static info (local CRL) be the usual first test? Isn't it always the cheapest test? Since it should _never_ be better than the the OCSP check, checking it last seems useless unless (and only unless) all the OCSP responses are timeouts or unknown. So just do it first and then forget it (see above).