956838 - OCSP responses fetched from network can override newer OCSP response that is in the OCSP cache

Status: RESOLVED INVALID

(NSS :: Libraries, defect, P5)

Description

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

See bug 933109 comment 30 and later comments in that bug.

There seems to be a problem in ocsp_GetOCSPStatusFromNetwork. It calls ocsp_CacheSingleResponse to cache the new response, which means we'll never replace a newer entry with an older one. However, ocsp_GetOCSPStatusFromNetwork doesn't return the newer (cached) status instead of the older (just-fetched) status, which seems like a legit bug.

Comment 1

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

I think this is not as major of an issue as we originally thought. It may even be a invalid bug.

1. If the cached revoked/unknown response is not expired, then the cached revoked/unknown response will be used and no fetch will be done. This is the correct thing to do.

2. If the cached revoked/unknown response is expired and we do a fetch that gives us a non-expired Good response that is newer than the cached response, then we consider the certificate to be no longer revoked. IMO, this is the correct thing to do, especially considering "extended revoked" (bug 943815).

3. If the cached revoked/unknown response is expired and we do a fetch that gives us a Good response that is older than the cached response, then there are two sub-cases to consider:

   a. Most likely, the Good response will also be expired, since
      it is older than the Revoked/Unknown response and so it
      probably expired before the Revoked/Unknown response
      expired. In this case, we will correctly reject the
      expired Good response that we fetched.

   b. Less likely, the Good response has a thisUpdate earlier
      than the cached Revoked/Unknown response but it has a
      nextUpdate that is later than the cached Revoked/Unknown
      response.

It is only this 3b case that is problematic.

Technically, according to the spec, we're doing the right thing, because we're trusting a non-expired Good response over an expired Revoked/Unknown response. Thus, it would be reasonable to make this bug RESOLVED INVALID.

I also think it is reasonable to say that a later (according to thisUpdate) Revoked/Unknown response should always override an earlier Good response, even if the Revoked/Unknown response has expired and the Good response hasn't expired. However, this scenerio seems quite unlikely given that it doesn't really make sense to have a Good response's validity period subsume the validity period of a Revoked/Unknown response that replaced it; i.e. the CA would have to be doing something dumb.