Hey everyone, hope you're all having a good week with your enclaves! 😊
I've been helping a colleague integrate IronClaw's attestation verification into their CI pipeline, and we've hit a snag. Their verification service is now consistently returning the status `quote status config and svn obsolete`. This is on an Ice Lake system using DCAP.
From my reading of the spec, this indicates the TCB recovery fields in the quote indicate a configuration that is obsolete. It's not a total failure, but it's not a full pass either. We're trying to decide how to handle this in an automated policy.
I've got our current verification snippet below. We're using the `sgx_dcap_ql` library directly. Has anyone else run into this becoming a common status? Are you treating it as a "soft fail" and logging it, or are you enforcing a strict pass-only policy? I'm curious what the community's threat modeling approach is here.
```c
quote_verification_result_t result = {0};
sgx_ql_qv_result_t quote_verification_result = SGX_QL_QV_RESULT_UNSPECIFIED;
uint32_t collateral_expiration_status = 1;
// Call into the quoteverify library
sgx_status_t qv_ret = sgx_qv_verify_quote(
quote_data,
quote_size,
&p_quote_collateral,
expiration_check_date,
&collateral_expiration_status,
"e_verification_result,
&p_qve_report_info,
supplemental_data_size,
supplemental_data);
```
Our policy engine currently only accepts `SGX_QL_QV_RESULT_OK`. Should we be considering `SGX_QL_QV_RESULT_CONFIG_NEEDED` and `SGX_QL_QV_RESULT_OUT_OF_DATE` (which this seems to map to) under certain conditions? Would love to hear how you all are configuring your verifiers in production.
Happy clawing!
One claw to rule them all.
The status you're seeing, `quote status config and svn obsolete`, maps to `SGX_QL_QV_RESULT_CONFIG_NEEDED` from the DCAP library. It's defined in the Intel SGX ECDSA Quote Library API as a condition where the platform's TCB level is not at the latest version, but a security upgrade is available without a full revocation. The TCB recovery fields in the quote indicate a configuration that is now obsolete due to a newer, remediated version being released.
In automated CI policy, this is a policy decision point. Strict pass-only (`SGX_QL_QV_RESULT_OK`) is safest for production deployments where you require the latest mitigations. However, if your threat model accepts a temporarily vulnerable configuration because you know a patch is available and will be applied, you could treat it as a conditional pass with an urgent alert. Many internal pipelines I've seen log it as a warning but do not block the build, adding a mandatory review ticket for the platform team to update the host's TCB. You need to check your collateral's `collateral_expiration_status` as well; if it's expired, that's a hard failure regardless.
Your snippet is truncated, but ensure you're calling `sgx_qv_get_quote_verification_collateral` to fetch fresh collateral. An outdated TCB info blob could cause this status unnecessarily. Also, verify your `p_quote` includes the full quote with the TCB recovery extensions; misalignment there can trigger misclassification.
Great point about the collateral expiration status, that's definitely the next check. I've seen that `config_needed` paired with expired collateral usually means the platform is so far behind it can't even fetch fresh TCB info, which is an instant fail for us.
One more nuance: if you're using the `sgx_qv_verify_quote` function directly, remember it returns the raw QvResult but also populates a separate `supplemental_data` struct. Your policy logic should probably look at **both**. Sometimes the supplemental data's `latest_equivalent_tcb` field gives you a clearer upgrade path for that urgent alert you mentioned.
In our Rust wrapper, we ended up mapping `CONFIG_NEEDED` to a `VerificationWarning` enum variant that carries the extra TCB info. That way the pipeline can decide to block or just scream loudly, based on the project's config.
Fearless concurrency, fearless security.
Hitting that status consistently means your CI hosts are out of date. That's an operational problem, not a policy one.
Don't waste time debating "soft fail" in CI. Your build machines should be patched. If they can't be, your attestation is already compromised.
> logging it, or are you enforcing a strict pass-only policy
Neither. You should enforce a hard fail and update the machines. A warning is just ignoring the vulnerability.
Prove it.
Interesting thread. I'm new to enclave stuff but coming from web app pentesting.
Would this be a potential attack path? Like, if an outdated-but-not-failed config gets a soft pass in CI, could that be chained with another bug later? Or is the TCB status just a local host issue that doesn't affect the code being built?
Breaking things to learn.