Privacy Preserving Verifiable Geofencing with Residency Proofs for Sovereign Workloads

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 14 September 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Operators of sovereign and high-assurance workloads need cryptographic assurance that sensitive computation occurs only on approved hardware within approved geographic boundaries. Traditional methods — IP-based geolocation, region labels, bearer tokens — are easily spoofed, stolen, or replayed and provide no hardware-rooted verifiability. Key gaps include:¶

• Unverifiable location metadata: Location tags for data objects are typically unsigned, making provenance and integrity difficult to validate.¶
• Token theft and replay: Bearer tokens can be copied and replayed from unauthorized hosts or locations.¶
• Implicit trust in "region" and transit: A relying party often cannot cryptographically verify a server's physical residency, and requests may traverse intermediaries that expand the effective trust boundary.¶

This document defines the Verifiable Geofencing Attestation Profile (V-GAP), a profile of the RATS Architecture {{!RFC9334}} that makes platform integrity and geofence residency verifiable inputs to workload credential issuance. V-GAP enables a Relying Party (or credential issuer) to require Evidence that:¶

1. the Workload Identity Agent is running on an approved, measured platform (platform integrity); and¶
2. that platform is resident within an approved geographic boundary, optionally without revealing coordinates (residency).¶

To maintain location privacy while providing cryptographic verifiability, V-GAP supports Transparent Zero-Knowledge Proofs (ZKPs) — non-interactive, hash-based proofs that allow a platform to demonstrate "in-zone" residency without disclosing exact coordinates and without requiring a trusted setup.¶

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 {{!RFC2119}} {{!RFC8174}} when, and only when, they appear in all capitals, as shown here.¶

3. Key Terms

Data Residency:

Requirement that data processing and storage remain within an approved geographic boundary.¶

Geofencing:

Enforcement that workloads execute only on approved hosts within an approved geographic boundary.¶

Workload Identity Agent:

On-host component that issues workload identities (for example, SVIDs) to local workloads, subject to verifier-approved evidence.¶

Location Anchor Host (LAH):

Trusted host or device that produces location evidence used to establish residency within a geofence. In RATS terms, the LAH is the Attester.¶

Workload Host:

Physical or virtual machine running the Workload Identity Agent and workloads; produces platform evidence. Unless otherwise stated, this document assumes the unified deployment model in which the Workload Host and the Location Anchor Host (LAH) are the same machine.¶

Composite Geolocation:

Location estimate fused from multiple sources and accompanied by a quality indicator.¶

Proof of Residency (PoR) / Co-location:

Evidence that binds a workload (or Workload Host) to an approved local environment and geofence for a specific attestation interval.¶

Silicon Root of Trust:

Hardware trust anchor that supports measured boot and protects attestation keys.¶

Transparent Zero-Knowledge Proof:

ZKP that does not require a trusted setup; used to prove "inside an approved zone" without revealing precise coordinates.¶

Workload Identity Management Plane:

Issues and validates workload identities and trust bundles based on verifier results and policy. In RATS terms, this plane acts as the Relying Party and Credential Issuer.¶

Host Identity Management Plane:

Verifies platform integrity and residency evidence, and manages attestation key registration and platform health state (often via OOB paths). In RATS terms, this plane acts as the Verifier.¶

V-GAP (Verifiable Geofencing Attestation Profile):

Nested evidence format defined in this document for binding identity to verified platform integrity and verified residency.¶

N_fusion (Workload Fusion Nonce):

Fresh nonce used to bind identity issuance to a specific attestation interval, delivered by the Workload Identity Management Plane. Corresponds to the nonce field in the lah-bundle.¶

4. Use Cases

This profile supports attested data residency and geofencing for workloads and (optionally) users. Common use cases fall into: server-centric enforcement, user-centric enforcement, and compliance and risk reduction.¶

5. Verifiable Geofencing Attestation Profile (V-GAP)

V-GAP is a profile of the RATS Architecture {{!RFC9334}} that binds a Workload Identity Agent to (1) hardware-rooted platform integrity and (2) verified residency within a configured geofence. The Attester (Location Anchor Host) produces a V-GAP Evidence structure (lah-bundle) that the Verifier (Host Identity Management Plane) appraises to produce an Attestation Result.¶

Attester (LAH)
    |
    | V-GAP Evidence (lah-bundle)
    v
Verifier (Host Identity Mgmt Plane)  <--- Endorsement (MNO)
    |
    | Attestation Result
    v
Relying Party + Credential Issuer (Workload Identity Mgmt Plane)
    |
    | X.509-SVID with V-GAP extension
    v
Downstream Relying Party (mTLS peer)

{
  "lah-bundle": { },
  "mno-endorsement": { },
  "workload": { }
}

6. Security Considerations

V-GAP reduces reliance on spoofable location signals and stolen tokens by making integrity and residency cryptographically verifiable. Implementers still need to address the following threats:¶

• Replay and mix-and-match: Use nonces and evidence stapling so that old location evidence cannot be combined with a fresh platform quote (or vice versa).¶
• Location spoofing: Treat sensor and network inputs as adversarial. Prefer multiple, corroborating sources where feasible, and apply conservative policy when evidence quality degrades.¶
• Relay and displacement: When proximity mechanisms are introduced in future profiles, implementers should be aware that they are vulnerable to relay attacks and anchor displacement. Mitigations (such as tight RTT-based acceptance windows and anchor health attestation) are deferred to those future profiles.¶
• Management plane compromise: OOB paths reduce dependence on the host OS but introduce dependence on the management controller and its network. Protect this plane with secure boot, authenticated updates, strong access controls, network segmentation, and audit logging.¶
• Time and freshness: Verifiers MUST enforce bounded freshness windows and MUST define recovery behavior (re-attestation, quarantine, or revocation) when clocks drift or evidence becomes stale.¶
• Registry and allowlist integrity: Protect key registries and policy stores against tampering; treat them as high-value privileged assets.¶
• Privacy: Avoid unnecessary collection or retention of precise location data. Prefer "in-zone" proofs (ZKP) where policy permits.¶

