The OCSP responder currently doesn't provide the nextupdate field.
Services such as HAProxy require this field, or else they will reject the OCSP response.
+1.
See also https://tools.ietf.org/html/rfc5019: The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments, and https://github.com/sleevi/cabforum-docs/pull/2/files?diff=split for more info on current practices / client expectations for OCSP stapling.
A few knobs to configure how the OCSP responder should behave would be no bad thing.
Metadata Update from @ftweedal: - Custom field component adjusted to General - Custom field feature adjusted to '' - Custom field origin adjusted to Community - Custom field proposedmilestone adjusted to '' - Custom field proposedpriority adjusted to '' - Custom field reviewer adjusted to '' - Custom field type adjusted to defect - Custom field version adjusted to ''
Metadata Update from @mharmsen: - Issue set to the milestone: 0.0 NEEDS_TRIAGE
Metadata Update from @mharmsen: - Issue priority set to: ---
Per PKI Bug Council of 04/27/2017: 10.5 - major
Metadata Update from @mharmsen: - Issue priority set to: major (was: ---) - Issue set to the milestone: 10.5 (was: 0.0 NEEDS_TRIAGE)
Per CS/DS Meeting 09/25/2017: 10.5 critical
Metadata Update from @mharmsen: - Issue priority set to: critical (was: major)
Metadata Update from @mharmsen: - Issue assigned to ftweedal
Some thoughts on this:
if the CRL cache is enabled and OCSP responder is configured to use it, then nextUpdate for the OCSP response should match the nextUpdate of the CRL.
nextUpdate
if the cache is not used, semantically the nextUpdate is "now" because the the status information is retrieved afresh from the database each time. If a cert gets revoked this information is immediately available to the OCSP responder. But we cannot set a nextUpdate of now, because delivery/processing delays or clock skew may mean that the client sees it as "the past", which means it must reject the request. From RFC 5019: https://tools.ietf.org/html/rfc5019
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.
So we need to push the nextUpdate time out a little bit. I have no idea what value we should use here... probably something around 5m to 30m would be appropriate? @cfu what do you think?
Metadata Update from @mharmsen: - Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1523443
Here is my take on this. First of all, Dogtag OCSP was not originally developed with the lightweight OCSP in mind. From the OCSP responder server point of view, according to RFC 6960: https://tools.ietf.org/html/rfc6960#section-4.2.2.1 nextUpdate CAN be lef out: "If nextUpdate is not set, the responder is indicating that newer revocation information is available all the time"
My understanding is that the purpose of the "nextUpdate" field in an OCSP response is to allow clients to save themselves a trip if (currentTime < nextUpdate).
That being said, there is no reason to add support for the clients adhering to rfc5019. From the cited "Time" section in the RFC 6960, thisUpdate and nextUpdate should naturally match that of the CRL. It seems like tfc5019 already addressed the concerns of time skew: "... Clients MAY allow configuration of a small tolerance period for acceptance of responses after nextUpdate to handle minor clock differences relative to responders and caches. " So that's up to the client to resolve it.
My conclusion is that we can set ocsp response to match that of the CRL and leave it at that.
Gerrit review: https://review.gerrithub.io/#/c/394865/
Pushed to master (fc3067f2e955e18405f735269bfe5fe135382d21)
Metadata Update from @ftweedal: - Issue close_status updated to: fixed
Metadata Update from @mharmsen: - Issue set to the milestone: 10.5.4 (was: 10.5)
Metadata Update from @mharmsen: - Custom field fixedinversion adjusted to pki-core-10.5.4-1.fc27
Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.
This issue has been cloned to GitHub and is available here: https://github.com/dogtagpki/pki/issues/2781
If you want to receive further updates on the issue, please navigate to the GitHub issue and click on Subscribe button.
Subscribe
Thank you for understanding, and we apologize for any inconvenience.
Log in to comment on this ticket.