If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

OCSP response "too old" check is hardcoded to 24 hours

NEW
Unassigned

Status

NSS
Libraries
P3
normal
11 years ago
7 years ago

People

(Reporter: Chandrasekar Kannan, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

11 years ago
OCSP response validity:

=== from kai ====
Regardless of whether CRLs do expire or not, regardless of whether a software cares for the next-update field of a CRL or not, OCSP is behaving independently.

When NSS is doing "is too old" check, I found the following behaviour in NSS:

We have a function ocsp_TimeIsRecent
and it currently is hardcoded to allow OCSP responses that were created during the last 24 hours, and rejects anything that is older. 

=== from kai ===

I would like to know if this behaviour is acceptable or not.

Comment 1

11 years ago
The ocsp_TimeIsRecent function is only called if the
OCSP response doesn't have "nextUpdate".  Here is the
algorithm, specified in the comment for the
ocsp_VerifySingleResponse function:

3105  *   4. If nextUpdate is given:
3106  *      - The value of nextUpdate is later than now.
3107  *      - The value of producedAt is earlier than nextUpdate.
3108  *      Else if no nextUpdate:
3109  *      - The value of thisUpdate is fairly recent.
3110  *      - The value of producedAt is fairly recent.

So ocsp_TimeIsRecent is only used in the "Else" part of the
algorithm.

Updated

11 years ago
Blocks: 157555
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.