Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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.
Comment 2Kai Engert (:kaie) (inactive account)
2016-05-23 09:43:27 UTC
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.
Comment 4Kai Engert (:kaie) (inactive account)
2016-05-23 10:48:08 UTC
Thanks. Closing this bug based on comment 3. Please explain and reopen if anything remains to be done.
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.