Subject: [pkix] Should Archive Cutoff be included in all OCSP responses?

From: Jaime Hablutzel <[email-masked]>
Date: Sun, 9 Jun 2019 18:06:01 -0500

Quoting from RFC 6960, "4.4.4. Archive Cutoff":

OCSP servers that provide support for such a historical reference
> SHOULD include an archive cutoff date extension *in responses*.

So for an OCSP server which effectively holds archive revocation
information during a given retention interval, it would be valid to
interpret "in responses" as "in all responses"?, so the extension is
included in all responses instead of only a subset of them (e.g. only for
known expired certificates).

Now, I find important to always include it because status for a given
certificate might not be available anymore, but it could have been "good"
or "revoked" in the past, so including the archive cutoff date in this case
would warn clients of this possibility and this might be specially
important when the server has been configured to return "good" for
non-issued certificates and it could be responding "good" now for a deleted
certificate previously "revoked".

In the other hand, if the certificate is not expired yet, to provide the
archive cutoff would help clients to learn the server retention interval,
so they can realize until when the OCSP server guarantees to keep
certificate status after expiration, e.g. a client might need to validate a
digital signature in the future and knowing the archive cutoff would be
helpful for him to know until when he will be able to fully validate the
certificate status after expiration.

Finally, considering the analogous X.509 ExpiredCertsOnCRL extension which,
being a CRL extension instead of a CRL entry extension, would always be
present and provides archive status information for all possible
certificates that expired after the date it specifies, OCSP's Archive
Cutoff would need to be included in all responses (as a singleExtensions of
course) to produce the same effect, isn't it?.

-- 
Jaime Hablutzel -  +51 994690880