Technical detail

The specification follows the IETF RATS architecture (RFC 9334) and the Entity Attestation Token format (RFC 9711) ¹. Its roles are an Attester (a workload with a sidecar agent), a Verifier, an Anchor Fleet at fixed locations, an Endorser that publishes a signed directory of anchors with their public keys and coordinates, and a Relying Party ¹. The Attester generates an ephemeral key pair each cycle. A hash binding that key and the verifier's nonce goes into a register included in the hardware root of trust's signed quote ¹. The Attester may probe anchors directly or query a local trusted proxy ¹. The anchors probed must be chosen to minimize geometric dilution of precision (GDOP) ¹.

Anchor receipts carry a high-precision timestamp of the probe's arrival, the probe's nonce and the anchor's identifier, and are signed ¹. The normative text has the Verifier derive round-trip times from the receipts' timestamps; in the Annex B example, the Attester sends a UDP probe to each of eight anchors and records the local arrival time of each reply ¹. Anchors must be synchronized to a precise time source, preferably UTC ¹. The Verifier must reject evidence whose distance bounds have no common intersection ¹.

The EAT profile defines private claims for the platform quote, the ephemeral public key, the location receipts, a location claim with latitude, longitude, radius in metres and confidence, and the policies passed ¹. In the Annex B example the certificate expires after 10 minutes and is renewed about every five. If a certificate expires, the workload must fail closed ¹. Long-lived anchor, verifier and endorser keys must sit in hardware security modules, and signatures should use ECDSA with P-256 or stronger ¹.