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.
This document defines third-party verification for Untilum capsules: an eight-check report over format, algorithms, KDF floors, unlock arithmetic, beacon entries, payload hash, creator signature, and storage proofs, with pass/fail/skipped semantics in which nothing unverifiable ever passes silently. It also defines receipts — detached, authority-free projections of a capsule for handing to third parties, every claim of which is re-derived from the capsule itself.
Verification produces claims about a capsule, never inputs to opening it. The two pipelines share nothing: verify() touches no key material, derives no keys, and cannot be repurposed as a decryption oracle. Its audience is third parties — a counterparty, an auditor, a court-appointed expert — who must be able to run it with public tooling and no relationship to this project.
verify(capsule, { storage? }) -> VerifyReport evaluates eight checks, each reporting "pass" | "fail" | "skipped":
| Check | What it re-derives |
|---|---|
format |
Structural validity of the document (unknown fields rejected) |
algorithms |
Exact algorithm identifiers — no aliases, no downgrades |
kdfFloors |
KDF parameters meet the anti-downgrade floors |
unlockDate |
Round ↔ UTC arithmetic recomputed from pinned beacon constants (RFC-0005 §B4) |
beacons |
Beacon entries well-formed, chain identities pinned, ids unique |
payloadHash |
Ciphertext bytes hash to payload.hash (fetched via storage adapter when by-reference) |
creatorSignature |
Signature over the canonical signed fields (RFC-0006) |
storageProof |
Each storage entry re-fetched and byte-compared to its dataHash |
valid is true iff no check failed. The report additionally carries warnings: [] and errors: [] arrays explaining every non-pass result (normative shape: tsp-v1.md §10.1.3).
"skipped" with an explanatory warning. An unsigned capsule must be undistinguishable-by-accident from a verified-signed one — the distinction is the whole product.payloadHash and storageProof MUST work from the capsule JSON alone, with no network. The two exceptions exist only because they verify external bytes.A receipt is a detached projection of a capsule — its hash, payload digest, unlock parameters, beacon rounds, storage entries, creator key — packaged for handing to a third party, with a deterministic human-readable rendering.
The normative core: a receipt has no authority of its own. verifyReceipt(receipt, capsule) re-derives every claim from the capsule bytes; a mismatching receipt is worthless, and the capsule is always the authority. Receipts are never embedded in capsules (the receipt contains the capsule’s hash — embedding would be circular). Every rendering MUST carry verbatim:
This receipt provides cryptographic evidence of capsule creation, integrity, storage reference, and creator signature. It is not a notarization unless issued by an authorized notarial provider. It does not and cannot attest to the payload’s content before the unlock date.
An altered notice fails verification. What a receipt proves: that sealed data existed, unmodified, at a time, unlockable at a date, signed by a key. What it cannot prove: anything about the plaintext before the unlock date. Legal admissibility is jurisdiction-dependent and out of scope (RFC-0001 §3).
Verification and opening share nothing by design: verify() touches no key material and MUST NOT be extensible into a decryption oracle. The skipped-vs-pass distinction (R1) is itself a security property — collapsing “nothing was claimed” into “verified” is a silent downgrade of assurance, and R2’s fail-closed rule prevents unknown mechanisms from laundering unverifiable claims as passed ones. The receipt notice is normative and tamper-evident (an altered notice fails verification) precisely because receipts travel to parties who never see this specification.
../spec/tsp-v1.md — §10.1.3 normative report shape.Untilum project — Editors of the TSP RFC series Email: hello@untilum.com · Issues: https://github.com/untilum/protocol/issues
| 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. |