7. IANA Considerations

IANA is requested to register the following Object Identifier (OID) in the "SMI Numbers" registry under the "SMI Private Enterprise Numbers" (1.3.6.1.4.1) branch, or as appropriate for the V-GAP profile.¶

• OID: 1.3.6.1.4.1.65284.1.1¶
• Description: Verifiable Geofencing Attestation Profile (V-GAP) Evidence Bundle¶
• Reference: This document.¶
• PEN: 65284 (IANA Private Enterprise Number assigned to Ram Krishnan)¶

Appendix A. Operational Guidance

Appendix B. Scalable Fleet Management

Large deployments need lifecycle management for the attestation keys referenced by V-GAP (for example, tpm-ak) and for the policies that authorize them.¶

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

{
 "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"
}

Appendix C. Deployment Patterns

Implementations commonly fall into the following patterns, differing in how platform integrity Evidence and the tpm-quote-seal are collected:¶

• In-band host attestation: Evidence collected by host software (for example, Keylime-style deployments). In this pattern, the Relying Party (for example, SPIRE Server) generates N_fusion and shares it with the Verifier (for example, the Keylime Verifier) over a server-to-server channel. The Keylime Verifier then delivers N_fusion to the Keylime Agent running on the host, which collects TPM and geolocation evidence, assembles the lah-bundle, and returns it via the host-side channel. This pattern is well-suited to commodity servers and cloud VMs where a BMC path is not available or not required.¶

• Out-of-band management: Evidence collected via a management controller / BMC path (for example, iLO-class OOB management such as HPE OneView). In this pattern, the Relying Party (for example, SPIRE Server) generates N_fusion and shares it with the Verifier (for example, HPE OneView) over a server-to-server channel. The Verifier delivers N_fusion to the host via the BMC / OOB path — bypassing the host OS entirely. The host TPM seals the lah-bundle with that nonce, and the sealed bundle is returned via the same OOB path. This pattern is recommended for high-assurance environments where the host OS is part of the threat model.¶

• Cloud-hosted attestation environments: Provider mechanisms exposing measured boot and TPM-backed claims (for example, Nitro-class enclaves or shielded VM instances). The cloud provider supplies a hardware-rooted quote that can serve as the tpm-quote-seal; the geolocation claim is typically derived from the provider's zone or region attestation. Implementations should verify that the provider's attestation scope satisfies the geofence policy.¶

Appendix D. Policy Use

Relying parties and credential issuers can use V-GAP Attestation Results as inputs to authorization.¶

• ABAC: Residency and integrity can be mandatory claims for sensitive operations.¶
• KMS gatekeeping: Release of high-value assets (for example, decryption keys) should depend on a recent successful verification result.¶
• Fail closed: If V-GAP Evidence is carried in an X.509 extension and marked CRITICAL, any implementation that does not understand the extension will reject the credential.¶

Appendix E. V-GAP Examples and Sensor Recipes

{
  "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...",
    "workload-identity-agent-image-digest": "a1b2c3d4e5f6...64-char-hex-sha256"
  },
  "mno-endorsement": {
    "mno-key-cert": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...",
    "mno-sig": "MEYCIQDx9z2k..."
  },
  "workload": {
    "workload-id": "spiffe://example.org/python-app",
    "key-source": "tpm-app-key"
  }
}

Appendix F. Implementation Status

[Note to RFC Editor: This section may be removed before publication as per {{!RFC7942}}.]¶

A reference implementation of the V-GAP profile is publicly available:¶

• Repository: https://github.com/lfedgeai/AegisSovereignAI¶
• Path: hybrid-cloud-poc/¶
• License: Apache 2.0¶

The implementation demonstrates the in-band host attestation deployment pattern ({{deployment-patterns-informative}}) using:¶

• TPM 2.0 hardware root of trust (AK-based quotes, PCR 15 TOCTOU protection)¶
• SPIRE (Relying Party + Credential Issuer) with a custom unifiedidentity plugin that embeds the lah-bundle as an X.509 extension (OID 1.3.6.1.4.1.65284.1.1)¶
• Keylime (Verifier) with IMA measurement of the SPIRE agent binary (workload-identity-agent-image-digest)¶
• Plonky2 STARK prover for privacy-technique = "zkp" geofence proofs¶
• Geolocation sensor cascade: Mobile/CAMARA, GNSS/GPS, and config-file fallback with IMEI/IMSI binding for geolocation-id-hash¶

The implementation includes automated end-to-end tests (./run-demo.sh) that exercise the full attestation flow from TPM quote construction through ZKP proof generation and SVID issuance with embedded V-GAP Evidence.¶

Appendix G. Data Residency References

India -- Reserve Bank of India (RBI): Payment System Data Localization (2018): From RBI Circular RBI/2017-18/153 (April 6, 2018): "All system providers shall ensure that the entire data relating to payment systems operated by them are stored in a system only in India. This data should include the full end-to-end transaction details / information collected / carried / processed as part of the message / payment instruction."¶

South Korea's Data Localization Regulations -- Geospatial Information Management Act (Spatial Data Act): Article 16, Paragraph 1: Prohibits the export of state-led survey data.¶

Authors' Addresses