Investigate a TEE-attested principal adapter (Nitro first) to root Auths + Runtime proofs in hardware

[bordumb]

So what

Every Auths proof today bottoms out at "trust the host that ran the verifier or the workload." A tee-attested-v1 principal adapter changes the trust root from the host operator to the hardware vendor: a remote party verifies, offline, that a receipt or statement was signed by a key that exists only inside a measured enclave image, chained to AWS's or AMD's root key. Combined with Proofbound Runtime execution receipts, that is the first point at which an agent from one organization can prove to another organization what it did without either side trusting the other's machines. Without it, the Auths + Runtime chain proves attribution, not truth: a compromised host produces a receipt that verifies and is wrong.

This is the one missing piece between "auditable" and "trustless across organizations." It is also the precondition for underwritable agent actions and for regulated deployments where platform-attested logs are not acceptable evidence.

What to investigate

An attestation document is a signed statement from the hardware that the measured image is running and that a caller-supplied public key or nonce was embedded at request time. The adapter shape is identical to hsm-attested-v1 (a record binds a key to an attested device) and to the proposed AP-SPEC-045 (a token binds a key to an identity): the attestation binds an ephemeral key to a measurement under a vendor root.

• Obtain one real AWS Nitro attestation document and confirm it decodes with auths-codec's CBOR decoder. Nitro is COSE_Sign1 over CBOR with an X.509 chain to one published AWS root, so it fits the existing codec and the AP-SPEC-047 CertificatePathVerifier and AlgorithmBinding ports directly.
• Define the tee-attested-v1 PrincipalMethod: pinned vendor roots, pinned expected measurements (PCR set for Nitro; launch digest for SEV-SNP), embedded-key extraction, nonce/user-data binding to the Auths preimage, freshness rule from the attestation timestamp against evaluation_time.
• Decide the principal syntax and verification-method derivation, following the hsm: and spiffe:// precedents.
• Assess AMD SEV-SNP as the second target: report format, VCEK certificate retrieval from AMD KDS (must be pre-fetched; the kernel performs no network I/O), and whether a confidential VM is the easier producer environment for Proofbound Runtime than a Nitro enclave, since Runtime needs Landlock, seccomp, and cgroup v2 in the enclave kernel.
• Record what stays in the trusted computing base after attestation: the enclave kernel, the vendor's root key and firmware, and the measurement-to-image mapping supplied by the verifier. Attestation moves trust; it does not remove it.
• Write the AP-SPEC for the adapter once the decode check passes, with the same conformance and adversarial-matrix structure as AP-SPEC-045 and 046.

Boundary with Proofbound Runtime

This repository owns verification only: the adapter, its conformance corpus, and the acceptance policy that says "accept only measurement M under root R." Requesting the attestation inside the enclave, packaging the enclave image, and recording the attestation identity in the execution receipt's trusted-computing-base roles belong to bordumb/proofbound-runtime. Neither side runs in the other's security path.

Depends on

• AP-SPEC-047 (algorithm-agnostic ports): CertificatePathVerifier for the vendor chain, AlgorithmBinding for the embedded key, SignatureSuite::validate_key for pinned material.
• Defer predecessor custody and Secure Enclave implementation to Phase 11 #59 records why the predecessor Secure Enclave work is prior art only; this issue is server-side TEE attestation, a different mechanism with the same custody principle: the key never leaves the attested boundary.

Not in scope

• Confidential-computing isolation as a substitute for Runtime's Landlock/seccomp/cgroup boundary. Attestation says which image ran, not what it touched.
• Intel TDX and ARM CCA until Nitro and SEV-SNP have landed.
• Any claim that attestation discharges the enclave kernel or vendor firmware from the TCB.