Re: OCSP RFC and OCSP version 2 ID

[pgut001@xxxxxxxxxxxxxxxxx (Peter Gutmann)]

Santosh Chokhani <chokhani@xxxxxxxxxxxx> writes:

>I am looking at both the RFC and version 2 ID for OCSP.  Each document
>contains statements that seem contradictory to me.  This relates to the
>meaning of nextUpdate field in the OCSP SingleResponse.  Some places each
>document states that:
>
>"If nextUpdate is not set, the responder is indicating that newer revocation
>information is available all the time"
>
>Other places each document states that:
>
>"Responses where the nextUpdate value is not set are equivalent to a CRL
>with no time for nextUpdate"
>
>Now, this appear contradictory to me since I do not interpret X.509 to imply
>that absence of nextUpdate field in CRL means near real-time CRL generation.
>
>I assume that the above is editorial oversight and the authors of both the RFC
>and ID mean that for OCSP, absence of nextUpdate means newer revocation
>information is available all the time.

There appears to be quite a bit of confusion over these fields among
implementors because the RFC is so vague over how they're handled.  I've seen
responses where nextUpdate isn't set, where it's set to a value later than
thisUpdate, and where it's set to a value equal to thisUpdate (which seems
bogus since it auto-invalidates itself, but I haven't heard any complaints
about this so I guess no-one notices).  Other responders just copy the info
across from the CRL, which leads to funny results if the CRL doesn't contain a
notAfter (== nextUpdate), since the client is supposed to think that new info
is always available even though it's coming from a CRL which may only be
updated once a day (a truth-in-advertising problem).  My solution has been to
ignore the fields and let users decide, which I suspect means they just check
whenever they feel like it, because I doubt anyone's going to try and handle
all the weird special cases which crop up.  I seem to remember something on the
OpenSSL list where someone was grumbling about having to implement variable-
configuration options to handle this as well, so others have run into this
problem too.

Peter.