Verifiable Proof of Environment Attestation Profile

1.1. Scope and Layered Attestation

V-PEA profiles a two-layer Attester, following the layered attestation model defined in {{!RFC9334}}, Section 3.2. Using the terminology of RFC 9334 Figure 3:¶

The binding of individual workloads to the local Workload Identity Agent — and the credential issuance that follows a positive Attestation Result — are out of scope for this profile. Those concerns are addressed by complementary work such as {{I-D.mw-wimse-transitive-attestation}} and the WIMSE Architecture {{I-D.ietf-wimse-architecture}}. See the WIMSE Integration appendix for a mapping.¶

1.2. Relationship to Related Work

defines how a Verifier encodes geographic location conclusions — jurisdiction-level results such as country, subdivision, and city — as EAT Attestation Result Claims for consumption by a Relying Party. That draft addresses the output encoding side of the attestation pipeline.¶

V-PEA addresses the complementary input side: the Evidence profile the Attester produces, the hardware-binding mechanism (TPM quote) that makes location evidence verifiable, and the verification procedure the Verifier applies to produce an Attestation Result. V-PEA Evidence is what a Verifier appraises to yield the kind of geographic result claims that {{I-D.richardson-rats-geographic-results}} encodes.¶

The two documents are intended to compose: a Verifier that appraises a V-PEA lah-bundle could express its conclusion as an Attestation Result using the geographic Claims defined in {{I-D.richardson-rats-geographic-results}}. V-PEA is self-contained; use of that encoding is OPTIONAL and is one possible way a Verifier may express its conclusions — consumers MAY enforce geofence policy directly from the Attestation Result, use the V-PEA X.509 extension (OID 1.3.6.1.4.1.65284.1.1) as the trust signal, or adopt any other result encoding their deployment requires.¶

One gap in the combined stack is not addressed by either document: the mapping from a raw location fix or geofence proof to a named legal jurisdiction (for example, from "inside polygon P" to "in jurisdiction X"). This mapping raises its own trust questions — who maintains the polygon-to-jurisdiction database, under what authority, and how that mapping is kept current — and is deferred to future work.¶

2.1. Abbreviations

• AK: Attestation Key¶

• BMC: Baseboard Management Controller¶

• DAA: Direct Anonymous Attestation¶

• EAT: Entity Attestation Token¶

• EK: Endorsement Key¶

• GNSS: Global Navigation Satellite System¶

• IMA: Integrity Measurement Architecture¶

• IMEI: International Mobile Equipment Identity¶

• IMSI: International Mobile Subscriber Identity¶

• LAH: Location Anchor Host¶

• MNO: Mobile Network Operator¶

• OOB: Out-of-Band¶

• PCR: Platform Configuration Register¶

• PoR: Proof of Residency¶

• SPDM: Security Protocol and Data Model¶

• STARK: Scalable Transparent ARgument of Knowledge¶

• SVID: SPIFFE Verifiable Identity Document¶

• TEE: Trusted Execution Environment¶

• TPM: Trusted Platform Module¶

• V-PEA: Verifiable Proof of Environment Attestation Profile¶

• ZKP: Zero-Knowledge Proof¶

4.1. Server-centric Enforcement

Enterprises need cryptographic proof that identity agents run only on approved hosts within an approved geographic boundary, and that credentials are issued only from verified platforms.¶

• Platform-to-platform (general): Relying Parties accept credentials only when the issuing Attester's Evidence demonstrates platform integrity and "in-zone" residency, preventing credentials from being used outside the approved boundary.¶

• Agentic AI platforms: An AI agent platform may issue credentials for sensitive operations only when its Attester presents hardware-rooted integrity Evidence and a verifiable "in-zone" proof (optionally privacy-preserving), binding identity to both platform state and residency.¶

• Federated / edge AI (key or model release): High-value artifacts (e.g., decryption keys or model weights in federated learning) are released only when the partner/edge Attester demonstrates integrity and residency within the required boundary. This is useful for intermittently connected sites.¶

