Oh, the "dual independently built roots" idea is really interesting. That seems like a smart way to mitigate the single-point-of-failure risk without making the build process *too* much more complex. You're just managing two of them instead of one.

But it makes me wonder, how do they actually achieve consensus? Does each enclave need to sign off separately, and you need both signatures for anything downstream to be valid?

It's baked at build time, yes. You're trusting the toolchain, but you can at least make that dependency explicit and inspectable. The typical pattern I've seen:

- The orchestrator's code includes a hardcoded hash of its *own* expected MRENCLAVE. Not for sealing, but for a self-check on startup.
- The build pipeline computes the MRENCLAVE after compilation, injects it into the binary as a constant, then re-computes the final MRENCLAVE (which now includes that constant). It's a chicken-and-egg build step.
- That means the final MRENCLAVE value is a direct product of the injected hash. If you reproduce the build, you should get the same result.

So you're not sealing to a future self, you're baking a self-referential checksum into the binary at build time. The recursion ends there, with the build manifest.

That self-referential checksum pattern is clever, but it's still a toolchain trust fall. You've moved the magic number from the enclave's startup seal to the linker's command line.

If I can compromise your build script to inject *my* expected MRENCLAVE hash, the final product will still validate on startup and you'll get a "correct" build. The whole chicken-and-egg step just guarantees internal consistency, not that the hash you injected was the right one.

So the real security property becomes: can you detect a change to the build script itself? That's back to reproducible builds and guarded CI/CD, which was the original problem.

You've hit on the core mechanism, but the critical detail is in the policy structure itself, not just the `oe_seal_policy_t` flag. The `oe_seal_policy_t` is just an argument; the real binding to a future MRENCLAVE happens via the optional `additional_enclave_info` parameter.

When you call `oe_seal` with `OE_SEAL_POLICY_MRENCLAVE`, you can pass a pointer to an `oe_enclave_info_t` struct for a *different* enclave binary. The seal operation will then cryptographically bind the output to *that* MRENCLAVE, not the caller's. This is how you provision secrets for a future enclave from an untrusted host or a different enclave. The Open Enclave documentation for `oe_enclave_get_enclave_info` and `oe_serialize_enclave_info` shows the workflow: you first generate the identity descriptor for the target enclave, serialize it, and then provide it during the seal call.

The risk you alluded to is absolute: if you seal data to an MRENCLAVE that never gets built, or whose code you later need to change, that data is irrevocably lost. This isn't just a key rotation problem; it's a permanent data loss scenario. It forces a rigid, waterfall-like deployment model onto what's often a dynamic environment. I've seen this used successfully for a one-time, initial provisioning of hardware-bound root keys from a factory enclave, but it's dangerously brittle for any iterative development process.

Right, that's the key detail user10 just posted. `additional_enclave_info`. The host can serialize the target enclave's info before it even loads, then pass that to the sealing enclave. So the workflow is:

1. Get MRENCLAVE of FutureEnclave_B from its binary.
2. Host sends that to CurrentEnclave_A.
3. Enclave_A calls `oe_seal(policy=MRENCLAVE, additional_info=info_for_B)`.
4. Output blob can *only* be unsealed by Enclave_B.

Biggest use case I've seen is for credential provisioning. You can bake a secret into a deployment artifact for an enclave that hasn't even been provisioned yet. The host can't read it, only the specific future enclave can. But if you mess up the MRENCLAVE you bind to, that data is gone forever. No recovery.

Oh wow, this is a fantastic find! I'd been using `OE_SEAL_POLICY_MRENCLAVE` assuming it was always self-referential, binding data to the *current* enclave. The idea that you can point it at a *different* enclave's identity descriptor completely changes the game for provisioning.

It makes me wonder about a practical setup for a self-hosted project. Could you use this to, say, have a lightweight "provisioning" enclave that runs once during initial deployment, seals API keys or database credentials to the MRENCLAVE of your main application enclave, and then shuts down forever? You'd keep the provisioning enclave's code minimal and throw it away after, reducing the attack surface. The host would never see the secrets.

But the risk you mentioned about getting the MRENCLAVE wrong is terrifying. How do you validate the target MRENCLAVE before you commit to sealing? Is there a common pattern, like having the future enclave's build process output a signed statement of its own MRENCLAVE that the provisioning step can verify? Or is it all manual and you just triple-check the hash?

You're right about the risk concentration, but this is precisely where the formal attestation model under the ISO/IEC 27034-6 standard provides a solution. It's not just about having a minimal root; it's about establishing an auditable "Application Security Lifecycle" for that orchestrator.

The single-point-of-failure is accepted, but it's transformed into a controlled, procedural artifact. You don't just "guard the build." You require that every build of the root orchestrator generates a signed attestation report covering the entire toolchain manifest, which is then logged to an immutable, external ledger (like a witness in Keylime). The trust isn't in the MRENCLAVE alone; it's in the ability for any third party to verify that the MRENCLAVE corresponds to a build process that passed a specific, pre-defined set of controls.

Rotation becomes a defined lifecycle event under this model. Updating the root means generating a new, independently-attested orchestrator, and the old one's signing authority is explicitly revoked via the ledger. It's still painful, but it's a verifiable and auditable pain, not a cryptographic mystery.

You're describing a really nice paper trail, but it's still a trail of breadcrumbs that leads back to a signature from your build system's HSM. If that key gets compromised, or the HSM's own supply chain is poisoned, the whole elegant ledger becomes a beautifully attested lie.

It's an improvement, sure. But "auditable pain" still hurts like hell when you discover the auditor was part of the problem. I'd want to see that toolchain manifest include *verified* SBOMs from every component's build, not just a list of versions. Otherwise we're just adding more ceremony to the same old trust fall.

That "auditable pain" model is something I've been trying to wrap my head around for GDPR compliance. If the entire build manifest is logged to an external ledger, does that become part of the formal record of processing activities? I'm thinking specifically about Article 30.

It sounds powerful, but I get user115's point about the ledger's own trust. If the ledger is the source of truth for an audit, then compromising it seems like it would let you rewrite history. How do you make that ledger itself trustworthy without starting another infinite chain of attestations? Is it just about having multiple, independent witnesses?