[caops-wg] OCSP section 4

[Mike Helm]

"Oscar Manso" writes:
> mwh> What's complicated about that?
> 
> mwh> Otherwise, why even bother with the CRL's?  The only useful case that
> mwh> emerges is the same one I cite above (a hit on revocation). 

> RFC2459 states the following: 
> 
> A client can cache the information coming from a CRL safely only when
> ensuring that such information corresponds to revoked certificates. If

point: most crl's issued rite now in grid CA's are v1.
* We need a CRL requirements draft*

> client's safety, it is the same to cache locally revoked OCSP Responses than
> CRLs.
> But from the point of view of client's efficiency, it will be faster to

(1) This argument was about _complexity_;
I 'm going to take it that the complexity issue is dead (see options
below) and the question remaining is when testing the CRL is safe
and efficient.

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

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.

(3) I'll accept your argument about which is faster, checking a CRL list or
checking an OCSP responder service (reluctantly: in our environment, it's hard to
imagine a scenario where it would make much difference).  But I still
don't see why, in option 2, there is even a check for CRL's.  If the
OCSP responder is always >= client up-to-date-ness, the only case
where it would be checked, it's already worthless.  The only case it would be
checked is if the remote OCSP service doesn't provide an answer.
(See (2) - requires a different strategy.)

Suppose it's another case - the OCSP responder doesn't know about
this issuer, so the replying party client has a separate CRL list.
Then the client search algorithm wasn't optimal, and dealing with
OCSP "unknown" response needs a different strategy too.

Are there other cases I am not thinking of?

* It seems to me we need to deal with the "Fail-safe" and status:unknown or
non-responsive OCSP service some more....

(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?

Will have to look at X.509 for clues about some of the others.