• Server verification: Clients validate that a server endpoint is operating within an approved boundary (e.g., by policy tied to the Attestation Result for that server's platform).¶

4.2. User-centric Enforcement

Enterprises may also need trustworthy location signals for user-facing access decisions.¶

• Geofenced access control: User access is permitted only when the user (or user device) proves it is within an allowed boundary, ideally without requiring precise location disclosure.¶

• On-premises boundaries: Customer-premises equipment can define an enterprise boundary, with a network or enterprise infrastructure providing supporting evidence for policy enforcement.¶

• Restricted support geographies: Administrative or support actions can be allowed only when the operator proves presence within allowed geographies, reducing policy and insider-risk exposure.¶

4.3. Compliance and Risk Reduction

V-PEA provides audit-ready Evidence to support data residency and sovereignty controls, and it can also reduce non-compliance risk from misconfiguration or spoofable signals. Even when not mandated, "in-zone" proofs help address: configuration drift, edge relocation/proxying, contractual residency requirements, and location-privacy minimization (proving "inside the zone" without storing coordinates).¶

5.1. RATS Role Mapping

V-PEA instantiates the RATS Architecture {{!RFC9334}} with the following role assignments.¶

Note: The Mobile Network Operator (MNO), when present, provides a signed location statement (mno-location) that the Attester integrates into its Evidence as a signed Claim source. This is attester-collected Evidence — not a RATS Endorsement — because the MNO asserts network-observed location, not the Attester's identity or characteristics. The same model applies to other external signed location sources (such as SovCert anchors or quantum-derived proofs), which MAY similarly be integrated as signed Claim sources within the lah-bundle.¶

5.2. Evidence Flow

The V-PEA Evidence flow follows the RATS background-check model ({{!RFC9334}}, Section 5.2): the Attester conveys Evidence to the Verifier (possibly via a Relying Party), the Verifier appraises it using Reference Values and Endorsements, and conveys the Attestation Result to the Relying Party.¶

                                    Reference Value
Endorser                             Provider
(TPM Mfr)                            (Admin)
   |                                   |
   | EK cert                           | PCRs, agent digest,
   | chain                             | geofence polygons
   v                                   v
Attester (LAH)                      Verifier
  [TPM: Attesting Env]              Appraises Evidence
  [Agent: Target Env]  -- lah-bundle -->  against Reference Values
  [Sensor(s): Claim sources]               and Endorsements
  [MNO (opt): signed Claim source]
                                        |
                          Attestation Result
                                        |
                                        v
                                  Relying Party
                            (applies Appraisal Policy
                             for Attestation Results)

The Attestation Result produced by the Verifier is the output of V-PEA's RATS pipeline. What the Relying Party does with the Attestation Result — issue a credential, release a key, authorize an operation — is a Relying Party policy decision outside the scope of this profile. See the WIMSE Integration appendix for one such consumption pattern.¶

5.3. V-PEA Evidence Structure

The lah-bundle is the RATS Evidence structure defined by this profile. It is a hardware-sealed object produced by the Attester (LAH) and conveyed to the Verifier for appraisal. It encodes both Evidence dimensions: WHAT (hardware provenance via tpm-ak and manufacturer endorsement; platform integrity via PCRs in the TPM quote; software integrity via target-environment-image-digest) and WHERE (geofence residency via geolocation-proof-hash and geolocation-payload, optionally as a privacy-preserving ZKP). All fields are fused by the tpm-quote-seal into a single TPM-signed statement — neither dimension can be selectively forged or transplanted without invalidating the seal.¶

{
  "lah-bundle": { },
  "mno-location": { }
}

5.4. Attestation Result

Upon successful appraisal of the lah-bundle, the Verifier produces an Attestation Result ({{!RFC9334}}, Section 8.4). This profile does not mandate a specific encoding for the Attestation Result. Implementations MAY express results using:¶

• EAT Attestation Result Claims, including geographic Claims per {{I-D.richardson-rats-geographic-results}};¶

• an X.509 extension (OID 1.3.6.1.4.1.65284.1.1) embedded in a credential issued by a Relying Party acting as CA; or¶

• any other result encoding that satisfies the Relying Party's Appraisal Policy for Attestation Results.¶

The Attestation Result MUST convey at minimum:¶

When the Attestation Result is embedded in an X.509 extension and marked CRITICAL, any downstream consumer that does not understand the extension MUST reject the credential, enforcing fail-closed behavior.¶

5.5. TPM Quote Verification Procedure

The Verifier MUST perform the following steps to validate the tpm-quote-seal:¶

1. Decode tpm-quote-seal (Base64URL → bytes)¶

2. Parse TPMS_ATTEST structure¶

3. Assert TPMS_ATTEST.type == TPM_ST_ATTEST_QUOTE¶

4. Compute expected_qd = SHA-256(JCS({tpm-ak, geolocation-id-hash, geolocation-proof-hash, privacy-technique, nonce, timestamp, target-environment-image-digest}))¶

5. Assert TPMS_ATTEST.qualifyingData == expected_qd¶

6. Verify signature over TPMS_ATTEST bytes using tpm-ak public key (RSASSA-PKCS1-v1_5 or ECDSA)¶

If any step fails, the Verifier MUST reject the Evidence and MUST NOT produce a positive Attestation Result.¶

5.6. Freshness and Replay Prevention

To prevent mix-and-match and replay attacks, Verifiers MUST enforce the following:¶

• Attestation Results MUST be fresh and MUST be bound to the appraisal event (for example, by cryptographically binding freshness values used for platform quotes within the Attestation Result).¶

• The nonce field in the lah-bundle MUST be a freshness value issued by the Relying Party for each attestation interval, per the nonce-based freshness model in {{!RFC9334}}, Section 10.2.¶

• Verifiers MUST reject Evidence where the timestamp falls outside the configured freshness window.¶

Where policy requires it, the Verifier can additionally require that the Target Environment measurement (target-environment-image-digest) matches an approved Reference Value, reducing the risk that a modified or unauthorized agent produces accepted Evidence.¶

6.1. Privacy Applicability

The relevance of location privacy varies significantly by deployment context:¶

• Datacenter and server environments: When an Attester is a server in a known datacenter, the physical location of the hardware is typically not sensitive — it may be a matter of public record or contractual documentation. In such deployments, privacy-technique = "none" (raw coordinates) is appropriate and the ZKP overhead is unnecessary.¶

• User-facing and edge environments: When an Attester is a user device or edge node, precise coordinates may constitute Personally Identifiable Information (PII). In such deployments, privacy-technique = "zkp" SHOULD be used to prove geofence compliance without disclosing exact location.¶

• Mixed deployments: Appraisal Policy for Evidence SHOULD allow the Verifier Owner to configure which privacy technique is acceptable per Attester class or per geofence policy.¶

Implementers SHOULD select the privacy technique appropriate to their deployment context rather than applying ZKP uniformly.¶

6.2. Location Spoofing

6.3. Zero-Knowledge Proof Security

V-PEA's privacy-technique = "zkp" mode uses Plonky2 proofs (a STARK-based proof system using FRI commitments). The following properties and threats apply:¶

• Circuit correctness is the primary attack surface. A ZKP proves only what its arithmetic circuit encodes. Errors in the geofence boundary circuit — including precision errors, off-by-one boundary conditions, or incorrect coordinate system handling — yield proofs that are cryptographically valid but semantically incorrect. The geofence circuit MUST be independently audited before deployment.¶

• No trusted setup. Plonky2 is STARK-based and requires no trusted setup phase, eliminating the class of attacks arising from compromised SNARK setup parameters. Implementations substituting a different zkp-format MUST ensure it also provides transparent setup, or MUST document the resulting trust assumptions.¶

• Computational soundness. STARK security is computational, not unconditional, and relies on the collision resistance of the underlying hash function. Implementations SHOULD target at least 128-bit security and MUST document the proof system parameters (field size, hash function, FRI parameters) to enable independent security analysis.¶

• URI availability. When privacy-technique = "zkp", the Verifier MUST reject Evidence if the zkp-proof-uri cannot be resolved or the fetched proof bytes do not match geolocation-proof-hash.¶

• Proof freshness. A valid ZKP proves location at proof-generation time. The nonce and timestamp freshness requirements that apply to tpm-quote-seal apply equally to ZKP proofs: Verifiers MUST reject proofs whose timestamp falls outside the configured freshness window.¶

• Prover integrity. A compromised prover can produce false proofs even for a correctly specified circuit. This threat is mitigated by V-PEA's TPM binding: the tpm-quote-seal covers geolocation-proof-hash, so a false proof can only be embedded in a bundle that also passes TPM quote verification for an approved platform. The ZKP privacy guarantee is only meaningful in conjunction with verified platform integrity.¶

8.1. Normative References

• {{!RFC9334}}¶

• {{!RFC2119}}¶

• {{!RFC8174}}¶

• {{I-D.richardson-rats-geographic-results}}¶

• {{I-D.mw-wimse-transitive-attestation}}¶

• {{I-D.ietf-wimse-architecture}}¶

8.2. Informative References

• {{!RFC7942}}¶

• {{I-D.ramki-ptp-hardware-rooted-attestation}}¶

B.1. Gating Decisions on Attestation Results

A Relying Party consumes the Attestation Result produced by the Verifier and applies its Appraisal Policy for Attestation Results to make application-specific decisions. Common decision types include:¶

• Credential issuance: Issue or renew a workload credential only when the Attestation Result satisfies policy.¶

• Key release: Release decryption keys or model weights only to Attesters with a positive, fresh Attestation Result.¶

• Access authorization: Gate access to sensitive APIs or data stores on a valid Attestation Result.¶

In intermittently connected edge deployments, local operation can continue during outages, while centralized policy can be enforced on renewal and on release of high-value secrets once connectivity is available.¶

B.2. Distributed Credential Issuance and Scaling

To support edge deployments and intermittent connectivity, credential issuance by a Relying Party may be distributed within a sovereign boundary.¶

• Edge issuance: Credentials may be issued by a Relying Party deployed within the same boundary as the Attesters.¶

• Scoping: Issued credentials should be scoped so they are not accepted outside the intended deployment boundary (for example, via trust bundle partitioning and policy).¶

• Renewal gating: Relying Parties should renew short-lived credentials only when the Attestation Result for integrity and residency is valid for the requested freshness window.¶

B.3. Mobility and Handover

When an Attester moves between anchors or boundaries, the Target Environment (Workload Identity Agent) should trigger a new V-PEA attestation cycle that reflects the new LAH and current residency.¶

Verifiers should treat this as a normal re-attestation event: - platform integrity continuity can remain stable, but - residency Claims should be re-evaluated against the geofence policy for the new anchor/boundary.¶

B.4. Location Anchor Hosts

To scale location sensing, a deployment may use dedicated anchors:¶

• End-user anchors: A user device (for example, a phone) can serve as an LAH for a nearby client device. The mechanism by which the anchor establishes its own location (and any proximity evidence it may provide) is out of scope for this document.¶

• Data center anchors: A small set of hosts can act as LAHs for a cluster. Timing-based mechanisms (for example, PTP-derived) may assist in establishing relative location; protocol details are deferred to future profiling work (see {{I-D.ramki-ptp-hardware-rooted-attestation}}).¶

C.1. Nonce Chain and Merkle Audit Log

One way to satisfy the freshness requirements in this profile is through a chained nonce and Merkle audit log. Where bundle[n] denotes the JCS-canonicalized lah-bundle object at attestation interval n:¶

chain[n] = SHA-256(chain[n-1] || SHA-256(JCS(bundle[n])))
nonce[n]  = HMAC(secret, n || chain[n-1])

C.2. Key Registry and Synchronization

• A central Verifier maintains a registry of accepted AK public keys and associated metadata (for example, EK certificate chain, hardware identity, and status).¶

• An Edge Verifier may maintain a local registry to support disconnected operation and periodically synchronizes updates to the central registry.¶

C.3. Key Rotation

To prevent rogue key injection during rotation:¶

• The central registry should accept a new AK only if the Edge Verifier provides a rotation proof that chains the new AK to previously accepted state.¶

• A rotation proof should be a JCS-canonicalized object signed by the previously accepted AK (or, if available, validated by a fresh hardware-rooted OOB quote).¶

{
 "new-ak-pub": "Base64URL_Encoded_Public_Key",
 "serial-number": "AK_Serial_XYZ",
 "timestamp": 1708845600,
 "hardware-uuid": "Host_Hardware_UUID",
 "signature": "Base64URL_Signature_from_Previous_AK"
}

C.4. Credential Activation and Re-Verification

Credential activation (for example, TPM2_MakeCredential) is expensive to run on every request. Verifiers should perform it on events such as:¶

• Initial onboarding
  ¶

• Reboot / reset detection (for example, TPM clock/reset counters)
  ¶

• Policy violations or drift signals (for example, firmware or inventory changes)
  ¶

• Failure of location evidence checks
  ¶

• Explicit elevation to higher assurance policy
  ¶

Between full activations, Verifiers may accept fresh quotes from registered AKs as proof of continued compliance, subject to policy.¶

C.5. Revocation and Health Signals

• The Edge Verifier should maintain a per-node health signal (for example, tamper, firmware policy violations).¶

• On severe health signals, the Verifier should revoke the relevant AK(s) and reject identities derived from them according to policy.¶

C.6. Disconnected Operation (Leased Attestation Result)

For intermittent connectivity, the Verifier may produce Attestation Results with extended validity (a lease) under policy. If a lease is used:¶

• The Verifier should revoke or cease producing positive results locally on tamper/drift signals.¶

• The Attester should re-attest and satisfy current policy on reconnection before the Relying Party accepts a new Attestation Result or releases high-value secrets.¶

F.1. Example Instance (privacy-technique = "zkp")

{
  "lah-bundle": {
    "tpm-ak": "-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG...\n-----END PUBLIC KEY-----",
    "geolocation-id-hash": "7f4a2c1b9e3d8f0a6b5c4d2e1f0a9b8c...",
    "geolocation-proof-hash": "c8bc2ed62a7a650d99e0884197cdf345...",
    "privacy-technique": "zkp",
    "geolocation-payload": {
      "zkp-proof-uri": "https://verifier.example/v1/proof/c8bc2ed6...",
      "zkp-format": "plonky2"
    },
    "nonce": "ZmUyZjdmMzlmZGVlZWQxOTM1YjY0Mjk0...",
    "timestamp": 1740693456,
    "tpm-quote-seal": "ARoAAQALAAUACwEA...",
    "target-environment-image-digest": "a1b2c3d4e5f6...64-char-hex-sha256"
  },
  "mno-location": {
    "mno-key-cert": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...",
    "mno-sig": "MEYCIQDx9z2k..."
  }
}

F.2. Sensor Type Input Recipes

The following recipes define how geolocation-id-hash is constructed from different sensor types. The Verifier sees only the opaque hash — never the raw identifiers.¶

H.1. Relationship to WIMSE Architecture

The WIMSE Architecture {{I-D.ietf-wimse-architecture}} defines a credential issuance and workload identity framework. V-PEA produces Attestation Results that WIMSE credential issuers consume as trust inputs. The following mapping shows how V-PEA RATS roles correspond to WIMSE entities:¶

H.2. Workload Binding Fields

In a WIMSE deployment the Relying Party (SPIRE Server) may require additional context to associate the Attestation Result with a specific credential issuance event. The following fields are carried outside the V-PEA Evidence structure, typically in the credential issuance request or as Relying Party policy inputs:¶

These fields are not part of V-PEA Evidence. They are consumed by the Relying Party when applying its Appraisal Policy for Attestation Results.¶

H.3. X.509 Extension for Downstream Consumers

When the WIMSE Relying Party acts as a CA (for example, SPIRE Server issuing X.509-SVIDs), it MAY embed V-PEA Attestation Result information as an X.509 extension (OID 1.3.6.1.4.1.65284.1.1). Implementations SHOULD mark this extension as CRITICAL so that any downstream consumer that does not understand it will reject the credential, enforcing fail-closed behavior for residency-constrained workloads.¶