[caops-wg] OCSP section 4

[Mike Helm]

Olle Mulmo writes:
> On Jun 3, 2005, at 01:30, Mike Helm wrote:
> > but why _wouldn't_ the static info (local CRL) be the usual first 
> > test?  Isn't it

> I'm not sure the gain outweighs the additional complexity. How many 
> percent of the issued certificates are typically revoked? That's the 

In DOEGrids, about 1%.  

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

> 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 

No, this "conduct" argument doesn't seem to be very relevant to me.
So what if the CRL is 6 months stale?  If the cert is revoked and so listed,
you are done, and you have saved yourself the bother of a network query.

In fact, you can test the CRL; you might like to have a  test for
nextUpdate (I mite reply to another message on this topic later time permitting)
and skip CRLs under some circumstances.  A complication, sure.  I don't 
propose this behavior for standardization.

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

I don't follow this.  

Don't particularly care one way or the other, but I am prodding this argument
to see if there's anything to it.  Also, the "suspend" or "hold" feature 
muddies this area.