Cryptographic Attestation: What an Ed25519 Sovereignty Receipt Actually Proves

Most data sovereignty claims are made in marketing copy. They live in PDFs, in certification pages, in sections of vendor agreements that legal teams review once and then file away. None of them are independently verifiable at the time of an audit.

Sovereign AI Gateway takes a different approach: we issue cryptographically signed attestation documents for each client organisation, formatted so that your compliance officer, IPC auditor, or LSO inspector can independently verify the signature without calling us, without trusting our word, and without engaging a third party.

This post explains how the mechanism works, what it proves, and how you can verify it yourself using open-source tools.

Why Signatures, Not Promises

A signed document differs from a policy promise in one fundamental way: you can verify a signature mathematically. If the signature is valid, the document was produced by the holder of the corresponding private key and has not been modified since signing. No trust in the issuer is required beyond the initial verification of the public key — and we publish our public key at a well-known URL, so even that initial step is auditable.

Ed25519 is an elliptic-curve digital signature algorithm based on Curve25519, designed by Daniel J. Bernstein and colleagues. It is widely regarded as the most practically secure signature algorithm in common use: fast, compact, resistant to side-channel attacks, and with no known parameter manipulation vulnerabilities of the kind that affected earlier elliptic-curve standards. It is the signature scheme used in SSH keys, Signal's protocol, and modern TLS deployments.

What Our Attestation Documents Contain

Each attestation document is a JSON structure with two top-level fields: a payload and a signature. The payload contains:

• schema_version: The attestation format version, for forward compatibility.
• issued_at / valid_until: ISO 8601 timestamps. Documents are valid for 12 months with on-demand re-issuance available.
• issuer: Company name and jurisdiction (Trango Compute Inc., Ontario, Canada).
• client_org: Your organisation identifier, so the document is specific to your account — not a generic company-wide claim.
• infrastructure: The specific colocation facility (eStruxture Toronto), the governing law jurisdiction (Ontario, Canada), and attestations that no US infrastructure is in the data path.
• residency_statement: A plain-language statement of the sovereignty guarantee, suitable for inclusion in audit submissions.
• legal_status: Our Ontario CCPC registration status and the assertion that we are not subject to the US CLOUD Act.

The signature field contains the base64-encoded Ed25519 signature over the canonical JSON serialisation of the payload (keys sorted lexicographically, no extra whitespace). This canonical form is specified so that independent verifiers can reproduce it without ambiguity.

How to Verify the Signature

Verification requires three things: the attestation document, our public key, and any Ed25519 verification library. Here is a Python example using the standard cryptography package:

from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PublicKey
from cryptography.hazmat.primitives.serialization import load_pem_public_key
import json, base64, urllib.request

# Fetch Trango's published public key
with urllib.request.urlopen(
    "https://sovereignai.trango-compute.com/.well-known/attestation-pubkey.pem"
) as r:
    public_key = load_pem_public_key(r.read())

# Load your attestation document
with open("attestation.json") as f:
    doc = json.load(f)

# Reproduce the canonical payload
canonical = json.dumps(
    doc["payload"], sort_keys=True, separators=(",", ":")
).encode()

# Raises InvalidSignature if tampered — silent success if valid
public_key.verify(base64.b64decode(doc["signature"]), canonical)
print("Attestation valid. Sovereignty verified.")

The same verification can be performed with OpenSSL, Node.js (crypto.verify), Go's ed25519.Verify, or any library implementing RFC 8032. We deliberately chose a standard algorithm and a standard JSON format so that no Trango-specific tooling is required.

What the Attestation Proves

A valid signature on our attestation document proves:

• The document was produced by the holder of Sovereign AI Gateway's Ed25519 private key.
• The document has not been modified since it was signed.
• The assertions in the payload — regarding data residency, legal jurisdiction, and CLOUD Act non-applicability — were made by us at the time of issuance.

It does not prove, in a technical sense, that every individual API request stayed in Ontario — that is addressed by architectural controls (network egress lockdown, loopback-only inference binding) and per-request audit logs. What it proves is that the entity making these sovereignty assertions is cryptographically identified, and that the assertions cannot be quietly modified after the fact.

Using the Attestation in Audit and Compliance Submissions

The attestation document is formatted for direct use in:

• IPC submissions: The residency_statement and legal_status fields use language aligned with IPC review criteria for PHI custodians.
• LSO due diligence files: The document answers LSO's three core cloud diligence questions (where, who, what happens under compulsion) in a single verifiable record.
• Board and risk committee reporting: A PDF-formatted version suitable for non-technical audiences is available on request.
• Vendor assessment questionnaires: The attestation can accompany standard security questionnaire responses as independent corroboration.

Rotating Keys and Long-Term Verifiability

We rotate our signing key annually. When we rotate, we publish the new key at the well-known URL and archive the previous key at a versioned URL (/.well-known/attestation-pubkey-v1.pem, etc.). Attestation documents include the key version in their payload, so historical documents can always be verified against the key that signed them.

This means an attestation document issued today remains independently verifiable five years from now — important for organisations that need to demonstrate compliance at the time of an AI deployment, not just at the time of an audit.