A certificate is revoked. What does the relying party see?

Assume a trust service is changing its status publication component. An isolated authority issues a test certificate, a responder publishes status, and a representative application consumes it through a cache. The release owner wants to know whether revocation remains effective under the agreed freshness and failure rules.

The investigation must distinguish the authority’s record, the responder’s output, the cached response, and the consumer’s action. A test that checks only the administrative revocation API leaves the last three unexamined. A consumer may continue using information acquired before the authoritative change.

The service owner supplies the certificate profile, permitted responder, response freshness policy, clock tolerance, and treatment of unavailable or unknown status. Identify the application version that will make the decision. Different consumers can apply different policies, so one application’s behavior cannot stand in for every relying party.

RFC 6960 describes checks for response identity, signature, signer authority, and freshness. Its “good” status is not proof of complete certificate validity. This evaluation therefore records the status result separately from the application’s final acceptance decision and its other certificate checks.

The proposed Zof workflow starts with the change, test endpoints, representative consumer configuration, and existing validation commands. System Graph connects the publication service to the consumers and dependencies affected by it. The review can then select which paths need evidence rather than assuming a healthy responder establishes a healthy trust workflow.

The Verification Engine uses approved verification systems, customer validators, and existing CI evidence. Here the expected output is a reproducible comparison of status and consumer behavior for the candidate. The PKI owner supplies policy and trusted fixtures; engineers approve access and interpret results; the release decision stays with the accountable owner.

A screenshot of “revoked” cannot explain what another application received. Capture the test certificate reference, response identity, relevant times, cache behavior, and consumer decision in one sequence. Keep a response collected directly from the responder distinct from one served through a cache.

RFC 9654 discusses how an earlier response can remain unexpired after the responder’s status changes. Record nonce support and freshness policy where relevant. The test must distinguish an allowed cached response from a response accepted beyond the policy’s limit. They are different findings with different implications.

Keep test issuance, revocation, response signing, and consumer trust configuration separate from production. Use dedicated test keys and approved endpoints. It does not require automatic access to HSM operations or changes to production trust stores. Those would be separate decisions with separate controls.

Review secure enclave deployment when the relevant systems require protected execution. Confirm permitted network paths, where evidence remains, and how the chosen consumer is represented. An accessible test responder is not representative if production reaches it through a different cache or failure policy.

Under the policy defined for this evaluation, a fresh authenticated revoked response must prevent acceptance. Unknown, stale, and unavailable status must follow their explicitly configured dispositions. A failure to distinguish these cases should stop the release review until the owner understands the effect on the intended application.

A passing evaluation covers the declared client, profile, configuration, and conditions. It does not establish universal rejection, certificate issuance correctness, or the security of every key operation. After any correction, repeat normal status checks and the relevant failure conditions. Preserve the unresolved consumers as open scope, not implied coverage.