Cedulon Checkpoints: Epoch Witnesses and Transparency
draft-dogru-cedulon-checkpoint-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Emek Can Doğru | ||
| Last updated | 2026-09-17 | ||
| Replaces | draft-dogru-cedulon | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
companion implementation and test vectors
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-dogru-cedulon-checkpoint-00
Network Working Group E. C. Dogru
Internet-Draft VERAX TEKNOLOJI LIMITED SIRKETI
Intended status: Informational 17 September 2026
Expires: 21 March 2027
Cedulon Checkpoints: Epoch Witnesses and Transparency
draft-dogru-cedulon-checkpoint-00
Abstract
This document specifies epoch checkpoints, the transparency witness
and the anchoring of checkpoints as SCITT Signed Statements for the
Cedulon audit layer. The spend receipt, rail-extract reconciliation
and trust-root rules live in the companion Cedulon Core document. A
verifier that pins a witness key can detect a withheld or rolled-back
checkpoint; without that pin the suppression guarantee is
conditional.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 21 March 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Dogru Expires 21 March 2027 [Page 1]
Internet-Draft Cedulon Checkpoints September 2026
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. The witness root . . . . . . . . . . . . . . . . . . . . 3
2.2. Checkpoint claims . . . . . . . . . . . . . . . . . . . . 3
2.3. Genesis and continuity . . . . . . . . . . . . . . . . . 4
2.4. The transparency witness . . . . . . . . . . . . . . . . 4
2.5. Verification algorithm . . . . . . . . . . . . . . . . . 7
2.6. Finding codes . . . . . . . . . . . . . . . . . . . . . . 9
3. SCITT Anchoring . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. T11: Checkpoint suppression or rollback . . . . . . . . . 12
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
4.1. application/cedulon-checkpoint+cbor . . . . . . . . . . . 15
4.2. application/cedulon-inclusion+cbor . . . . . . . . . . . 16
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Normative References . . . . . . . . . . . . . . . . . . 17
5.2. Informative References . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
The core document [CEDULON-CORE] defines the spend receipt and the
reconciliation of those receipts against an authenticated rail
extract. That result says nothing about whether the issuer published
a complete checkpoint chain for the same window. This document
states that chain, the witness that makes suppression visible, and
the two media types those objects carry.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Dogru Expires 21 March 2027 [Page 2]
Internet-Draft Cedulon Checkpoints September 2026
2.1. The witness root
Section 2.4 describes what a transparency witness adds. An inclusion
receipt checked against the key it carries says that some log is
internally consistent, and a log is cheap to invent.
A verifier MUST obtain the transparency service's public key out of
band and MUST verify inclusion receipts against it (MUST-T11-15).
Inclusion receipts that cannot be checked that way MUST NOT be used
as evidence, in either direction: they cannot establish that a
checkpoint was anchored, and they cannot establish that one was
withheld. A verifier SHOULD report that it left them out.
A log holds statements from everyone who uses it. A statement held
by a pinned log MUST additionally answer to the issuer root before it
counts as something that issuer published (MUST-T11-16); otherwise
another user's epoch, sitting in a shared log, reads as this issuer
publishing two checkpoints for one epoch.
Anchoring and withholding are different claims and need different
evidence. Establishing that a checkpoint was logged needs only the
statement hash. Establishing that an issuer withheld one needs to
know whose statement it is, which an inclusion receipt carrying no
statement body cannot say. Such a receipt MUST NOT be used to report
a withheld checkpoint, and MUST NOT be silently discarded either: a
real withholding must not be buried by removing the body (MUST-
T11-17).
2.2. Checkpoint claims
An epoch checkpoint MUST be COSE_Sign1-signed with the header profile
in [CEDULON-CORE] (COSE Profile) and MUST bind all of the following
(MUST-T11-1):
epoch, startMs, endMs, receiptCount, chainHeadHash, totals, and
prevCheckpointHash.
The checkpoint window is half-open [startMs, endMs) (MUST-T11-7).
receiptCount MUST equal the number of receipts (settled and aborted)
whose timestampMs falls in that window. chainHeadHash MUST equal
receiptHash of the last receipt in that window - the last link, in
issuer order (the prevReceiptHash chain, as step 6 of [CEDULON-CORE]
defines it), of the chain inside the window, not the last one
presented or the latest timestampMs - or null if the window is empty
(MUST-T11-2). Where totals is present it MUST sum only receipts with
outcome = settled; the one permitted absence is the signed redaction
below.
Dogru Expires 21 March 2027 [Page 3]
Internet-Draft Cedulon Checkpoints September 2026
An issuer that publishes a checkpoint without its totals MUST encode
totals as null in the signed payload (MUST-T11-12). An empty map is
an honest zero for an empty window and is not a redaction. Because
the redaction is inside the signature, it cannot be added to, or
removed from, a checkpoint after signing.
A verifier MUST NOT accept a redaction asserted anywhere but the
signed payload (MUST-T11-13). A presentation-layer flag alongside a
checkpoint is chosen by whoever presents it, which is the party under
audit; honouring such a flag would let that party switch off the
totals comparison for a checkpoint whose signed totals are wrong.
The structural claims (epoch, startMs, endMs, receiptCount,
chainHeadHash, prevCheckpointHash) MUST NOT be redacted: a checkpoint
missing any of them does not decode, and a verifier MUST treat it as
a failed checkpoint rather than as a redacted one.
2.3. Genesis and continuity
The first checkpoint in a presented chain is the genesis checkpoint
of that chain. Its prevCheckpointHash MUST be null. Epoch numbers
MUST be consecutive integers. Adjacent windows MUST satisfy
next.startMs = prev.endMs (MUST-T11-8).
A later checkpoint that omits a prefix of earlier epochs (prefix
deletion) is detectable only if an external witness (transparency
log) has recorded the missing prefix (MUST-T11-9). Without that
witness, T11 guarantees about suppression are *conditional*.
A verifier that holds witness receipts for the period under audit
compares what the witness recorded against what the chain presented,
and reports the difference under its own name (Section 2.4). A
witness that holds a checkpoint the presented chain omits is not the
same condition as a chain that leaves a gap in its own coverage, and
the two MUST NOT be reported under one identifier (MUST-T11-11). The
first says evidence is being withheld; the second says the evidence
shown is incomplete. An operator who cannot tell them apart cannot
tell an incomplete record from a concealed one.
2.4. The transparency witness
A checkpoint registered with a Transparency Service [RFC9943] is a
Signed Statement whose payload is the checkpoint COSE object and
whose content type is application/cedulon-checkpoint+cbor
(Section 3). What comes back, and what it proves, is stated as two
named tiers.
Dogru Expires 21 March 2027 [Page 4]
Internet-Draft Cedulon Checkpoints September 2026
*Tier 1 - the witness receipt.* The witness returns a co-signature
over the statement hash of what it recorded: a COSE_Sign1 whose
payload binds the statement hash, the entry index, and the witness's
tree head. Verifying it establishes exactly one sentence - "the
witness signed for this hash" - and nothing more; in particular it
does not establish membership in an append-only log. The receipt is
a signature over a statement rather than a proof of log membership.
The [RFC9942] citation applies in tier 2, where its mechanics are
actually performed.
On the wire the witness receipt is a COSE_Sign1 under [CEDULON-CORE]
(COSE Profile), signed by the witness key, with content type
application/cedulon-inclusion+cbor (Section 4.2). Its payload is a
deterministic CBOR map carrying three entries and is not a CWT claim
set: label 1 is the statement hash, label 2 the entry index, label 3
the tree head. The two hashes are text strings holding the lowercase
hexadecimal of a 32-octet SHA-256, the statement hash taken over the
octets of the statement the witness recorded; the entry index is an
unsigned integer. The hash strings are compared as issued and are
not passed through the hash-claim grammar the claim sets use; the
revision that moves them to byte strings will close that difference.
Entries under other labels are not defined, and a verifier of this
revision does not refuse them. The map carries no statement body: a
receipt that travels with the body carries it beside the COSE object,
not inside it (Section 2.1, MUST-T11-17). A receipt whose content
type is another value, or whose payload lacks one of the three
entries or carries one of another type, does not verify: the content
type is the check [CEDULON-CORE] (COSE Profile) makes on every object
of this profile, and the payload map is the one this paragraph
states.
A verifier MAY be given witness receipts for the period under audit.
It is a distinct input from the presented checkpoint chain, and
supplying it is optional: a verifier given none performs the same
steps, and reports the same findings, that it would if this input did
not exist (MUST-T11-10). Supplying an empty set is not the same as
supplying none. An empty set says a witness is configured and
recorded nothing, which is itself reportable; absence says no witness
was consulted.
A receipt binds a statement hash, not a statement. The body is not
carried by the receipt and a verifier will often not hold it. Two
levels of checking follow from that, and they are not the same (MUST-
T11-10).
Dogru Expires 21 March 2027 [Page 5]
Internet-Draft Cedulon Checkpoints September 2026
Every receipt MUST have its signature verified before it counts for
anything. That is what establishes the hash as one the service
signed for, and it is all that comparing recorded hashes against
presented ones requires: the verifier computes the statement hash of
each presented checkpoint itself.
A receipt accompanied by the statement body carries more, and MUST be
checked further before that body is relied on. The body's statement
hash MUST equal the hash the receipt binds, and the body MUST itself
verify as a checkpoint. A body that fails either check proves
nothing and MUST be ignored rather than counted, while the receipt it
came with remains usable for the hash comparison. Equivocation is
the case that needs a body, because it compares claims rather than
hashes.
*Tier 2 - log membership.* A verifier MAY additionally be given, for
one recorded statement, the registered Signed Statement bytes (the
candidate entry) and an inclusion proof. When both are present, the
verifier MUST perform the verification of [RFC9942] Section 5.2.1
over them: hash the candidate entry bytes to obtain the leaf, apply
the proof to reproduce a root, and accept only when the leaf hash,
the proof's leaf index, and the reproduced root are all equal to the
statement hash, entry index, and tree head of one witness receipt
that verifies under the pinned witness key (MUST-T11-18).
Reproducing a root is deliberately not sufficient on its own: the
proof format below carries no domain separation between leaves and
interior nodes, and the exact match against a witness-signed receipt
is what closes the ambiguities that follow from that. A pair that
fails this check, or a candidate entry presented without a proof,
MUST be reported as a failing finding; the identifier witness-
inclusion-invalid names it.
The inclusion proof is an audit path: the leaf index, and the sibling
hashes from the leaf's level up to the root, lowest level first. The
tree is built over statement hashes as leaves; an interior node is
the SHA-256 of the concatenation of its two children's 32 raw bytes;
a level with an odd count pairs its last node with itself, so the
path needs no separate leaf count.
Where witness receipts are supplied and this pair is not, tier 2 was
not exercised, and the report MUST say so rather than letting the
tier pass silently (MUST-T11-19); the identifier witness-inclusion-
not-exercised names it, as a warning - the witness attested the
statement hash, and log membership was not proven. A pair that
verifies is silent, like every other passing check in the algorithm.
Dogru Expires 21 March 2027 [Page 6]
Internet-Draft Cedulon Checkpoints September 2026
What tier 1 establishes, and what it does not, is worth stating
plainly. It establishes that the service signed for that statement.
Whether the statement is a member of an append-only log is tier 2's
question, answered only where tier 2's inputs were supplied and
verified; whether the log has ever equivocated remains a property of
the service and its own proofs. A verifier that treats a tier-1
receipt alone as proof of log membership is claiming more than the
receipt carries.
2.5. Verification algorithm
A verifier MUST perform all of these steps and MUST report every
finding they produce (MUST-T11-2). They are numbered for reference,
not to require an evaluation order: no step short-circuits another,
and an implementation may evaluate them in any order that produces
the same set of findings.
The data dependencies are named, because "any order" read naively
would break them. Step 5 decides which witness receipts, and which
statement bodies, survive checking; steps 4 and 6 consume what
survives. Step 1 decides which checkpoints verified, and step 4
compares only those together with what step 5 admitted. An
implementation that ran a consumer against an unchecked producer
would not produce the same set of findings, so those orders are not
among the permitted ones.
These steps consume two products of [CEDULON-CORE] (Verification
algorithm): the working set that the issuer-pin step decides, and the
ref index that step 7 of [CEDULON-CORE] builds. The chain walk that
defines issuer order is step 6 of [CEDULON-CORE]. A fail-severity
finding these steps produce is a finding step 11 of [CEDULON-CORE]
treats as failing the audit (MUST-T10-4).
When a step names an identifier in backticks, that identifier SHOULD
be used for the condition in diagnostic output. The normative
requirement is the behaviour: report the condition, identified by the
ref or other handle given in the step. The identifiers are not an
interoperability surface.
1. Decode each checkpoint. Reject a failed signature, and reject a
kid that does not match the key obtained for the checkpoint
issuer, on the same terms as a receipt (MUST-T4-8). Require
receiptCount, chainHeadHash, and totals to match the receipts of
the working set in [startMs, endMs) as defined above (MUST-
T11-2); a receipt step 4 of [CEDULON-CORE] rejected is not among
them, or a forged receipt could satisfy a checkpoint count. The
identifier checkpoint-total-mismatch SHOULD be used for a failed
signature, a wrong receiptCount, or totals that disagree, and
Dogru Expires 21 March 2027 [Page 7]
Internet-Draft Cedulon Checkpoints September 2026
checkpoint-head-mismatch for a chainHeadHash that is not the last
link, in issuer order (step 6 of [CEDULON-CORE]), of the chain
inside [startMs, endMs) - "last receipt" binds to the chain, not
to presentation or to timestampMs. If the signed totals is null,
the verifier cannot perform the totals comparison for that
checkpoint. It MUST report that the comparison was skipped and
MUST treat the completeness guarantee as conditional; the absence
of a comparison is not a passed comparison (MUST-T11-12). The
identifier checkpoint-totals-redacted SHOULD be used for this
condition. receiptCount and chainHeadHash MUST still be checked.
A checkpoint that fails verification MUST NOT be treated as
redacted, whatever it claims about its own totals.
2. Every chained receipt MUST fall in exactly one checkpoint window.
A gap or double count MUST be reported as a window coverage
failure (MUST-T11-7, MUST-T11-8). The identifier window-coverage
SHOULD be used for this condition. The check runs against the
presented checkpoint windows and it is fail-closed: a receipt
that falls under none of them is this failure - including every
receipt when no checkpoint was presented, and receipts after the
last closed checkpoint's endMs. The text names that last state
an *open epoch*, and it is auditable only when the checkpoint
that closes it is issued; the name explains why the finding
fired, it does not soften it. Nothing about an absent checkpoint
is silent: uncovered evidence surfaces as a finding rather than
as a gap in the report.
3. Walk checkpoints in epoch order. prevCheckpointHash MUST equal
the SHA-256 of the previous checkpoint COSE bytes, or null for
genesis (MUST-T11-4). The identifier checkpoint-total-mismatch
SHOULD be used for a broken chain, which is the fourth condition
its table row names.
4. If two successfully verified checkpoints share an epoch number
and have different hashes, the verifier MUST report equivocation
(MUST-T11-3). The identifier equivocation SHOULD be used for
this condition. The checkpoints compared here are those
presented *together with* any carried by verified witness
receipts (step 5). A presented chain that satisfies MUST-T11-8
(step 2) cannot raise this finding on its own, because its epochs
are consecutive and no two of its members share an epoch. A copy
recorded by a witness is where the second one is found.
5. If witness receipts were supplied, verify them against the out-
of-band witness key (Section 2.1); receipts that cannot be
checked that way are not evidence in either direction and the
verifier reports that it left them out (MUST-T11-15); the
identifier unauthenticated-witness SHOULD be used for this
Dogru Expires 21 March 2027 [Page 8]
Internet-Draft Cedulon Checkpoints September 2026
condition. Discard any whose signature fails (MUST-T11-10). A
surviving receipt whose statement body verifies against the
issuer root is a statement that issuer published; one that does
not is another party's, and is not this issuer equivocating
(MUST-T11-16). The survivors are the recorded statement hashes
used in step 6. Where a receipt also carries the statement body,
discard that body unless its statement hash equals the one the
receipt binds and it verifies as a checkpoint; the surviving
bodies are what step 4 compares. Discarding a body does not
discard its receipt. This is tier 1 of Section 2.4. Where the
tier-2 pair - the registered Signed Statement bytes and an
inclusion proof - was also supplied, verify it as Section 2.4
states: apply the proof to the candidate entry's hash and accept
only on an exact match with a witness-signed receipt (MUST-
T11-18); a pair that fails, or a candidate without a proof, is
witness-inclusion-invalid and the audit MUST fail. Where witness
receipts were supplied and no tier-2 pair was, report witness-
inclusion-not-exercised as a warning (MUST-T11-19): the witness
attested the statement hash, and log membership was not proven.
6. Compare the surviving witness records against the presented chain
(MUST-T11-11). For each presented checkpoint with no surviving
record, report that it is not anchored; the identifier
checkpoint-not-anchored SHOULD be used. This is a warning: a
witness may have been configured after the checkpoint was issued,
and an operator's own gap is not evidence of concealment. For
each surviving record whose statement is absent from the
presented chain, report that a recorded checkpoint was withheld;
the identifier checkpoint-withheld SHOULD be used. This is a
finding and the audit MUST fail. A record that carries no
statement body cannot say whose statement it binds, so it MUST
NOT produce this finding; it is reported as an entry that could
not be attributed and makes the guarantee conditional, because a
real withholding must not be buried by removing the body (MUST-
T11-17). Such a record still establishes anchoring in the first
half of this step: proving that a checkpoint was logged needs
only its hash. The verifier MUST NOT report a withheld
checkpoint as a window coverage failure (MUST-T11-11).
2.6. Finding codes
The identifiers below are for diagnostic output. They are not an
interoperability surface. The codes the core algorithm can produce
are listed in [CEDULON-CORE] (Finding codes). A condition that makes
the audit fail is a finding. A condition that only makes the
completeness guarantee conditional is a warning. Warnings MUST still
appear in operator-facing output (MUST-T10-14).
Dogru Expires 21 March 2027 [Page 9]
Internet-Draft Cedulon Checkpoints September 2026
+===============================+===========+=======================+
|Code |Effect |Meaning |
+===============================+===========+=======================+
|checkpoint-total-mismatch |audit fails|Totals, count, |
| | |signature, or |
| | |checkpoint chain |
| | |failed. The signature |
| | |branch is reached where|
| | |no issuer pin has |
| | |already excluded the |
| | |checkpoint: under a pin|
| | |a checkpoint that does |
| | |not verify is issuer- |
| | |key-mismatch and never |
| | |reaches the totals |
| | |comparison |
+-------------------------------+-----------+-----------------------+
|checkpoint-head-mismatch |audit fails|chainHeadHash is not |
| | |the last link, in |
| | |issuer order, of the |
| | |chain inside the |
| | |window, or the expected|
| | |head could not be |
| | |computed at all because|
| | |the last receipt on the|
| | |chain refused canonical|
| | |encoding; the refusal |
| | |is named and is not a |
| | |signature verdict |
+-------------------------------+-----------+-----------------------+
|equivocation |audit fails|Two distinct hashes for|
| | |one epoch |
+-------------------------------+-----------+-----------------------+
|window-coverage |audit fails|Gap, overlap, or non- |
| | |adjacent / non- |
| | |consecutive windows |
+-------------------------------+-----------+-----------------------+
|unauthenticated-witness |conditional|No verifier-supplied |
| | |witness key; inclusion |
| | |receipts were left out |
| | |of the comparison |
+-------------------------------+-----------+-----------------------+
|witness-entry-unattributable |conditional|The witness holds a |
| | |statement this chain |
| | |does not present, |
| | |carrying no body to say|
| | |whose it is |
+-------------------------------+-----------+-----------------------+
Dogru Expires 21 March 2027 [Page 10]
Internet-Draft Cedulon Checkpoints September 2026
|checkpoint-withheld |audit fails|A verified witness |
| | |receipt binds a |
| | |checkpoint the |
| | |presented chain does |
| | |not contain |
+-------------------------------+-----------+-----------------------+
|checkpoint-not-anchored |guarantee |A witness was supplied |
| |conditional|and holds no verified |
| | |receipt for this |
| | |checkpoint |
+-------------------------------+-----------+-----------------------+
|checkpoint-totals-redacted |guarantee |The checkpoint was |
| |conditional|signed with totals |
| | |null, so the totals |
| | |comparison could not be|
| | |made |
+-------------------------------+-----------+-----------------------+
|witness-inclusion-invalid |audit fails|The tier-2 candidate |
| | |bytes and inclusion |
| | |proof do not reproduce |
| | |a witness-signed tree |
| | |head, or a candidate |
| | |was supplied without a |
| | |proof (MUST-T11-18) |
+-------------------------------+-----------+-----------------------+
|witness-inclusion-not-exercised|conditional|Witness receipts were |
| | |supplied and no tier-2 |
| | |pair was, so log |
| | |membership was not |
| | |proven (MUST-T11-19). |
| | |The code says nothing |
| | |about whether any of |
| | |those receipts |
| | |verified: it is |
| | |reported on |
| | |presentation, and an |
| | |unpinned or |
| | |unverifiable inclusion |
| | |receipt reaches it |
| | |alongside |
| | |unauthenticated-witness|
+-------------------------------+-----------+-----------------------+
Table 1
Dogru Expires 21 March 2027 [Page 11]
Internet-Draft Cedulon Checkpoints September 2026
3. SCITT Anchoring
A Receipt Issuer or relying party MAY construct a SCITT Signed
Statement whose payload is either the Spend Receipt COSE object or a
privacy profile ([CEDULON-CORE] (Privacy Considerations)) and
register it with a Transparency Service [RFC9943]. The service
returns a COSE receipt [RFC9942]. Embedding that receipt yields a
Transparent Statement. Cedulon does not define a new transparency
algorithm.
An epoch checkpoint MUST be registrable on the same terms (MUST-
T11-14), as SHOULD-T11-5 asks. Its Signed Statement carries the
checkpoint COSE_Sign1 object as the payload and application/cedulon-
checkpoint+cbor as the content type, which is among the media types
Section 4 asks to have registered and which, until then, is a
placeholder like the rest. Nothing else about registration differs
from a receipt.
3.1. T11: Checkpoint suppression or rollback
MUST-T11-1 (the checkpoint label set) and MUST-T11-12 (totals
conditionality) are defined in the core document [CEDULON-CORE]. The
remaining T11 identities are defined here.
+==============+==================================================+
| ID | Requirement |
+==============+==================================================+
| MUST-T11-2 | Verifiers MUST reject a checkpoint whose |
| | signature fails, whose totals do not match |
| | settled receipts in the declared window, whose |
| | receiptCount is wrong, or whose chainHeadHash is |
| | not the hash of the last in-window receipt in |
| | issuer order (the prevReceiptHash chain). Where |
| | the signed totals are null, MUST-T11-12 governs |
| | instead: there is no total to disagree with, the |
| | comparison is reported as skipped, and the count |
| | and chain-head checks still apply. |
+--------------+--------------------------------------------------+
| MUST-T11-3 | Two verified checkpoints for the same epoch with |
| | different hashes MUST be reported as |
| | equivocation. The checkpoints compared are |
| | those presented together with those carried by |
| | verified witness receipts; a presented chain |
| | that satisfies MUST-T11-8 cannot raise it on its |
| | own, because its epochs are consecutive. |
+--------------+--------------------------------------------------+
| MUST-T11-4 | A broken checkpoint hash chain MUST fail |
| | verification. |
Dogru Expires 21 March 2027 [Page 12]
Internet-Draft Cedulon Checkpoints September 2026
+--------------+--------------------------------------------------+
| SHOULD-T11-5 | Checkpoints SHOULD be registered with a |
| | Transparency Service when one is configured. |
+--------------+--------------------------------------------------+
| MAY-T11-6 | A test deployment MAY use an in-process append- |
| | only log as the witness. |
+--------------+--------------------------------------------------+
| MUST-T11-7 | Checkpoint windows MUST be half-open [startMs, |
| | endMs). Every chained receipt MUST fall in |
| | exactly one window. |
+--------------+--------------------------------------------------+
| MUST-T11-8 | Presented checkpoint epochs MUST be consecutive |
| | and adjacent windows MUST meet at endMs = |
| | next.startMs. |
+--------------+--------------------------------------------------+
| MUST-T11-9 | Prefix-deletion and suppression claims that go |
| | beyond the presented chain are conditional on an |
| | external transparency witness. A report MUST |
| | NOT present a completeness guarantee as settling |
| | suppression when no witness was consulted. |
+--------------+--------------------------------------------------+
| MUST-T11-10 | Witness receipts are an optional, separate |
| | input. A verifier given none MUST behave as it |
| | did without this input. A receipt MUST have its |
| | signature verified before it counts for |
| | anything. Where a receipt also carries the |
| | statement body, that body MUST NOT be relied on |
| | unless its statement hash equals the one the |
| | receipt binds and it verifies as a checkpoint; a |
| | discarded body does not discard its receipt. |
+--------------+--------------------------------------------------+
| MUST-T11-11 | A verified receipt binding a checkpoint absent |
| | from the presented chain MUST be reported as a |
| | withheld checkpoint, and MUST NOT be reported as |
| | a window coverage failure. A presented |
| | checkpoint with no verified receipt, where a |
| | witness was supplied, MUST be reported and makes |
| | the guarantee conditional. |
+--------------+--------------------------------------------------+
| MUST-T11-13 | A redaction asserted outside the signed payload |
| | MUST NOT be honoured, and structural claims MUST |
| | NOT be redacted. A checkpoint that fails |
| | verification MUST NOT be treated as redacted. |
+--------------+--------------------------------------------------+
| MUST-T11-14 | An epoch checkpoint MUST be registrable as a |
| | Signed Statement carrying the checkpoint COSE |
| | object with content type application/cedulon- |
| | checkpoint+cbor. |
Dogru Expires 21 March 2027 [Page 13]
Internet-Draft Cedulon Checkpoints September 2026
+--------------+--------------------------------------------------+
| MUST-T11-15 | A verifier MUST obtain the transparency service |
| | public key out of band and MUST verify inclusion |
| | receipts against it. Receipts that cannot be |
| | checked that way MUST NOT be used as evidence in |
| | either direction, and the verifier SHOULD report |
| | that they were left out. |
+--------------+--------------------------------------------------+
| MUST-T11-16 | A statement held by a pinned log MUST |
| | additionally verify against the issuer root |
| | before it counts as something that issuer |
| | published, so that another user's epoch in a |
| | shared log is not read as equivocation by this |
| | issuer. |
+--------------+--------------------------------------------------+
| MUST-T11-17 | An inclusion receipt carrying no statement body |
| | MUST NOT be used to report a withheld |
| | checkpoint, because it cannot say whose |
| | statement it binds. It MUST NOT be discarded |
| | silently either: a real withholding must not be |
| | buried by removing the body. |
+--------------+--------------------------------------------------+
| MUST-T11-18 | Where candidate Signed Statement bytes and an |
| | inclusion proof are both supplied, a verifier |
| | MUST verify log membership by the mechanics of |
| | RFC 9942 Section 5.2.1 and MUST accept only when |
| | the leaf hash, leaf index, and reproduced root |
| | exactly match a witness receipt that verifies |
| | under the pinned witness key. Root reproduction |
| | alone is not acceptance. A pair that fails, or |
| | a candidate supplied without a proof, MUST be |
| | reported as a failing finding. |
+--------------+--------------------------------------------------+
| MUST-T11-19 | Where witness receipts are supplied and the |
| | tier-2 pair is not, the report MUST state that |
| | log membership was not exercised rather than |
| | passing the tier silently. |
+--------------+--------------------------------------------------+
Table 2
Issuer self-attestation: A Receipt Issuer that also produces the
only copy of the extract can omit settlements. Completeness holds
only against an extract the verifier obtained from the rail or
from a rail signature.
Key rotation and revocation: kid identifies the verification key.
Dogru Expires 21 March 2027 [Page 14]
Internet-Draft Cedulon Checkpoints September 2026
This -00 does not specify a revocation list. Verifiers MUST pin
the issuer keys they accept and MUST stop accepting a kid after an
authenticated revocation signal.
Timestamp trust: timestampMs is issuer-asserted. Window assignment
uses that field. A lying issuer can slide a receipt between
windows. External timestamping of receipts is out of scope for
this revision; the checkpoint witness covers checkpoints, not
receipt timestamps.
Collusion: If the rail operator and the issuer collude, they can
publish a matching extract and receipt set that hides a real-world
settlement. Cedulon does not detect extract-external agreement.
Reversal, refund, and partial settlement: State machines for
reversal, refund, and partial settlement are out of scope for this
revision.
4. IANA Considerations
This document requests the registration of two media types in the
"Media Types" registry [RFC6838], in the standards tree.
Registration in the standards tree requires IETF approval; the
provisional registration procedure of [RFC6838] Section 5.2.1 is
available to an Internet-Draft in the meantime. The names are the
same names the core document [CEDULON-CORE] uses for these objects.
4.1. application/cedulon-checkpoint+cbor
Type name: application
Subtype name: cedulon-checkpoint+cbor
Encoding considerations: binary. A COSE_Sign1 structure [RFC9052]
in deterministic CBOR [RFC8949], untagged, as profiled in
Section 2.2 and [CEDULON-CORE] (COSE Profile); the same object is
the payload of the Signed Statement Section 3 registers.
Security considerations: See Section 3.1 of this document. A
checkpoint carries the suppression guarantee for its window
(Section 2.4). Its evidentiary weight depends on a pinned issuer
key ([CEDULON-CORE] (The issuer root)) and never on the key it
carries; where no such key is held the signature is still checked
against the carried key, which establishes internal consistency
only.
Interoperability considerations: As for application/cedulon-
Dogru Expires 21 March 2027 [Page 15]
Internet-Draft Cedulon Checkpoints September 2026
receipt+cbor; the labels are those of the checkpoint table in
[CEDULON-CORE] (Claim labels), and totals signed as null is a
redaction, not a malformed claim.
Published specification: This document, Section 2.2.
Applications that use this media type: As for application/cedulon-
receipt+cbor, and transparency witnesses that co-sign or register
checkpoints.
Required parameters, optional parameters, fragment identifier
considerations, additional information, contact, intended usage,
restrictions on usage, author, change controller: As for
application/cedulon-receipt+cbor.
4.2. application/cedulon-inclusion+cbor
Type name: application
Subtype name: cedulon-inclusion+cbor
Encoding considerations: binary. A COSE_Sign1 structure in
deterministic CBOR, untagged, as profiled in [CEDULON-CORE] (COSE
Profile), whose payload is the three-entry map Section 2.4 states:
statement hash, entry index, tree head.
Security considerations: See Section 3.1 of this document. A
witness receipt verified under the key it carries establishes that
some log is internally consistent and nothing about which log; it
carries evidentiary weight only under a witness key held out of
band (Section 2.1, MUST-T11-15). It attests a statement hash, not
membership in an append-only log; membership is tier 2 of
Section 2.4 and needs the candidate statement and an inclusion
proof beside the receipt.
Interoperability considerations: As for application/cedulon-
receipt+cbor, except that the payload is not a CWT claim set: its
three labels are local to the map and are stated, with their
types, in Section 2.4.
Published specification: This document, Section 2.4.
Applications that use this media type: Transparency witnesses that
co-sign the statements they record, and verifiers that hold
witness receipts for a period under audit.
Dogru Expires 21 March 2027 [Page 16]
Internet-Draft Cedulon Checkpoints September 2026
Required parameters, optional parameters, fragment identifier
considerations, additional information, contact, intended usage,
restrictions on usage, author, change controller: As for
application/cedulon-receipt+cbor.
5. References
5.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/rfc/rfc6838>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/rfc/rfc8949>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/rfc/rfc9052>.
[RFC9942] Steele, O., Birkholz, H., Delignat-Lavaud, A., and C.
Fournet, "CBOR Object Signing and Encryption (COSE)
Receipts", RFC 9942, DOI 10.17487/RFC9942, June 2026,
<https://www.rfc-editor.org/rfc/rfc9942>.
[RFC9943] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande,
Y., and S. Lasker, "An Architecture for Trustworthy and
Transparent Digital Supply Chains", RFC 9943,
DOI 10.17487/RFC9943, June 2026,
<https://www.rfc-editor.org/rfc/rfc9943>.
5.2. Informative References
Dogru Expires 21 March 2027 [Page 17]
Internet-Draft Cedulon Checkpoints September 2026
[CEDULON-CORE]
Dogru, E. C., "Spend Receipts and Payment Rail
Reconciliation for AI Agents", 2026, <https://github.com/
dogrucanemek-alt/cedulon/blob/master/spec/draft-dogru-
cedulon-core-00.md>.
Author's Address
Emek Can Dogru
VERAX TEKNOLOJI LIMITED SIRKETI
Email: e.dogru@cedulon.com
Dogru Expires 21 March 2027 [Page 18]