CRLs need an authorized signer and scope
A CRL is signed revocation information from an authorized CA or delegated issuer. Checking a serial number also requires validating the signature, issuer, distribution point, scope and update time. Absence from an inapplicable or stale list does not establish current nonrevocation.
RFC 10007 clarifies a check in 2026: a v3 CRL-issuer certificate must contain keyUsage with cRLSign set. Matching a name, or checking the bit only if the extension happens to exist, can accept a key not certified for signing CRLs. Versions 1 and 2 lack that extension field and are treated separately.
OCSP good is not complete certificate validity
OCSP supplies statuses such as good, revoked and unknown for a queried certificate, with definitive basic responses signed by an authorized party. At minimum, good reports no revocation for that serial number within the relevant validity interval; it need not prove issuance or replace path, usage and service-name checks.
Unknown means the responder cannot determine the requested status, and a network error is not good. Clients must also establish responder authority, such as the issuing CA, a locally trusted responder or a properly delegated OCSP signer, before applying their policy for insufficient information.
References: [3]
Status time, signing time and explicit exceptions differ
OCSP thisUpdate is the latest time the status was known correct, nextUpdate indicates when newer information will be available at or before, and producedAt is the response-signing time. Receiving a newly fetched signed response does not imply its status was freshly investigated.
An end-entity certificate can explicitly declare noRevAvail when its CA publishes no revocation information. RFC 9608 specifies the resulting check exception and prohibits the extension in CA certificates. That design choice, short validity and a failed network query are distinct circumstances.