dcap-qvl `is_valid()` accepts non-UpToDate statuses

[pbeza]

The TcbStatus::is_valid() method in dcap-qvl/src/tcb_info.rs returns true for all statuses except Revoked, meaning consumers who rely solely on this built-in check may unknowingly accept quotes with known vulnerabilities (e.g. OutOfDate, ConfigurationNeeded).

Root Cause

dcap-qvl's TcbStatus::is_valid() returns true for all statuses except Revoked:

pub(crate) fn is_valid(&self) -> bool {
    match self {
        Self::UpToDate => true,
        Self::SWHardeningNeeded => true,
        Self::ConfigurationNeeded => true,
        Self::ConfigurationAndSWHardeningNeeded => true,
        Self::OutOfDate => true,
        Self::OutOfDateConfigurationNeeded => true,
        Self::Revoked => false,
    }
}

This is used as the internal gate at verify.rs:666. The caller fully mitigates this by requiring status == "UpToDate" and empty advisory IDs in the caller's attestation layer.

Attack Path

None for callers who check status independently — mitigated.

Impact

None for callers who check status independently. Other dcap-qvl consumers who rely solely on its built-in is_valid() may unknowingly accept quotes with known vulnerabilities.

Suggested Fix

No action needed for callers who check status independently. Consider having dcap-qvl default to stricter validation or clearly document that callers must check the status string themselves.

---

Note: This issue was created automatically. The vulnerability report was generated by Claude and has not been verified by a human.

[kvinwang]

Thanks for raising this and for spelling out the context.

TcbStatus::is_valid() is intentionally defined as a low-level helper: it only rejects Revoked, and leaves all other status codes (OutOfDate, ConfigurationNeeded, etc.) to the caller so that different deployments can apply their own risk tolerance and rollout strategy on top of the raw status and advisory IDs.

In other words, we do not intend is_valid() to be the final policy decision point for all consumers, but rather a minimal building block.

There is an ongoing effort in PR #112 ("feat: two-phase verify with Policy trait") to introduce an explicit policy layer on top of the core verification. Once that lands, callers will be able to plug in a Policy implementation that encodes how to treat non-UpToDate statuses in a configurable way, instead of relying directly on is_valid().

Given that, we do not plan to change the current behavior of is_valid() itself, but we will make sure the policy-based API is clearly documented as the preferred integration point for higher-level applications.