The OCSP archive cutoff extension is an OCSP extension which can be sent in OCSP responses. The extension and how it is used is defined in section 4.4.4 of RFC 6960.

An OCSP responder MAY choose to retain revocation information beyond a certificate's expiration. The date obtained by subtracting this retention interval value from the producedAt time in a response is defined as the certificate's "archive cutoff" date.

To illustrate, if a server is operated with a 7-year retention interval policy and status was produced at time t1, then the value for ArchiveCutoff in the response would be (t1 - 7 years).

OCSP-enabled applications use an OCSP archive cutoff date to contribute to a proof that a digital signature was (or was not) reliable on the date it was produced even if the certificate needed to validate the signature has long since expired. If t1 is the date when the OCSP response was signed, archiveCutoff denotes the date until which revocation information is available. As an example, with a retention period of 7 years a response signed at 2013-11-13 sets ArchiveCutoff to 2006-11-13, indicating that the status "good" for a certificate that expired before 2006-11-13 is not reliable, because the information base of the OCSP responder is not guaranteed (but may) include revocation information of that certificate.

The archive cutoff extension is also used in ETSI EN 319 411-2.

CSS-6.3.10-08 [CONDITIONAL]: If OCSP is provided, the OCSP responder should use the ArchiveCutOff extension as specified in IETF RFC 6960 [i.9], with the archiveCutOff date set to the CA's certificate "valid from" date.

EJBCA can compute the archive cutoff date based on either the retention period and the time the OCSP response was produced (as described in RFC 6960), or based on the issuer's "valid from" date as described in ETSI EN 319 411-2.