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