Closed Bug 242146 Opened 21 years ago Closed 20 years ago

no "slop time" for nextUpdate time in OCSP responses

Categories

(NSS :: Libraries, defect, P2)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: nelson, Assigned: nelson)

References

()

Details

Attachments

(1 file)

The interpretation of nextUpdate times in CRLs has recently been a hot topic.
NSS developers have held the view that nextUpdate times are not hard 
expiration times.  Now, here's a similar issue for OCSP responses.  

A cert OCSP responder produces responses that have the same values for the 
thisUpdate, nextUpdate, and producedAt timestamps.  Such a response seems
incorrect according to RFC 2560.  

When NSS receives such an OCSP repsonse, NSS rejects the update with error 
code SEC_ERROR_OCSP_OLD_RESPONSE.  

NSS uses a "slop time" to compensate for clock differences, to prevent
"response in the future" errors.  I propose to use a similar slop time 
for the nextUpdate computation, allowing an OCSP response to be used
as long as now < (nextUpdate + slopTime).  A patch to implement that 
proposal will be attached here shortly.  

Another approach would be to  simply rely on the "isRecent" test for 
thisUpdate, and ignore the nextUpdate field.
Attached patch patch v1Splinter Review
Priority: -- → P2
Target Milestone: --- → 3.10
Comment on attachment 147365 [details] [diff] [review]
patch v1

Julien, please review.
Attachment #147365 - Flags: review?(julien.pierre.bugs)
Comment on attachment 147365 [details] [diff] [review]
patch v1

This patch looks like it's correctly implementing your first approach - ie.
checking if nextUpdate+sloptime is in the past instead of whether nextUpdate is
in the past.

My only nit is that the code would be much more readable if better variable
names were used (ie. something more meaningful than "tmp").

I think the patch is fine for now, but in the future when an OCSP cache is
implemented, we will have to reconsider whether to treat nextUpdate as an
expiration date. That will probably involve major overhaul of the OCSP code,
though.
Attachment #147365 - Flags: review?(julien.pierre.bugs) → review+
/cvsroot/mozilla/security/nss/lib/certhigh/ocsp.c,v  <--  ocsp.c
new revision: 1.20; previous revision: 1.19
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: