Clients are off the net all the time, for a large number of reasons. The relying party decisions are often time critical -- need to be made now, not 2 hrs from now when the router is fixed and the remote OCSP responder is visible again.
If a client is off the net, it is not going to be easy to validate a certificate on-line because only if the certificate is on the localCRL/OCSPcache the client will be sure of its status. Hopefully, most certificates being used should be valid. Therefore, they won't be present in the localCRL. The older the localCRL we are consulting the less reliable it becomes. There will be applications that will be able to manage perfectly with a delay of one day but others will need to validate the status of the certificate on real time. In order to do so, those application will be forced to connect to the net to do their OCSPrequest or read the lastCRL issued (which may have a long cautionaryPeriod).
We have to agree on particular ways of dealing with unknown / unavailable OCSP responders (by "we" I mean the Grid community, relying parties and security folks) -- see other messages.
Given the fact that client's requirements may differ, maybe instead of defining a general behaviour, we should encourage clients to specify their validation requirements in the form of a policy. (what validation services to contact, in what order, what QoS to request...) Such policy should also include what to do when the client can not contact with the outside world. Consequently, we believe that the document should present the user the advantages/disadvantages of using OCSP/CRL. In other words, to define a set of use cases and let the user decide what suits him best.
Therefore, we suggest two options:
Option 1: + Check client's OCSP local cache first. + Check local CRL. + Check remote OCSP Service.
Option 2: + Check client's OCSP local cache first. + Check remote OCSP Service. + Check local CRL.
Option2 may be more efficient than Option1 when CRLs are so large that it takes longer to check the CRL than querying the remote OCSP Service. Otherwise Option1 will be more efficient. Both options are fault-tolerant.
(2) These are not fault-tolerant from the point of view of the client!
Excuse me Mike, maybe I didn't pick the right word. What we meant is that the mechanism is fault-tolerant in the sense that if one validation source fails, the client can try to use the others. It is true that there will be cases when all the checks may fail but, as we mentioned earlier, the action to take will depend on the client's security policy. If you agree, we can develop a little bit more both options presenting the advantages and disadvantages of each in the form of an annex to the document. (4) About CRLReason types
As you mentioned here are the various revocation reasons in X.509/RFC 3280:
CRLReason ::= ENUMERATED { unspecified (0), keyCompromise (1), cACompromise (2), affiliationChanged (3), superseded (4), cessationOfOperation (5), certificateHold (6), removeFromCRL (8), privilegeWithdrawn (9), aACompromise (10) }
I don't understand all of these, and some of them may not have agreed upon meanings in fact :^), but the only one that can provide ambiguity in a CRL is the "certificateHold" or suspend - true or false?
We consider that in general this should be the only case unless the CA policy specifies other ones. This would involve modifying the OCSP policy.