Ah I see. Seems a bit off the beaten path already, though. Were they some sort of existing documents, generated by something not easily available server side?

No, I'm just implementing code that signs and verifies PDF digital signatures for compliance with EU regulations. I'm not dealing with HSMs, or even the PKIX infrastructure other than verifying a certificate is valid according to Adobe/ETSI and generating/checking signatures. The certificate issuers need to provide the CRLs and OCSP responders/responses.

Why is this downvoted? Could the downvoter please comment?

Online revocation check doesn't require buying HSMs. HSMs also usually operate on a much lower level / aren't really connected to the internet.

If you can't use a cached OCSP response and instead need a fresh one (or the cache is valid for a short period only), that means the CA must sign a new OCSP response much more often.

The key the CA uses to sign OCSP must be held safely because it is important, even if that key can't sign new certificates. I think it belongs in an HSM.

I've read Let's Encrypt spends ~98% of the time of its intermediate signing keys on OCSP, not on new certs. If the OCSP was good only for an hour instead of a week, they would need to perform many more signatures per unit of time which would require more hardware.

But that's an implementation detail. Sure, some HSMs will make signing faster, some won't. You don't need to use HSMs which will have a considerable markup too. You can use more servers if you prefer.

And anyway, that's the server case. OP just wanted to check the revocation as a client as far as I can tell, which definitely doesn't require any extra hardware.

In some cases revocation info will be live, in others it will be stored inside of the document.

My use case involves embedding it, but also being able to verify it (Adobe distributes trusted CA certs through a signed PDF). Never would I need to run my own PKIX infrastructure.