The Checkpointed Local Log (CLL)

1.1. Conventions and Definitions

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.¶

The terms tree size, accumulator, node value, consistency proof, Receipt of consistency, add_leaf_hash, leaf_count, peaks and consistent_roots are used as defined in [I-D.bryce-cose-receipts-mmr-profile].¶

Entry: a 32-byte value appended to the log, typically the SHA-256 digest of a signed record produced by the operator or received from another party. Entries are otherwise opaque to this specification. The binding between an entry and the record it commits to MAY be expressed using a declared digest context (e.g., [I-D.mih-sokolov-scitt-payload-binding]), including contexts that commit to already-signed bytes exactly as transmitted.¶

Log: an append-only sequence of entries held as an MMR per Section 3.¶

Log size: the tree size of the log's MMR: its number of nodes, not its number of entries. A log of 21 entries has log size 39.¶

Checkpoint: a Signed Statement committing to the log's state at a given log size, structured per Section 4.¶

Consistency Registration Policy: a Registration Policy (Section 5.1.1 of [RFC9943]), published by a Transparency Service operated by a party other than the log operator, that admits a checkpoint only if it is consistent (Section 4.5) with the last checkpoint that service registered for the same log identity.¶

Producer / operator: the party that appends entries and signs checkpoints. This specification assumes they are the same party (Section 7).¶

Log identity: the pair (iss, sub) carried in the checkpoint's CWT_Claims (Section 4.5). All continuity requirements in this document are per log identity.¶

1.2. Relation to SCITT Terms

This document uses the terms of [RFC9943]. The party that signs a record is an Issuer, and a signed record is a Signed Statement (COSE_Sign1). A checkpoint is a Signed Statement whose Issuer is the producer and whose Artifact is the log. A service that registers Signed Statements and returns Receipts [RFC9942] is a Transparency Service; a Receipt proves inclusion in that service's log, not agreement with the statement. The check a Transparency Service makes before registering is its published Registration Policy. Independence comes from registering the same Signed Statement with more than one Transparency Service. A party that independently recomputes checks over records it is given works in the manner of an Auditor. SCITT defines no "witness" role and this document defines none; earlier revisions of this document used that word for what is now a Transparency Service applying a Consistency Registration Policy. One party signing another operator's log head is a separate layer outside SCITT and outside this document.¶

4.1. Commitment Encoding

commitment and prev_commitment carry the MMR profile accumulator for their size: the node values of the peaks, concatenated in descending height order (tallest first), with no length prefix, separator, or further combination. For MMR_SHA256 each node value is 32 bytes, so the encoding is 32 times the number of peaks long, and the empty log (size 0) has a zero-length commitment.¶

These are exactly the bytes [MMR-PROFILE-MAIN] specifies as the detached payload of a Receipt of consistency for that size. A verifier recovers the accumulator by splitting the value into 32-byte node values; the number of node values is fixed by the size and MUST match it.¶

An implementation MAY additionally fold the accumulator into a single "bagged root" for its own fast comparisons between local log states. No such fold is specified by this document or by the MMR profile, and a bagged root MUST NOT be carried in commitment or prev_commitment.¶

4.2. Consistency Proof

When 0 < prev_size < log_size, the checkpoint MUST carry consistency_proof, whose value is the MMR profile's consistency-proof:¶

consistency-proof = bstr .cbor consistency-proof-content
consistency-proof-content = [
  tree-size-1: uint,            ; = prev_size
  tree-size-2: uint,            ; = log_size
  consistency-paths: [ * consistency-path ],
  right-peaks: [ * hash ]
]

as defined in [I-D.bryce-cose-receipts-mmr-profile]. It is the same proof a Receipt of consistency carries in its unprotected header, here carried inside the signed payload. When prev_size is 0, or when prev_size equals log_size (the log did not grow between checkpoints), consistency_proof MUST be absent.¶

Carrying the proof in the checkpoint makes every checkpoint independently checkable from its predecessor with no further exchange with the producer, and gives a Transparency Service everything its Consistency Registration Policy needs in the Signed Statement it registers.¶

4.3. Checking a Checkpoint

A verifier holding a checkpoint and the public key of the log's signing identity MUST reject the checkpoint unless all of the following hold:¶

1. The COSE_Sign1 signature verifies, and the protected header carries CWT_Claims with text-string iss and sub (Section 4.5).¶

2. kind is "cll-checkpoint", and log_size, prev_size, commitment, prev_commitment and issued_at are present with the types of Table 1.¶

3. log_size and prev_size are complete MMR sizes, and prev_size is not greater than log_size.¶

