Attestation trust root: which PCRs are pinned, and can a debug enclave pass?

[Rob1Ham]

Component: web-wallet/src/api.rs, web-wallet/src/browser.rs (attest_enclave, verify_enclave_statechain), web-wallet/src/client.rs (prove_enclave_server_share, validate_enclave_configuration)
Severity: Open question (attestation trust root)

Summary

The deposit flow's H2 defense ("never expose a funding address before the signing enclave itself confirms, over the attested channel, that it holds the server share Mercury advertised") depends on enclave attestation (prove_enclave_server_share / Enclavia channel). The review did not fully trace:

1. Which PCR values (or measurement set) the client pins, and where those constants live.
2. Whether a debug-mode or development enclave build can satisfy the attestation (i.e., whether the pinned measurement excludes debug flags).
3. Whether the attestation verifies the enclave's TLS/transport key is bound to the attested report (preventing Mercury from MITM-forwarding the "attested" channel).
4. What happens when the operator rotates the enclave image — do old vaults fail closed with a clear error?

If any of these is weak, a compromised Mercury could substitute its own server share at deposit time and steal the funding output after a later transfer — the exact attack H2 was built to stop.

Suggested direction

Document the pinned measurement set and rotation story; add a test asserting debug-enclave quotes are rejected.

Found during security review of feature/bip448-web-wallet-mutinynet @ 64d2423.