[caops-wg] OCSP section 4

[Jesus Luna]

Because this topic is somewhat related with the one we wrote you 
yesterday about Proxy Certificates you'll find some comments in the 
original text below.
Regards,

>
> On Jun 3, 2005, at 01:30, Mike Helm wrote:
>
>> I think it is hard to make one rite answer & don't have a strong 
>> opinion on this,
>> but why _wouldn't_ the static info (local CRL) be the usual first 
>> test?  Isn't it
>> always the cheapest test?  Since it should _never_ be better than the
>> the OCSP check, checking it last seems useless unless (and only unless)
>> all the OCSP responses are timeouts or unknown.  So just do it first
>> and then forget it (see above).
>
>
> I'm not sure the gain outweighs the additional complexity. How many 
> percent of the issued certificates are typically revoked? That's the 
> 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".

For the proposed Proxy Revocation method using CertiVeR an "unknown" 
status for the Proxy Certificate will always be obtained from a CRL (as 
their revocation info is registered not in the CRL but into a Database 
for such purpose), so from this point of view there is an overhead if 
you first check with such CRL. Also if there are several CAs involved 
then you should check every correspondent CRL as there is not a concept 
like OCSP's Trusted Responder which serves several CAs. On top of that, 
if a CRL has a considerable size then its search/download process may 
become cumbersome.
Remember that this is only a suggestion for the user/developer and 
finally OCSP options able to change such behaviour should be configured 
into the multicited policy (section 9).

>
> IMO, it's only when you run a well-managed central service that you 
> would really gain by query CRLs first, and assume that a non-entry 
> means "good", as that requires proper conduct in regards to keeping 
> the local CRL updated. The text in 4.2 should be enhanced to reflect 
> this consideration.

However as you mentioned in the last part of your email, even this 
central service would have problems keeping fresher certificates status 
(when compared against OCSP).

>
> We all know what disaster it is to have CRLs on client machines where 
> we couldn't control such a conduct -- we shouldn't even try that again.
>
> Also, one has to weigh in risk into the equation. For instance, a 
> service may trust the locally cached CRL for HTTPS handshakes, but 
> make an extra OCSP query before processing a transaction worth > 
> €10,000. This is of course under the assumption that the OCSP query 
> would return a state that is fresher (more fresh?) than what's 
> available in the local CRL.

Which is mostly true when you combine OCSP with a mechanism like 
Delta-CRL. Now again the user should be able to change this default 
behaviour by customizing the OCSP Policy according to his needs.

>
> /Olle
>
Regards,


-- 

____________________
Jesus Luna Garcia
PhD Student. Polytechnic University of Catalonia
Barcelona, Spain
jluna at ac.upc.edu