4. The length of commitment is 32 times the number of peaks of log_size, and the length of prev_commitment is 32 times the number of peaks of prev_size.¶

5. If leaf_count is present, it equals leaf_count(log_size - 1) (0 when log_size is 0).¶

6. If prev_size is 0, consistency_proof is absent.¶

7. If prev_size equals log_size, consistency_proof is absent and commitment equals prev_commitment.¶

8. Otherwise consistency_proof is present and is a consistency-proof; its tree-size-1 equals prev_size and its tree-size-2 equals log_size; and applying the verification steps of the MMR profile for a Receipt of consistency — consistent_roots from prev_size and the accumulator in prev_commitment, followed by the right-peaks — yields an accumulator whose encoding (Section 4.1) equals commitment.¶

Step 8 is the step a Receipt of consistency verifier performs before checking its signature, with prev_commitment as the trusted accumulator. It establishes that the log at log_size extends the log at prev_size without modification. It does not establish that prev_commitment is the commitment of a checkpoint anyone else has seen; that is the role of Registration (Section 4.5).¶

4.4. Required Constraints — Elected Once, Then Binding

Publishing checkpoints is OPTIONAL. Once a producer elects to publish, the following are REQUIREMENTS, because a checkpoint regime with discretionary gaps supports none of the claims in Section 7:¶

1. Declared cadence. The producer MUST declare a maximum interval between checkpoints (and MAY declare a maximum entry lag). The declaration SHOULD be carried in the checkpoint's cadence claim; however conveyed, it MUST be available to every Transparency Service the checkpoints are registered with. A missing checkpoint at any of them is thereby a detectable event, not an ambiguity. A producer with no new entries meets the cadence with a checkpoint whose log_size equals its prev_size.¶

2. Continuity. Each checkpoint MUST pass Section 4.3 with its prev_size and prev_commitment equal to the log_size and commitment of the producer's previous checkpoint for the same log identity. This internal relation is checkable offline by any verifier holding the two checkpoints; it establishes that the presented history was not rewritten between them. It does not, by itself, establish that no divergent history exists: a forking producer can satisfy the internal relation on each fork separately. Detecting that requires state across time, which a single offline verifier does not have, and is what a Consistency Registration Policy adds (Section 4.5).¶

3. Named, independent Transparency Services. A producer representing a log's checkpoints as independently registered MUST name the Transparency Services it relies on and the Registration Policy each publishes. A Transparency Service operated by the producer confers no independence; it is a replica.¶

4. No claims beyond the last registered checkpoint. Entries appended after the most recent registered checkpoint are, to a relying party, exactly as strong as a log with no registered checkpoint. Producers MUST NOT represent them otherwise.¶

4.5. Checkpoint Registration

The checkpoint's protected header MUST carry the CWT_Claims header parameter [RFC9597] with the claims [RFC9943] requires of a Signed Statement: iss (the CWT Issuer claim [RFC8392]) identifies the producer, and sub (the CWT Subject claim) identifies the log. sub MUST be the same value in every checkpoint of a log, and MUST NOT vary per checkpoint: a checkpoint is a new Signed Statement about the same Artifact, which Section 6.3 of [RFC9943] asks an Issuer to register under the same iss and sub. The pair (iss, sub) is the log identity every continuity check keys on. A sub that changes with every checkpoint (for example, one that embeds the log size) gives each checkpoint a new log identity, so a Transparency Service never finds a predecessor to check it against, and continuity is silently never enforced.¶

The checkpoint is registered as a Signed Statement per [RFC9943], by any transport the Transparency Service accepts. A Transparency Service unaware of this document can register it as an ordinary Signed Statement.¶

A Transparency Service applying a Consistency Registration Policy performs the checks of Section 4.3 and, in addition, keeps for each log identity the log_size and commitment of the last checkpoint it itself registered. For a checkpoint whose log identity it holds state for, it MUST verify that prev_size and prev_commitment equal that state, and on failure MUST refuse registration and MUST treat the failure as evidence of log mutation, never as an error to be retried. For a log identity it holds no state for, it MAY register the checkpoint as the start of that log's history at the service; continuity at that service is then established from that checkpoint forward and says nothing about the history before it. This is the MMR profile's "empty tree as trusted state" case, applied per log identity.¶

