RFC-0003: Trust Model

Status: Last Call · Date: 2026-07-17 · Editors: Untilum project — hello@untilum.com

Part of the TSP RFC series; see the series index for the Last Call window and how to comment. The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY in this document are to be interpreted as described in BCP 14 [RFC 2119] [RFC 8174] when, and only when, they appear in all capitals.

Abstract

This document assigns every party and input in the Untilum Protocol to one of three trust tiers: irreducibly trusted mathematics and pinned constants (Tier 0); beacon networks, semi-trusted within bounds set by the unlock policy (Tier 1); and everything else — storage, endpoints, receipts, the platform itself — untrusted and either cryptographically verified before use or treated as advisory (Tier 2). It also states, as explicit prohibitions, what the protocol deliberately never trusts.

1. Principle

Untilum minimizes who must be trusted by maximizing what can be verified. The conversion rule, applied uniformly: every external input is cryptographically verified before use; anything unverifiable is treated as advisory. There are no trusted servers in the protocol — only trusted mathematics and pinned public constants.

2. Trust tiers

Tier 0 — Trusted (irreducible)

• The mathematics: AES-256-GCM, Argon2id, HKDF-SHA256, SHA-256, Ed25519, BLS12-381 pairings and the IBE construction over them.
• Audited implementations of that mathematics (tlock-js, @noble/curves, @noble/hashes, Web Crypto, hash-wasm). The protocol forbids novel primitives; this tier grows only by adding audited libraries, never by writing cryptography.
• Pinned constants embedded in the documents and implementations: beacon group public keys, chain hashes, genesis/period (the normative values: tsp-v1.md §5). These are the trust anchors — a capsule verifier that fetches its verification keys from a network has no anchor at all.
• The opener’s local execution environment. A keylogged machine defeats any protocol (RFC-0002 §3).

Tier 1 — Semi-trusted (bounded by policy)

• Beacon networks — trusted for exactly two properties, each independently bounded:
  • not producing round signatures early (early-opening resistance) — bounded by the allOf policy: no single network is trusted alone;
  • continuing to produce them (liveness) — bounded by the anyOf policy and by mirrors/custodial fallbacks.
  • Never trusted for honesty of served data — that is verified (Tier 2).

Tier 2 — Untrusted (verified or advisory)

• Storage providers and gateways — every fetched byte is digest-checked (payload.hash, dataHash); locators are advisory (RFC-0004).
• Beacon endpoints, relays, mirrors, manually pasted rounds — every signature is BLS-verified against the Tier-0 pinned key; the source is irrelevant (RFC-0005 §4).
• The Untilum platform, SDK distribution, and applications — replaceable per the layering rule; a capsule must open under an independently written conforming implementation.
• Receipts and their bearers — a receipt has no authority; every claim is re-derived from the capsule (RFC-0007 §4).
• Capsule documents themselves as parser input — structurally validated before any cryptography (RFC-0002 §T9).

3. What is deliberately NOT trusted

Stated as prohibitions, because each has tempted a design shortcut:

• No server is trusted to hold plaintext, passwords, or keys — so none ever receives them.
• No beacon source is trusted, only the beacon signature — so verification is unskippable.
• No storage locator is trusted — so the digest is always the authority.
• No version of this project’s own software is trusted as the sole opener — so the format is public and the decryptor is self-contained.
• No future maintainer is trusted to keep these properties — so changes to them require the process in RFC-0008 §5.

4. Trust statement for users

The honest one-paragraph summary applications SHOULD surface: “Your file is encrypted on your device. Opening requires both your password and a public randomness value that will not exist until your chosen date. We never have your password, your key, or your file’s contents — which also means we cannot recover them for you. Before the date, nobody — including us, our storage providers, or any single randomness network under the strict policy — can open the capsule. The mathematics, not our goodwill, enforces this.”

5. Security Considerations

The trust tiers are this document’s security argument: Tier 0 is the protocol’s entire trusted computing base, and it contains no servers, no organizations, and no network sources — only mathematics, audited implementations of it, pinned constants, and the opener’s own machine. Misclassifying an input upward (for example, trusting a beacon endpoint rather than the verified beacon signature, or a storage locator rather than the digest) silently voids the threat analysis of RFC-0002. The prohibitions in §3 exist because each names a shortcut that would perform exactly such a misclassification.

6. References

6.1. Normative

• [RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
• [RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, May 2017.
• [TSP-V1] “Untilum Protocol (TSP) — Version 1”, ../spec/tsp-v1.md — §5 normative beacon constants.

6.2. Informative

• RFC-0002, RFC-0004, RFC-0005, RFC-0007, RFC-0008 — this series.

Editors’ Addresses

Untilum project — Editors of the TSP RFC series Email: hello@untilum.com · Issues: https://github.com/untilum/protocol/issues

Revision History

Date	Status	Change
2026-07-07	Draft	Initial version.
2026-07-17	Last Call	Publication pass: BCP 14 boilerplate, Abstract, Security Considerations, References, Revision History added; no normative changes. Entered Last Call per RFC-0008 §4.