RFC-0001: Protocol Goals

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 states the goals (G1–G6) and explicit non-goals of the Untilum Protocol (TSP). TSP defines a self-describing document — the capsule — that keeps data confidential until a chosen future instant and is thereafter openable by anyone holding the password, without the permission, participation, or continued existence of any organization. Every other document in the series is evaluated against the priorities fixed here.

1. Purpose

The Untilum Protocol (TSP) defines a document — a capsule — that keeps data confidential until a chosen future instant, and after that instant is openable by anyone holding the password, with no permission from, participation of, or even continued existence of any organization.

2. Goals

Every protocol decision is tested against these, in priority order:

• G1 — Trustless timelock. Before the unlock instant, the capsule MUST be unopenable by everyone: the platform, the storage provider, the beacon operators individually, and the creator themselves. “We promise not to look” is not a mechanism; the mechanism is that the decryption key does not exist yet.
• G2 — Platform-independent opening. Opening MUST require only: the capsule bytes, the protocol documents, a beacon signature for the unlock round (from any source), and the password. No server, domain, or product of this project may be a dependency.
• G3 — Two independent factors. Opening = (time factor: beacon signature) AND (knowledge factor: password). The protocol MUST NOT degrade to one factor, and MUST NOT provide password storage or recovery.
• G4 — Longevity. Capsules are designed for 50–100 year horizons. Formats favor self-description, pinned constants, and boring, widely-implemented cryptography over novelty. Opening support is never removed (RFC-0009).
• G5 — Third-party verifiability. Anyone MUST be able to verify a capsule’s integrity, unlock parameters, and creator signature without being able to open it and without contacting the project (RFC-0007).
• G6 — Substrate independence. Storage (RFC-0004), beacons (RFC-0005), and identity (RFC-0006) are abstractions with pluggable implementations. No vendor or network is protocol-load-bearing.

3. Non-goals

The protocol deliberately does not attempt:

• Anonymity. Capsule documents are public; traffic analysis, storage-chain metadata, and creator signatures may all reveal who sealed what and when.
• Plaintext attestation. Nothing can prove what a capsule contains before it opens (see the receipt notice, RFC-0007).
• DRM / revocation. A capsule cannot be un-published or un-opened once its instant passes and the password is known.
• Key recovery. A forgotten password loses the capsule. Mitigations (custodians, social sharing of the password) live above the protocol.
• Legal authority. Receipts are cryptographic evidence, not notarization (RFC-0007 §4).
• Post-quantum timelock. The quantum risk to the timelock is early opening, and it is mitigated organizationally (custodians), not by PQ primitives — see RFC-0002 §T7 for the honest statement.

4. Conformance

An implementation conforms if it: produces capsules valid under the wire specifications (tsp-v1.md, capsule-v1.md); refuses to open or verify without the checks those specifications mark mandatory (beacon signature verification above all, tsp-v1.md §4.2); and passes the four critical tests — round-trip, no-time, no-password, forged-time (tsp-v1.md §8.5).

5. Security Considerations

The goals in §2 are this protocol’s security requirements; the corresponding threat analysis is RFC-0002, which serves as the security-considerations baseline for the entire series. The non-goals in §3 are deliberate security limitations — in particular the absence of anonymity, of key recovery, and of a post-quantum timelock — and implementations MUST NOT present them as protections the protocol does not make.

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.
• [CAPSULE-V1] “Capsule v1 — wire format”, ../spec/capsule-v1.md.

6.2. Informative

• RFC-0002 Threat Model; RFC-0007 Verification Model; RFC-0009 Compatibility Policy — 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.