The [RFC9942] Receipt the Transparency Service returns proves that the checkpoint is included in the Transparency Service's log, and the time of registration if and only if the Receipt carries a signed time claim. A Receipt is an inclusion proof; it is not the service's agreement with the checkpoint. Continuity follows from the published Registration Policy: where that policy is a Consistency Registration Policy, inclusion under it shows the check passed. A Transparency Service that registers a checkpoint without the check returns a Receipt that proves inclusion and nothing about continuity. A verifier SHOULD know which Registration Policy the Transparency Service applied, and relies on continuity only when it does.¶

Scope of the Consistency Registration Policy. [RFC9943] defines a Registration Policy over the non-opaque header and metadata of the COSE Envelope, permits the service to validate the payload of a Signed Statement (Section 6.3 of [RFC9943]), and leaves the scope of checks beyond the mandatory ones to the implementation (Section 5.1.1 of [RFC9943]). A Consistency Registration Policy reads the log identity from the protected header's CWT_Claims and the claims of Section 4 from the payload. This document does not copy those claims into the protected header. Because the consistency proof is carried in the checkpoint, the Signed Statement itself is the material Section 5.1.1.2 of [RFC9943] requires the service to make available for Auditors to reproduce its check.¶

Registering the same checkpoint with more than one Transparency Service (Section 6.3 of [RFC9943]) strengthens the log against equivocation (presenting different histories to different parties): an equivocating producer must present a consistent history to every one of them (Section 9).¶

5.1. What Each Document Defines

5.2. A Checkpoint and a Receipt of Consistency

A Receipt of consistency for an MMR_SHA256 log is a COSE_Sign1 whose detached payload is the accumulator at tree-size-2, whose protected header carries tree-size-2, and whose unprotected header carries one or more consistency proofs. A checkpoint carries the same three things — commitment is the payload bytes, log_size is tree-size-2, consistency_proof is the proof — with three differences:¶

• Signer. A Receipt is signed by the operator of the verifiable data structure in its role as a Transparency Service, over that service's own log. A checkpoint is signed by the producer as an Issuer, over the producer's local log. It is a Signed Statement, not a Receipt in the sense of [RFC9943], and it becomes transparent only by being registered.¶

• Placement. The Receipt detaches its payload and carries the proof in the unprotected header. The checkpoint attaches the accumulator and puts the proof, log_size and the previous state inside the signed payload, so a Transparency Service registering it receives everything its Registration Policy evaluates in one Signed Statement, and the proof is covered by the producer's signature.¶

• Previous state. A Receipt of consistency leaves the trusted accumulator to the verifier. A checkpoint names its predecessor (prev_size, prev_commitment), which is what lets a Transparency Service detect a fork or a skipped checkpoint by comparing it with the state it holds.¶

Because the bytes coincide, a producer that also operates its log as a Receipt-issuing service can issue a Receipt of consistency over the same sizes, and a verifier that has checked one has checked the other's accumulator. Nothing in this document requires that.¶

5.3. What a Checkpoint Establishes

Given one checkpoint, any verifier can check entries against it: an entry is in the log at a position (an MMR profile inclusion proof against the accumulator in commitment), and a presented range of entries is complete. Given two checkpoints of one log, any verifier can check that the later log extends the earlier one without modification (Section 4.3, step 8). All of this holds to the extent the verifier trusts the producer, because the producer signed every checkpoint and chose what to present.¶

Registered under a Consistency Registration Policy at one or more Transparency Services the verifier regards as independent of the producer, the same checkpoints additionally establish, against a producer the verifier does not trust: that each committed entry existed no later than the registration of the first checkpoint covering it; that no registered checkpoint was followed by a rewritten, reordered, or truncated history; and, across services, that the producer did not show divergent histories to them (Section 7).¶

5.4. What a Checkpoint Does Not Establish

A checkpoint does not make any entry transparent. A Transparency Service that registers checkpoints never receives the entries; it cannot be queried for a record, and verifying a particular entry still requires the producer (or another holder) to present the entry and its inclusion proof. A checkpoint says nothing about the truth of an entry's content, about whether the producer has other logs, or about records the producer never appended (Section 7). And a checkpoint is not a Receipt: a relying party that needs a Transparency Service's own signed proof about a specific record needs that record registered.¶

5.5. The Path to Full Registration

A CLL is designed so that its records can later receive full Registration without losing what the local log already proved:¶

1. Checkpoints only (this document). The producer registers checkpoints; records stay local and private. Relying parties get order, completeness, and an upper bound on creation time for every entry, at the cost of one small Signed Statement per cadence interval.¶

2. Selected records registered. When a record needs independent, per-record transparency — it is disclosed to a counterparty, or contested — the producer registers that record itself, as a Signed Statement, with a Transparency Service (Section 6.3 of [RFC9943]). The record gains its own Receipt and becomes a Transparent Statement. Its CLL inclusion proof against an earlier registered checkpoint is retained as evidence that the record existed, in that position, before the later Registration; the later Receipt does not by itself establish that.¶

3. The log operated as a Transparency Service. A producer that wants every record registered as it is produced can operate (or delegate) its log as a Transparency Service whose verifiable data structure is MMR_SHA256. Its Receipts of inclusion and of consistency then come directly from the MMR profile, and checkpoints become unnecessary for that log; the continuity a Consistency Registration Policy gave is then given by Receipts of consistency verified from trusted state. The log's existing nodes need no conversion, since they were built with the profile's algorithms from the start.¶

Each step keeps the leaf values, node values, and accumulators of the step before it, so a relying party's earlier verification remains valid.¶

5.6. Profile Revisions

This document cites [I-D.bryce-cose-receipts-mmr-profile] at its current revision, -03. The editors' copy of the profile [MMR-PROFILE-MAIN] differs from -03 in ways this document depends on: it specifies the detached payload of a Receipt of consistency as the accumulator's node values concatenated in descending height order (the encoding Section 4.1 uses), it adds a protected tree-size-2 header to the Receipt of consistency, and it states consistent_roots with the exact proof shape checks step 8 of Section 4.3 relies on. This document follows the editors' copy and will track the next published revision of the profile. The checkpoint carries its tree size in the signed payload, so it does not depend on the protected tree-size-2 header.¶

11.1. Artifact Type Declaration for Payload Binding

This section declares, for use with [I-D.mih-sokolov-scitt-payload-binding], the digest context of the cll-checkpoint artifact type. It is a declaration by the owning specification, not an IANA registration.¶

Artifact type:

cll-checkpoint¶

Digest context:

the log state a checkpoint commits to.¶

Canonicalization algorithm:

as-transmitted.¶

Byte-boundary selector:

the value of the commitment claim of a checkpoint (Section 4.1 of this document): the accumulator at log_size, which [I-D.bryce-cose-receipts-mmr-profile] names the detached payload of a Receipt of consistency.¶

Hash function and representation:

SHA-256; 64-character lowercase hexadecimal, as the as-transmitted registration fixes.¶

Composite:

no. The commitment embeds no other artifact type's payload bytes; prev_commitment refers to the previous log state by value, not by digest reference.¶

The test vectors [CLL-VECTORS] give this digest for every log size of the example log (commitment_sha256).¶

12.1. Normative References

[I-D.bryce-cose-receipts-mmr-profile]

Bryce, R. and J. Geater, "COSE Receipts for MMRs", Work in Progress, Internet-Draft, draft-bryce-cose-receipts-mmr-profile-03, 19 September 2026, <https://datatracker.ietf.org/doc/html/draft-bryce-cose-receipts-mmr-profile-03>.

[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>.

[RFC3339]

Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/rfc/rfc3339>.

[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>.

[RFC8392]

Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, <https://www.rfc-editor.org/rfc/rfc8392>.

[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>.

[RFC9597]

Looker, T. and M.B. Jones, "CBOR Web Token (CWT) Claims in COSE Headers", RFC 9597, DOI 10.17487/RFC9597, June 2024, <https://www.rfc-editor.org/rfc/rfc9597>.

[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>.

12.2. Informative References

[CLL-VECTORS]

"draft-mih-scitt-checkpointed-local-log-02 test vectors", October 2026, <https://github.com/action-state-group/checkpointed-local-log/tree/main/cll-02-vectors>.

[I-D.mih-sokolov-scitt-payload-binding]

Mih, S. and A. Sokolov, "Canonicalization Declaration for SCITT Signed Statements", Work in Progress, Internet-Draft, draft-mih-sokolov-scitt-payload-binding-05, 12 September 2026, <https://datatracker.ietf.org/doc/html/draft-mih-sokolov-scitt-payload-binding-05>.

[MMR-PROFILE-MAIN]

Bryce, R. and J. Geater, "COSE Receipts for MMRs, editors' copy", October 2026, <https://github.com/robinbryce/draft-bryce-cose-receipts-mmr-profile/blob/f1320c0/draft-bryce-cose-receipts-mmr-profile.md>.

[RFC9162]

Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, December 2021, <https://www.rfc-editor.org/rfc/rfc9162>.

[RFC9864]

Jones, M.B. and O. Steele, "Fully-Specified Algorithms for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE)", RFC 9864, DOI 10.17487/RFC9864, October 2025, <https://www.rfc-editor.org/rfc/rfc9864>.