Repository navigation
Trusted Server attestation #161
Description
Description
Define and implement a Trusted Server attestation mechanism so a party receiving requests can verify agreed claims about the running software and deployment configuration. The issue had no body. A January 2026 attestation design draft explores the problem, but must be reconciled with today's configuration and auction architecture before it is treated as the implementation contract.
Proposed scope
- Specify the verifier, threat model, trust root, claim set, freshness/replay rules, and which configuration changes affect the claims.
- Map claim creation and signing to the current deployment/configuration lifecycle and decide how the proof is carried to an external verifier.
- Define safe failure and rotation behavior without exposing secrets or publisher-sensitive configuration.
Done when
- A reviewed design identifies the exact claim schema, signer/verifier ownership, configuration inputs, rotation, and failure semantics.
- Tests prove that an authorized deployment verifies and that tampered, stale, or mismatched claims fail.
- The agreed transport is exercised end to end and documented for operators and verifiers, or the investigation records why attestation cannot be supported as proposed.
Affected area
Deployment identity, configuration lifecycle, request signing, and auction transport.
Activity
[-]Runtime Attestation[/-][+]Trusted Server attestation[/+]jwrosewell commentedon Oct 12, 2026
A draft that answers this issue's scope is on the fork, jwrosewell#7, on top of one app-config blob for each host (fork pull request 6).
With
[attestation]in the settings a deployment serves evidence, in the sense of RFC 9334, of who operates it and which build it runs, signed with a key that only the operator's build carries. A relying party fetches the evidence from the publisher's own address, at/_ts/attestationunless the endpoint is moved, as a page or as.json, and a verifier holding the operator's public keys decides whether it is genuine. The signed evidence states the host the request arrived for, the publisher whose settings answered, the platform service and the build that answered, the time, and the caller's nonce when one was sent. The signature is ECDSA on P-256 with SHA-256 over a configured context, a line feed and the payload, so a signature the same key made for another purpose cannot pass as evidence.It proves that whoever signed held the operator's key, and the guide says first what it does not prove, being what code is running (a module on a CDN cannot read its own code, so the build fields are the operator's own report), a hardware measurement, what the site serves, and that production answered rather than staging, which the evidence names.
Against the scope here, the verifier is outside the repository and the guide lists its seven checks, the threat model is the guide's "What the evidence proves", "Replay and relay" and "Limits", the trust root is the operator's key schedule (a build input, the key in force being the latest to have started, so a build carries the next key before it is needed), freshness is the signed time and nonce with every answer
Cache-Control: no-store, and no key in force answers503at the endpoint alone with nothing else changed. A settings document cannot name a key.Where it meets #1235, this compiles the operator's keys into the build, so an operator who attests builds its own binary. Reading the schedule from the secret store instead keeps one released binary for everyone, and the signing step is two functions over a schedule, so that change is contained. Which custody the task force wants is the open question.