I've been auditing our attestation pipeline for IronClaw's secure enclave, and the revocation check is consistently the most brittle component. We rely on certificate chains from Intel's PCCS, but a static CRL/OCSP check feels insufficient for a high-stakes, automated deployment.

My current approach involves:
- Embedding the latest CRL at deploy time and checking it during the initial attestation.
- A scheduled job to fetch updated CRLs and cache them, with a fallback to OCSP for real-time validation if the cached CRL is stale.

The problems I'm hitting:
* **Latency:** OCSP responders can be slow or unavailable, blocking our launch.
* **Freshness:** A CRL cached even for an hour is a window of vulnerability if a key is suddenly compromised.
* **Complexity:** The Intel root/processor chain adds steps, and a failure in any external service (like the PCCS) can halt our verification.

I'm considering a shift to a more aggressive, multi-source strategy. Something like:

```python
# Pseudocode for a layered check
def verify_quote_with_revocation(quote, nonce):
# 1. Local cached CRL (updated hourly by background job)
if is_revoked_in_crl(quote.cert, local_crl):
return False

# 2. Parallel OCSP request with strict timeout
ocsp_future = execute_ocsp_check_with_timeout(quote.cert, timeout=2.0)

# 3. Proceed with other verifications (signature, PCRs) in parallel
if not basic_quote_verification(quote, nonce):
return False

# 4. Finalize: if OCSP succeeded and says revoked, fail.
if ocsp_future.result() is REVOKED:
return False
# If OCSP failed (timeout/unavailable), we rely on the cached CRL.
# Log a warning; this is the trade-off for availability.
return True
```

Is this the right balance? How are others handling the "CRL is stale" vs. "OCSP is down" dilemma in production? I'm particularly wary of any solution that introduces a single point of failure or adds seconds to the attestation flow.