| Summary: | OCSP cache timeout not RFC compliant | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Paul Wouters <pwouters> |
| Component: | nss | Assignee: | nss-nspr-maint <nss-nspr-maint> |
| Status: | CLOSED NOTABUG | QA Contact: | BaseOS QE Security Team <qe-baseos-security> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.4 | CC: | kengert, mrogers, pwouters, tis |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-05-23 10:48:08 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
Paul, I have trouble to understand what exactly you're asking for. Can you please clarify what behaviour you have observed? What's the issue that you have seen? Ok. This is same confusion there was with crl fetching code before. Crl lifetime may be significant, like 30 days but there may be updates any time before. I think current behaviour is exactly correct and rfc is very misleading. |
I believe this is an NSS issue - if I'm wrong and it is a libreswan issue, please re-assign component. OCSP cache timeout is about 1.5hour. libreswan source code and NSS library source code seems to suggest OCSP cache timeout is between 1hour and 24 hour. OCSP requester (IPSEC Peer) should not use a pre-configured "OCSP cache" timer value. Instead it should use the validity period (as OCSP cache) provided in the form of 'thisUpdate' and 'nextUpdate' in an OCSP response. Once the validity period expire, OCSP requester should contact the OCSP server to fetch the fresh revocation status. Here are the references from two OCSP related RFCs: RFC 2560 ===================================================================== 4.2.2.1 Time The thisUpdate and nextUpdate fields define a recommended validity interval. This interval corresponds to the {thisUpdate, nextUpdate} interval in CRLs. Responses whose nextUpdate value is earlier than the local system time value SHOULD be considered unreliable. Responses whose thisUpdate time is later than the local system time SHOULD be considered unreliable. Responses where the nextUpdate value is not set are equivalent to a CRL with no time for nextUpdate (see Section 2.4). ====================================================================== RFC 5019 ======================================================================== 2.2.4. thisUpdate, nextUpdate, and producedAt When pre-producing OCSPResponse messages, the responder MUST set the thisUpdate, nextUpdate, and producedAt times as follows: thisUpdate The time at which the status being indicated is known to be correct. nextUpdate The time at or before which newer information will be available about the status of the certificate. Responders MUST always include this value to aid in response caching. See Section 6 for additional information on caching. 6.1. Caching at the Client To minimize bandwidth usage, clients MUST locally cache authoritative OCSP responses (i.e., a response with a signature that has been successfully validated and that indicate an OCSPResponseStatus of 'successful'). Most OCSP clients will send OCSPRequests at or near the nextUpdate time (when a cached response expires). To avoid large spikes in responder load that might occur when many clients refresh cached responses for a popular certificate, responders MAY indicate when the client should fetch an updated OCSP response by using the cache- control:max-age directive. Clients SHOULD fetch the updated OCSP Response on or after the max-age time. To ensure that clients receive an updated OCSP response, OCSP responders MUST refresh the OCSP response before the max-age time. 4. Ensuring an OCSPResponse Is Fresh Clients MUST check for the existence of the nextUpdate field and MUST ensure the current time, expressed in GMT time as described in Section 2.2.4, falls between the thisUpdate and nextUpdate times. If the nextUpdate field is absent, the client MUST reject the response. If the nextUpdate field is present, the client MUST ensure that it is not earlier than the current time.