cfu wrote the following:

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.

Upstream gerrit review: https://review.gerrithub.io/#/c/394865/

`ca.ocspUseCache=true` must be set in CS.cfg for this enhancement to
take effect.

Verification steps:

- install Dogtag.
- set ca.ocspUseCache=true in CS.cfg and restart
- perform an OCSP request.  Verify that OCSP response contains
  `nextUpdate' field.  e.g.:

    % openssl ocsp \
        -CAfile /etc/ipa/ca.crt \
        -issuer /etc/ipa/ca.crt \
        -url http://f27-1.ipa.local:8080/ca/ocsp \
        -serial 1 \
        -no_nonce
    Response verify OK                                                     
    1: good                                                                
            This Update: Jan 16 03:45:00 2018 GMT                          
            Next Update: Jan 16 06:00:00 2018 GMT                          

(Vary certificate paths, URL and serial as appropriate.)

Upstream commit: fc3067f2e955e18405f735269bfe5fe135382d21

Build used for verification:
root@csqa4-guest01 ecc_setup # rpm -qi pki-server
Name        : pki-server
Version     : 10.5.1
Release     : 6.el7
Architecture: noarch
Install Date: Monday 29 January 2018 10:37:10 PM EST
Group       : System Environment/Base
Size        : 4805315
License     : GPLv2
Signature   : RSA/SHA256, Tuesday 23 January 2018 10:44:40 PM EST, Key ID 199e2f91fd431d51
Source RPM  : pki-core-10.5.1-6.el7.src.rpm
Build Date  : Tuesday 23 January 2018 10:14:38 PM EST
Build Host  : ppc-016.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor      : Red Hat, Inc.
URL         : http://pki.fedoraproject.org/
Summary     : Certificate System - PKI Server Framework


Procedure for verification:

1. install dogtag
2. set ca.ocspUseCache=true in CS.cfg and restart instance
3. perform a OCSP request and verify that the OCSP response contains the nextUpdate field using the following command:

openssl ocsp -CAfile ca.crt -issuer ca.crt -url http://csqa4-guest01.idm.lab.eng.rdu.redhat.com:8080/ca/ocsp -serial 0x96a64e2 -no_nonce
Response verify OK
0x96a64e2: good
	This Update: Jan 31 05:52:39 2018 GMT
	Next Update: Jan 31 06:00:00 2018 GMT

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0925