[caops-wg] OCSP section 4

Mike Helm helm at fionn.es.net
Thu Jun 2 18:30:08 CDT 2005


Olle Mulmo writes:
> we recommend that applications behave as if they would had they 
> received a Revoked state with revocationReason certificateHold (that 
> is, a temporal revocation state).

This seems so close to the very poor behavior we have had with CRLs
and non-updated or missing CRL's that I just don't think it is the
rite thing to do.  I realize the security profs want this. I just
think it leads to annoying problems, particularly when the OCSP
service isn't available (like, for instance, the local net becomes
scrambled, just at the moment your batch job enters the queue.)
Reading Netscape mail in offline mode on an airplane, with OCSP
enabled, was quite annoying!  I think Netscape/Mozilla logged some bugs on this
but don't know numbers or resolution, if any.

I interpret this recommendation as trying to fail safe, but think it will
result  in more practical harm  than good.

> > Search revocation information in preference order
> >    clients should validate local Trusted OCSP responders first, 
> > Authorized
> > OCSP responders next and then CRLs
> > First final answer ends the search. (understanding by final answer a 
> > valid
> > or invalid one).

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





More information about the caops-wg mailing list