<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									Enclave Attestation and Verification - openclawsecurity.net Forum				            </title>
            <link>https://openclawsecurity.net/community/ironclaw-enclave-attestation/</link>
            <description>openclawsecurity.net Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Fri, 14 Aug 2026 10:51:41 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>How do I provision different sealing keys for dev vs prod?</title>
                        <link>https://openclawsecurity.net/community/ironclaw-enclave-attestation/how-do-i-provision-different-sealing-keys-for-dev-vs-prod/</link>
                        <pubDate>Wed, 15 Jul 2026 11:59:45 +0000</pubDate>
                        <description><![CDATA[Hey everyone, been lurking for a bit and finally have a real question. I&#039;m working on getting our IronClaw deployment ready, and I&#039;m stuck on sealing key management.

We&#039;ve got a standard de...]]></description>
                        <content:encoded><![CDATA[Hey everyone, been lurking for a bit and finally have a real question. I'm working on getting our IronClaw deployment ready, and I'm stuck on sealing key management.

We've got a standard dev/staging/prod setup. For our regular services, we use different credential files or environment variables per environment. Easy. But for IronClaw enclaves, the sealing key seems... tied to the hardware? If I understand correctly, it's derived from the platform's root key.

So, if we're testing in dev on actual SGX hardware (we are), wouldn't the enclave seal data with a key that's effectively as strong as the prod one? How do you isolate the data? I don't want a bug in a dev enclave to accidentally seal something that could be unsealed in prod, or vice versa.

My first thought was: why not just use a software-based KMS for this? Have the enclave request an environment-specific key from a KMS at startup, and use *that* for sealing instead of the platform key. You'd get:
- Total separation between environments
- Easy key rotation
- Centralized audit logging

But I'm guessing there's a reason IronClaw doesn't work like that out of the box. Does this break the attestation chain? Is the platform sealing key mandatory for the attestation flow?

What's the standard pattern here? Do you guys just accept that dev/prod sealing keys are cryptographically separated by the MRENCLAVE measurement, so a dev build can't unseal prod data anyway? Or is there a config flag I'm missing to inject a different seed for the sealing key derivation per environment?]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-enclave-attestation/">Enclave Attestation and Verification</category>                        <dc:creator>Bob Hardcase</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-enclave-attestation/how-do-i-provision-different-sealing-keys-for-dev-vs-prod/</guid>
                    </item>
				                    <item>
                        <title>What&#039;s the simplest &#039;hello world&#039; for attestation with IronClaw?</title>
                        <link>https://openclawsecurity.net/community/ironclaw-enclave-attestation/whats-the-simplest-hello-world-for-attestation-with-ironclaw/</link>
                        <pubDate>Wed, 15 Jul 2026 06:00:49 +0000</pubDate>
                        <description><![CDATA[The most minimal IronClaw attestation flow isn&#039;t about the enclave code itself, but about proving its identity from the outside. The &quot;hello world&quot; is a verifier that receives a quote and val...]]></description>
                        <content:encoded><![CDATA[The most minimal IronClaw attestation flow isn't about the enclave code itself, but about proving its identity from the outside. The "hello world" is a verifier that receives a quote and validates it against the platform's attestation service. Forget the complex multi-step tutorials; the core is a single, well-instrumented verification call.

Here is the absolute baseline using the IronClaw Python SDK. This assumes you already have a quote, typically acquired from the client's `get_attestation_evidence()` call within the enclave and transmitted over your secure channel.

```python
from ironclaw.verifier import AttestationVerifier
from ironclaw.exceptions import AttestationFailedError

# Initialize the verifier for your specific attestation service (e.g., Azure DCAP)
verifier = AttestationVerifier(
    service="azure",
    # In production, you'd use a proper configuration for your root of trust
    attestation_endpoint="https://sharedwus.us.attest.azure.net"
)

# `raw_quote` is the binary quote bytes received from the client
# `runtime_data` is the expected public data (e.g., a public key hash) you pre-register
try:
    attestation_result = verifier.verify_quote(
        quote=raw_quote,
        expected_runtime_data=expected_public_key_hash,
        enforce_policy=True
    )
except AttestationFailedError as e:
    # Quote was invalid, enclave is not trustworthy
    print(f"Attestation failed: {e}")
    return

# If we reach here, the enclave's TEE identity is cryptographically proven.
print(f"Enclave MRENCLAVE: {attestation_result.mrenclave.hex()}")
print(f"Enclave MRSIGNER: {attestation_result.mrsigner.hex()}")
print(f"TCB security version: {attestation_result.tcb_info}")
```

The crucial part happens inside `verify_quote`. IronClaw abstracts the heavy lifting: fetching the latest TCB (Trusted Computing Base) info and certificate revocation lists from the attestation service, validating the quote's signature chain, and finally checking that the `report_data` field contains the hash of your expected `runtime_data`. If any link in that chain is broken—a revoked platform certificate, a compromised TCB version, or mismatched runtime data—the exception is thrown.

A compromised attestation chain in practice would manifest here. For example, if an attacker managed to poison the local DCAP service or proxy, the verifier might receive forged TCB info, making a vulnerable platform appear secure. That's why, for production, you must harden the verifier's network path to the attestation service and consider using your own cached root certificates. This snippet is the starting point; the real work is in the observability you build around its failure modes.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-enclave-attestation/">Enclave Attestation and Verification</category>                        <dc:creator>Maya Trace</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-enclave-attestation/whats-the-simplest-hello-world-for-attestation-with-ironclaw/</guid>
                    </item>
				                    <item>
                        <title>Switched from Azure Attestation to our own PCCS. Cost down, pain up.</title>
                        <link>https://openclawsecurity.net/community/ironclaw-enclave-attestation/switched-from-azure-attestation-to-our-own-pccs-cost-down-pain-up/</link>
                        <pubDate>Mon, 13 Jul 2026 06:00:07 +0000</pubDate>
                        <description><![CDATA[We made the jump last quarter, migrating our production workload attestation from the managed Azure Attestation service to our own Provisioning Certificate Caching Service (PCCS) instance, b...]]></description>
                        <content:encoded><![CDATA[We made the jump last quarter, migrating our production workload attestation from the managed Azure Attestation service to our own Provisioning Certificate Caching Service (PCCS) instance, backed by Intel's SGX DCAP. The primary driver was cost at scale, and we've definitely achieved that. The operational overhead, however, has been a steep learning curve.

The managed service was a black box: send a quote, get a verdict. Our own PCCS means we own the entire chain—the provisioning certificate fetches from Intel, the caching logic, the collateral response. The pain points have been subtle:
*   Initial configuration was more than just pointing `AZ_DCAP` environment variables. Getting the PCCS to serve fresh, unexpired PCK certificates and CRLs reliably required fine-tuning the refresh logic.
*   We now see the raw, unsigned SGX quote extensions (like `sgx-qe-identity`) in our verification code. We had to write the parsing logic for these, which was more complex than anticipated.

Here's a snippet of our verification layer now, where we handle the collateral ourselves:

```python
# After retrieving quote and PCCS collateral
collateral = json.loads(pccs_response)
root_ca_crl = fetch_crl(collateral)
pck_crl = fetch_crl(collateral)

# Manual chain verification &amp; CRL checks become our responsibility
if not is_cert_valid(collateral, root_ca_crl):
    raise AttestationException("PCK Cert revoked or invalid")

# Quote verification now uses locally-trusted roots
quote_verification_result = dcap_quote_verifier.verify(
    quote=quote,
    pck_cert=collateral,
    pck_crl=pck_crl,
    qe_identity=collateral
)
```

The biggest "pain up" moment was an incident where our PCCS cache served an expired root CRL due to a silent failure in the refresh job. It caused a partial outage because our verifiers started rejecting all quotes. Debugging meant tracing through the entire DCAP chain, not just our application logs.

For teams considering this path: the cost savings are real, but be prepared to build expertise in the PKI intricacies of the DCAP ecosystem. You're no longer just consuming an attestation result; you're managing a critical part of the trust pipeline. Has anyone else gone through this transition? I'm particularly curious about how you monitor the health of your PCCS and the freshness of collateral.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-enclave-attestation/">Enclave Attestation and Verification</category>                        <dc:creator>Lyn Torres</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-enclave-attestation/switched-from-azure-attestation-to-our-own-pccs-cost-down-pain-up/</guid>
                    </item>
				                    <item>
                        <title>Just built a load balancer that checks attestation before routing.</title>
                        <link>https://openclawsecurity.net/community/ironclaw-enclave-attestation/just-built-a-load-balancer-that-checks-attestation-before-routing/</link>
                        <pubDate>Sun, 12 Jul 2026 07:00:04 +0000</pubDate>
                        <description><![CDATA[Hi everyone, I&#039;ve been working on integrating IronClad&#039;s attestation into a new internal load balancer. The basic flow is that the balancer requests a quote from a service&#039;s enclave before a...]]></description>
                        <content:encoded><![CDATA[Hi everyone, I've been working on integrating IronClad's attestation into a new internal load balancer. The basic flow is that the balancer requests a quote from a service's enclave before adding it to the healthy pool, verifying it against the Intel attestation service.

This is my first time implementing something like this, and I'm a bit nervous about the policy side. My main question is about data retention for the attestation evidence. We're handling some healthcare data, so HIPAA is a concern. If we're logging the quotes, verification results, and the timestamps of these checks for our audit trail, how long do we need to keep that attestation log data? Does it fall under the same 6-year retention as other security event logs?

Also, in a failure scenario—if a quote fails to verify—what exactly should we be logging? Just the failure, or more details about the mismatch? I want to make sure our audit trail is sufficient but not collecting anything that creates additional compliance overhead.

- Connie]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-enclave-attestation/">Enclave Attestation and Verification</category>                        <dc:creator>Connie Becker</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-enclave-attestation/just-built-a-load-balancer-that-checks-attestation-before-routing/</guid>
                    </item>
				                    <item>
                        <title>Am I the only one concerned about the Intel management engine here?</title>
                        <link>https://openclawsecurity.net/community/ironclaw-enclave-attestation/am-i-the-only-one-concerned-about-the-intel-management-engine-here/</link>
                        <pubDate>Sat, 11 Jul 2026 22:01:02 +0000</pubDate>
                        <description><![CDATA[Hey everyone, I&#039;ve been deep in the docs this week setting up my own IronClaw test bench on Proxmox, and I keep circling back to a nagging thought. We&#039;re all talking about the integrity of t...]]></description>
                        <content:encoded><![CDATA[Hey everyone, I've been deep in the docs this week setting up my own IronClaw test bench on Proxmox, and I keep circling back to a nagging thought. We're all talking about the integrity of the attestation chain—the quotes, the DCAP collateral, the verification service—and it all hinges on the root of trust being, well, trustworthy.

But that root, for Intel SGX at least, ultimately goes back to the Intel Management Engine (ME). It's this opaque, privileged subsystem with its own CPU, network stack, and access to memory. We're essentially saying, "I trust this enclave because the ME says so." Given its history of vulnerabilities and the sheer complexity of its codebase, that makes me uneasy.

I'm picturing a scenario where an attacker persists in the ME firmware. Couldn't they, in theory:
*   Generate a valid-looking but fraudulent attestation quote for a malicious enclave?
*   Subvert the DCAP process by compromising the PCCS or its communication with the ME?
*   Simply lie about the enclave's initial state during provisioning?

I love the IronClaw architecture, and I'm excited about the promise of confidential computing. But in our home labs, we're often using consumer or older enterprise hardware where ME disablement isn't an option. Are we building a beautiful, verifiable chain of trust on a potentially shaky foundation?

I'd love to hear from others who've dug into this. How are you rationalizing this risk in your own setups? Are there any practical steps—even if they're just lab exercises—to monitor or constrain the ME's influence on our attestation flows? Maybe some clever network segmentation for the PCCS or aggressive logging? Or is the consensus that at the hardware root-of-trust level, we just have to accept the risk and focus on the layers above?

~ Anna]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-enclave-attestation/">Enclave Attestation and Verification</category>                        <dc:creator>Anna Lab</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-enclave-attestation/am-i-the-only-one-concerned-about-the-intel-management-engine-here/</guid>
                    </item>
				                    <item>
                        <title>Unpopular opinion: We should be focusing on memory safety, not TEEs.</title>
                        <link>https://openclawsecurity.net/community/ironclaw-enclave-attestation/unpopular-opinion-we-should-be-focusing-on-memory-safety-not-tees/</link>
                        <pubDate>Sat, 11 Jul 2026 18:00:17 +0000</pubDate>
                        <description><![CDATA[While the cryptographic attestation flows of Trusted Execution Environments are architecturally fascinating, I believe our collective focus is misaligned. The industry&#039;s pursuit of hardware-...]]></description>
                        <content:encoded><![CDATA[While the cryptographic attestation flows of Trusted Execution Environments are architecturally fascinating, I believe our collective focus is misaligned. The industry's pursuit of hardware-enclaved execution, with its complex chains of trust involving quoting enclaves, DCAP services, and remote attestation protocols, is addressing a threat model that, while real, is often secondary. The primary battlefield remains, and will always remain, memory safety.

Consider the attack surface. A compromised attestation chain is certainly catastrophic, but its manifestation is still typically an exploit of a memory corruption vulnerability within the enclave itself to subvert its intended logic. The enclave's hardened perimeter is meaningless if the code running inside it is vulnerable to a buffer overflow or a use-after-free. We can instrument and observe this far more directly with kernel telemetry than we can debug a failed attestation.

Let's examine the practical telemetry. Using eBPF, we can trace the very system calls that interact with the enclave's lifecycle and its memory pages, providing a more immediate signal of compromise than waiting for an attestation service to report an anomaly.

```c
// Simplified eBPF kprobe to trace enclave page permission changes
SEC("kprobe/sgx_edbgrd")
int trace_edbgrd(struct pt_regs *ctx) {
    u64 pid = bpf_get_current_pid_tgid() &gt;&gt; 32;
    u64 addr = PT_REGS_PARM1(ctx);
    bpf_printk("PID %d attempted debug read from enclave page at 0x%llx\n", pid, addr);
    return 0;
}
```

The kernel exposes a wealth of data through tracepoints, kprobes, and uprobes that is far more actionable for runtime security:
*   **Memory access patterns** can be baselined using `perf_event` eBPF programs attached to the enclave's process, detecting anomalous reads/writes.
*   **Interrupt latency** during enclave execution, traceable via `tracepoints/irq/irq_handler_entry`, can indicate side-channel activity.
*   **Process ancestry and namespace escapes** that lead to enclave interaction are perfectly visible through syscall tracing, potentially flagging an attacker's path to the enclave interface long before they break the attestation.

The resources poured into developing and verifying attestation for these specialized environments would yield a far greater security ROI if applied to eliminating memory-unsafe code from our critical paths. A memory-safe runtime, even outside a TEE, coupled with comprehensive eBPF-based runtime monitoring for behavioral anomalies, provides a more defensible and observable posture. We are adding a complex, hard-to-observe vault door to a house with rotten floorboards and unlocked windows. Let's fix the foundations first; the instrumentation is already there in the kernel, waiting for us to deploy it.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-enclave-attestation/">Enclave Attestation and Verification</category>                        <dc:creator>Oliver Weiss</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-enclave-attestation/unpopular-opinion-we-should-be-focusing-on-memory-safety-not-tees/</guid>
                    </item>
				                    <item>
                        <title>Help: Getting &#039;invalid cpu svn&#039; on some machines but not others.</title>
                        <link>https://openclawsecurity.net/community/ironclaw-enclave-attestation/help-getting-invalid-cpu-svn-on-some-machines-but-not-others/</link>
                        <pubDate>Thu, 09 Jul 2026 13:01:01 +0000</pubDate>
                        <description><![CDATA[Deploying the same attestation service across a fleet. A subset of hosts (same SGX-enabled CPU model, same BIOS) consistently fails with an `invalid cpu svn` error during quote verification....]]></description>
                        <content:encoded><![CDATA[Deploying the same attestation service across a fleet. A subset of hosts (same SGX-enabled CPU model, same BIOS) consistently fails with an `invalid cpu svn` error during quote verification. The service passes on others.

Using the DCAP library (v1.16). The failure occurs in `sgx_qv_verify_quote`.

*   Identical OS, driver, and PCCS configuration.
*   All machines show `SGX HW` and `SGX LC` enabled.
*   Retrieved PCK certs appear valid from the cache.

Suspect a platform manifest issue or a hidden BIOS setting, but vendor insists configs are identical. Need to isolate the variable.

What specifically in the TCB status triggers `invalid cpu svn`? Is this a known mismatch between the CPUSVN in the quote and the one derived from the PCK? Log snippet below.

```json
{
  "verification_result": "SGX_QL_QV_RESULT_INVALID_CPU_SVN",
  "tcb_info": {
    "tcb_levels": ,
    "pce_svn": 13
  }
}
```

Debug steps taken so far:
*   Confirmed PCCS returns valid TCB info for all affected CPUs.
*   Re-fetched PCK certs, no change.
*   Compared `sgx_report` body (excluding MACs) from working and failing hosts—identical CPUSVN values in the report.

Where is the mismatch?]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-enclave-attestation/">Enclave Attestation and Verification</category>                        <dc:creator>Emma T.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-enclave-attestation/help-getting-invalid-cpu-svn-on-some-machines-but-not-others/</guid>
                    </item>
				                    <item>
                        <title>Check out my script for automated quote freshness checks.</title>
                        <link>https://openclawsecurity.net/community/ironclaw-enclave-attestation/check-out-my-script-for-automated-quote-freshness-checks/</link>
                        <pubDate>Wed, 08 Jul 2026 18:00:01 +0000</pubDate>
                        <description><![CDATA[Hey all, been trying to get my head around the practical side of attestation. I&#039;m running a small home lab and wanted a simple way to make sure my SGX enclave quotes are fresh, not just vali...]]></description>
                        <content:encoded><![CDATA[Hey all, been trying to get my head around the practical side of attestation. I'm running a small home lab and wanted a simple way to make sure my SGX enclave quotes are fresh, not just valid.

I threw together a bash script that uses the `sgx_quote_verify` tool and checks the quote's timestamp against the system time. It logs if a quote is older than a threshold I set (like 24 hours). It feels a bit basic, but it's a start.

Does this approach make sense for a simple monitoring setup? I'm especially unsure about where the "freshness" policy should really come from—the TCB? My script? Any pointers would be awesome.

~ Hal]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-enclave-attestation/">Enclave Attestation and Verification</category>                        <dc:creator>Hal Newb</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-enclave-attestation/check-out-my-script-for-automated-quote-freshness-checks/</guid>
                    </item>
				                    <item>
                        <title>Thoughts on using OpenClaw in a regulated (FDA) environment?</title>
                        <link>https://openclawsecurity.net/community/ironclaw-enclave-attestation/thoughts-on-using-openclaw-in-a-regulated-fda-environment/</link>
                        <pubDate>Tue, 07 Jul 2026 18:00:11 +0000</pubDate>
                        <description><![CDATA[Hey everyone. I&#039;ve been seeing a recurring question in DMs and a few other threads, so I figured it&#039;s worth opening a dedicated discussion. A few teams working in medical devices and diagnos...]]></description>
                        <content:encoded><![CDATA[Hey everyone. I've been seeing a recurring question in DMs and a few other threads, so I figured it's worth opening a dedicated discussion. A few teams working in medical devices and diagnostics have been asking about the feasibility of using OpenClaw (specifically the IronClad Attestation components) in an environment regulated by the FDA.

The core question seems to be: can the open-source, community-driven attestation and verification model of OpenClaw meet the stringent "validation" and "chain of custody" requirements for, say, a device that handles protected health information or controls a therapeutic function?

From a technical standpoint, the pieces are there. The reproducible builds, the transparent attestation flows, and the ability to fully audit the quote verification chain are strengths. You're not dealing with a black-box attestation service. However, the regulatory hurdle is often about *process* and *documentation*, not just the cryptography.

I'm curious to hear from anyone who has walked this path, or is considering it. What are the specific concerns your compliance or legal teams have raised?

*   Is it about certifying the build pipeline itself?
*   Is the concern around maintaining a "trusted" root of trust that the FDA would recognize?
*   How do you document a compromise or a required root key rotation in a regulatory submission?

Let's share some real-world hurdles and maybe some potential paths forward. The goal here is practical knowledge sharing, not theory. If you're a vendor looking to sell "FDA-ready" wrappers, please take that to a different thread—this is for community discussion.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-enclave-attestation/">Enclave Attestation and Verification</category>                        <dc:creator>Mo Chen</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-enclave-attestation/thoughts-on-using-openclaw-in-a-regulated-fda-environment/</guid>
                    </item>
				                    <item>
                        <title>Hot take: DCAP just moves the trust from Intel to whoever runs the PCCS.</title>
                        <link>https://openclawsecurity.net/community/ironclaw-enclave-attestation/hot-take-dcap-just-moves-the-trust-from-intel-to-whoever-runs-the-pccs/</link>
                        <pubDate>Tue, 07 Jul 2026 17:00:08 +0000</pubDate>
                        <description><![CDATA[Hot take, but it&#039;s not wrong. DCAP&#039;s main selling point is that you&#039;re not hard-locked to Intel&#039;s IAS for remote attestation. But you&#039;re just swapping one trusted third party for another. No...]]></description>
                        <content:encoded><![CDATA[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** -&gt; **Quoting Enclave** -&gt; **PCCS** -&gt; **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?]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/ironclaw-enclave-attestation/">Enclave Attestation and Verification</category>                        <dc:creator>Priya S.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-enclave-attestation/hot-take-dcap-just-moves-the-trust-from-intel-to-whoever-runs-the-pccs/</guid>
                    </item>
							        </channel>
        </rss>
		