[caops-wg] OCSP section 4

[Oscar Manso]

>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.