Hot take, but it's not wrong. DCAP's main selling point is that you're not hard-locked to Intel's IAS for remote attestation. But you're just swapping one trusted third party for another. Now your root of trust is whoever provisions and runs your PCCS (Provisioning Certificate Caching Service).

The chain looks like this now:
* **Your Enclave** -> **Quoting Enclave** -> **PCCS** -> **Intel Provisioning Certification Service (PCS)**
The PCCS is the critical man-in-the-middle. It caches the PCK (Provisioning Certification Key) certificates and CRLs from Intel. If that's compromised, or if the operator is malicious, your entire attestation flow is poisoned.

What does a compromised chain look like? Let's be concrete.
1. Attacker controls the PCCS endpoint your client is configured to use.
2. They serve you forged PCK certificates and revoked CRLs.
3. Your verification library happily accepts a "valid" quote from a malicious enclave because the crypto checks out against the forged certs.
4. You hand the keys to the kingdom to a fake.

```json
// Your compromised config might just point to their server
{
"pccs_url": "https://legit-pccs.attacker.net",
"pccs_api_key": "your_key_here",
"use_secure_cert": true // lol
}
```

The point is: DCAP doesn't eliminate trust. It changes the *who* and potentially reduces availability risk (you can run your own). But now your security depends on your PCCS's integrity, its network security, and correct synchronization with Intel. You've traded a dependency on Intel's availability for a dependency on your own (or your provider's) operational security. Is that always a win?

How are you all handling PCCS trust in production? On-prem? Multiple federated instances? Or just accepting the cloud provider's managed service as your new root?