RFC-003 — Trust Bundles

Status: Draft Created: 2026-06-08 Updated: 2026-08-18 Authors: Genesis Mesh contributors Requires: RFC-001, RFC-002, RFC-004

Abstract

A trust bundle is a portable, redacted collection of a sovereign’s public trust material, assembled so that an operator can review another sovereign before deciding to recognize it. This RFC defines what a bundle contains, what validation of a bundle does and does not prove, and the redaction rules that keep a bundle safe to share. A trust bundle is review input; it is never itself a grant of trust.

Motivation

Before a treaty (RFC-002) is issued, the accepting operator needs something to review: the candidate sovereign’s identity, genesis, recognition posture, revocation feed, and recognition graph, fetched from public endpoints and frozen into a single reviewable artifact. The trust bundle exists so that this review material is portable, hashable, and auditable without exposing any private control material.

Terminology

  • Trust bundle — the portable artifact defined here.

  • Source endpoint — the public base URL the bundle was assembled from.

  • Bundle hash — a content hash recorded by the importer as an audit anchor.

  • Import receipt — the importer’s record of what was reviewed and whether trust was granted afterward (out of band).

Normative requirements

  1. A trust bundle MUST identify itself with bundle_type and bundle_version so consumers can detect format changes.

  2. A trust bundle MUST carry the subject’s public identity material: sovereign_id, sovereign_metadata, and genesis.

  3. A trust bundle MUST carry the subject’s recognition_policy and revocation_feed (or an explicit skipped marker) so the reviewer can see the subject’s current recognition and revocation posture.

  4. A trust bundle MUST carry a connectome section summarizing recognition edges, active treaties, and revoked trust material (RFC-006).

  5. A trust bundle MUST record created_at and source_endpoint.

  6. A trust bundle MUST NOT contain any private material listed under Redaction rules.

  7. Importing a trust bundle MUST NOT, by itself, grant trust. The act of granting trust is a separate, explicit operator action (typically issuing a treaty under RFC-002).

  8. An importer MUST be able to compute and record a stable bundle hash for audit.

Data model

The reference implementation builds the bundle in genesis_mesh/cli/trust_bundle.py (export_trust_bundle):

{
  "bundle_type": "<bundle type tag>",
  "bundle_version": "<format version>",
  "created_at": "<iso8601>",
  "source_endpoint": "https://na.example.org",
  "sovereign_id": "USG-NB",
  "network_version": "<version>",
  "sovereign_metadata": { "...": "RFC-001 identity material" },
  "genesis": { "...": "public genesis document" },
  "recognition_policy": { "...": "subject recognition posture" },
  "revocation_feed": { "...": "RFC-004 feed or {\"status\": \"skipped\"}" },
  "connectome": {
    "summary": { "...": "RFC-006 counts" },
    "recognition_edges": [],
    "active_treaties": [],
    "revoked_trust_material": []
  },
  "endpoint_checks": {
    "healthz": "<status>",
    "readyz": "<status>"
  }
}

Verification rules

  1. A reviewer MUST treat bundle contents as claims to be checked, not as trust. Signatures inside embedded objects (genesis, attestations, treaties, feeds) are defined by their own RFCs — but bundle validation does not check any of them, and nothing in the bundle tooling does. Verifying them is the reviewer’s responsibility, using key material obtained independently of the bundle.

  2. Validation of a bundle proves only that the public material is internally consistent and well-formed at fetch time. It does NOT prove the subject is honest, available, or worthy of recognition, and it does NOT prove the bundle is authentic.

  3. A bundle authored entirely by one party passes validation by construction. Every consistency check compares one part of the bundle against another, so a party who wrote both sides satisfies all of them. An empty error list means “well-formed and self-consistent”, never “genuine”.

  4. Before relying on any bundle content, a reviewer MUST verify the subject’s genesis against a root key obtained from somewhere other than the bundle — a live query to the subject’s own endpoint, or an out-of-band channel.

  5. Bundle content MUST NOT be loaded into a trust store, a revocation state, or a recognition policy. A bundle is an unverified hint used to decide whether to begin a trust process, never an input to trust state itself.

  6. endpoint_checks reflect liveness at assembly time and MUST NOT be treated as a continuing guarantee.

  7. An importer SHOULD record an import receipt that links the bundle hash to the subsequent trust decision so the decision is auditable.

Security considerations

The bundle is self-attested

A bundle carries no signature of its own, and its validation consults nothing outside itself. Every check compares one part of the bundle to another, so an attacker who authors the whole bundle passes all of them — they wrote both sides. A bundle therefore proves nothing about who assembled it.

The practical consequences:

  • A bundle MUST be treated as an unverified hint that helps an operator decide whether to begin a trust process, never as evidence within one.

  • Bundle content MUST NOT be imported into trust state. A malicious bundle can otherwise inject forged recognition relationships, a treaty that does not exist, or a revocation feed with inconvenient revocations quietly removed.

  • The key a treaty is issued against MUST come from a live query to the subject’s own endpoint or an out-of-band channel, not from the bundle. The federation tooling already works this way.

This weakness is accepted, not fixed: promoting the bundle to a signed protocol artifact is a federation-design change, tracked under Open questions below.

Redaction rules

A trust bundle MUST NOT include any of the following (the redaction rules, mirrored from the proof-bundle schema):

  • Private keys.

  • Operator signatures over admin actions.

  • Admin nonces.

  • Raw request headers.

  • Full private genesis material beyond the public genesis document.

  • Local filesystem paths.

  • Database paths.

A bundle MAY include public endpoints, network names, public-key prefixes, attestation/treaty/feed identifiers, verification reason codes, and Connectome summary counts. Guiding rule: if a bundle needs private material to be convincing, the proof is not ready to share.

Operational considerations

  • Bundles are assembled from public endpoints, so assembling one SHOULD be possible by any reviewer, not only the subject operator.

  • Importers SHOULD keep import receipts as part of their audit trail, especially for adoption-proof workflows where the bundle backs a public claim.

Compatibility notes

  • bundle_version exists so consumers can branch on format. Consumers MUST reject a bundle_version they do not understand rather than guess.

  • Embedded objects follow their own RFCs; a change to those formats is governed by those RFCs, not this one.

Open questions

  • Should the bundle carry a detached signature by the assembling operator to bind created_at and source_endpoint, or is the recorded bundle hash plus import receipt sufficient? This is the open fix for the self-attestation weakness in Security considerations. Until it is answered, a bundle proves nothing about who assembled it, and the mitigation is procedural: treat the bundle as an unverified hint and verify the subject’s genesis independently.

  • Should bundles support incremental/delta refresh rather than full re-fetch for continuity checks (RFC-007)?