[caops-wg] OCSP section 4

[Oscar Manso]

Olle Mulmo writes:

>> maximum reduction of OCSP queries that you would get as a result. Plus, 
>> you have to watch out when encoding the logic: if you process the CRL 
>> first, the cert not being in the CRL should equal "unknown" and you 
>> should continue looking at other places; if you process the CRL last 
>> and the cert is not in the CRL, it should evaluate to "good".

> I don't get what the problem is here.  If the cert is revoked, it's 
> revoked,
> and having successfuly made this test with the static information in a >
file, 
> and matched, you are finished.    Otherwise, proceed to OCSP, if available
> for this certificate.

> What's complicated about that?

> Otherwise, why even bother with the CRL's?  The only useful case that
> emerges is the same one I cite above (a hit on revocation). 


RFC2459 states the following: 

5.3.1  Reason Code

   The reasonCode is a non-critical CRL entry extension that identifies
   the reason for the certificate revocation.  CRL issuers are strongly
   encouraged to include meaningful reason codes in CRL entries;
   however, the reason code CRL entry extension SHOULD be absent instead
   of using the unspecified (0) reasonCode value.

   id-ce-cRLReason OBJECT IDENTIFIER ::= { id-ce 21 }

   -- reasonCode ::= { CRLReason }

   CRLReason ::= ENUMERATED {
        unspecified             (0),
        keyCompromise           (1),
        cACompromise            (2),
        affiliationChanged      (3),
        superseded              (4),
        cessationOfOperation    (5),
        certificateHold         (6),
        removeFromCRL           (8),
        privilegeWithdrawn      (9),
        aACompromise           (10) }


Note that a CRL may (or may not) contain a CRLReason field which informs
whether the certificates are revoked or suspended (onHold) certificates. 
A client can cache the information coming from a CRL safely only when
ensuring that such information corresponds to revoked certificates. If
CRLReason is provided in the CRL then it is safe to check a CRL out of date.
The same happens with an OCSPResponse. Such response may also include the
CRLReason field or not. It is only safe for the client to cache a revoked
OCSPResponse when such information is present.
Taking into account our previous premises, from the point of view of
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
retrieve information from an OCSP local cache than from a full CRL (because
a CRL may contain a large number of entries).
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.

Regards,


Oscar & Jesus