]> Action State Group

steven@actionstate.ai

Security SCITT transparency merkle mountain range receipts audit log Many systems emit individually signed records — receipts, attestations, statements — and store them locally. Each record verifies on its own, but the collection proves nothing: records can be deleted, reordered, or created after the fact without detection. This document specifies the Checkpointed Local Log (CLL): a producer-operated append-only log, built on the Merkle Mountain Range structure whose COSE proof formats are specified in , together with a small signed checkpoint that commits to the log's entire history. Records of any format are appended as they are produced; checkpoints are emitted on a declared cadence and may be registered with one or more independent Transparency Services or witnesses using existing SCITT registration. A CLL upgrades a set of point receipts into a stream with provable order, contemporaneity, and completeness — while defining precisely, and narrowly, what such a log does and does not establish. This document defines the log discipline and the checkpoint structure; it defines no new proof formats, no transparency service behavior, and no payload semantics.

Introduction A signed record proves that its issuer produced those bytes. It does not prove when the record was produced relative to its neighbors, that no record between two others was deleted, or that the set presented to a verifier is the set that existed. In current practice, producers of agent receipts, decision records, build attestations, SBOM and other supply-chain artifact revisions, and similar records sign each record and store the results in ordinary storage — a "log" whose integrity rests entirely on the operator's word. A relying party examining such a collection cannot distinguish an honest archive from a curated one. The problem is payload-neutral: a stream of SBOM revisions and a stream of agent action receipts fail in exactly the same way, and this document treats them identically. Transparency logs in the style of address this by publishing entries to a small number of large, centrally operated logs, where anyone can audit the whole. That model asks two things the local case cannot give: that the entries themselves be published to a log the producer does not control, which is unacceptable when the content is private; and that each record be registered with a central service as it is produced, which a producer emitting thousands of records a day will not sustain in cost or latency. The need is a construction that keeps entries local and private and still lets a relying party check order and completeness. The Checkpointed Local Log occupies the middle position: the log is local and private; only a small checkpoint — a signed commitment to the log's entire history — ever leaves the producer. The local log makes the record set tamper-evident to anyone who trusts the producer; the checkpoint collapses that history, however many entries, into one commitment cheap enough to publish on every emission; and a witness — because it verifies each checkpoint's consistency with the one before — is what removes "trust the producer" from existence and ordering claims. The Merkle Mountain Range (MMR) structure makes this practical: appends are streaming and never restructure earlier entries, and inclusion and consistency proofs are logarithmic. This document deliberately specifies a thing, not a protocol: the log discipline (when entries are appended), the checkpoint structure and its REQUIRED constraints, and the verification claims the pair supports. Proof formats come from ; checkpoint registration, where elected, uses SCITT registration unchanged.

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 when, and only when, they appear in all capitals, as shown here. Entry: a byte string appended to the log. Entries are opaque to this specification. An entry is typically the digest of a signed record produced by the operator or received from another party; the binding between an entry and the record it commits to MAY be expressed using a declared digest context (e.g., ), including contexts that commit to already-signed bytes exactly as transmitted. Log: an append-only sequence of entries organized as a Merkle Mountain Range per 's underlying structure. Checkpoint: a signed statement committing to the log's state at a given size, structured per . Witness: a party other than the log operator that receives checkpoints, verifies their consistency with previously received checkpoints from the same log identity, and retains or countersigns them. A SCITT Transparency Service acting on registered checkpoint statements is one kind of witness. Producer / operator: the party that appends entries and signs checkpoints. This specification assumes they are the same party (). Log identity: the pair (producer identity, log identifier) carried in the checkpoint's CWT_Claims (). All continuity requirements in this document are per log identity.

The Log Discipline

1. Append at production time. An entry SHOULD be appended when the record it commits to is produced or received, not batched for later assembly. The evidentiary difference is the point of this document: an entry appended at time t is committed by every subsequent checkpoint, so contemporaneity becomes checkable; end-of-period assembly permits curation that no later verification can detect.
2. Append-only. Entries MUST NOT be modified or removed. Erasure of the content an entry commits to is a separate act on separate storage and does not touch the log; the entry (a digest) remains.
3. One log, one signing identity. A log's checkpoints are signed under one key at a time. Key rotation is announced by an entry declaring the rotation — produced under the outgoing key and naming the incoming key identifier — appended before the first checkpoint signed under the new key. The log identity () is unchanged by rotation.

Segmentation and archival (non-normative). A conforming implementation MAY store the log as a sequence of segments rather than one unbounded file. This specification imposes no segment format; the only checkpoint-relevant discipline is that any segment boundary a producer defines SHOULD coincide with a checkpoint boundary, never a calendar boundary: closing a segment at the log's state at a checkpoint's declared size means the segment plus that checkpoint is independently verifiable without the rest of the log, using an inclusion or range proof anchored to the checkpoint's committed root. A store's own manifest of which segments exist, and whether each is presently retrievable ("mounted") or has been archived elsewhere, is local bookkeeping, not itself evidence a verifier trusts — only a checkpoint (and what it commits to) carries that property. A verifier presented with a reference to an entry whose segment is not presently retrievable receives a distinct, honest refusal (e.g., "retention expired") rather than being told the entry never existed, since the checkpoint chain already proves it did.

The Checkpoint A checkpoint is a COSE_Sign1 whose payload is a CBOR map with the following claims:

Claim	Type	Description
kind	tstr	MUST be "cll-checkpoint"
log_size	uint	number of entries committed
commitment	bstr	the peak-list accumulator for the MMR over entries 0..log_size-1, canonical-CBOR-encoded exactly as the commitment object of at that size; see
prev_size	uint	log_size of this log's previous checkpoint; 0 for the first
prev_commitment	bstr	the previous checkpoint's commitment; zero-length for the first
issued_at	tstr	issuance time per
cadence	uint	OPTIONAL: declared maximum seconds between checkpoints ()

The protected header carries the algorithm and the key identifier of the log's signing identity, and the CWT_Claims of . Additional claims MAY be present; verifiers MUST ignore claims they do not understand. When a checkpoint is conveyed to a witness, the producer MUST make available, with it or on request, the consistency proof from prev_size/prev_commitment to log_size/commitment; the witness cannot perform the check without it.

Commitment Representation The MMR accumulator over a set of entries can be represented two ways: as the peak-list — an ordered array of one hash per mountain, tallest first, with no further combination — or as a single bagged root formed by folding that array down to one hash (the specific fold, including ordering and any domain separation, is a choice of the folding implementation and is not standardized by any document this one depends on). commitment and prev_commitment MUST carry the peak-list representation, canonical-CBOR-encoded (RFC 8949 §4.2 deterministic encoding: a definite-length array of definite-length byte strings, one per peak) exactly as produced by the commitment object construction of . This is the only representation a verifier can check inclusion and consistency proofs against, and is therefore the only wire-interoperable form this document defines. Implementations MAY additionally maintain a bagged root, and commonly do, for fast internal equality checks between local log states — this is a legitimate implementation optimization, but such a fold is not specified by this document, is not portable across implementations that choose a different fold, and MUST NOT be carried in the commitment or prev_commitment claims. Multiple independent implementations of this document have converged on exactly this split — peak-list on the wire, bagged root (if any) kept internal-only — and this document records that convergence as a wire requirement rather than leaving it to be rediscovered per implementation. Cryptographic agility. This document defines no hash or signature algorithm of its own. The peak-list commitment is a sequence of opaque byte strings whose construction, including the hash algorithm each entry was produced with, is entirely that of ; the checkpoint's signature algorithm is carried in the COSE protected header per . A CLL therefore inherits algorithm agility from both underlying specifications and adds no agility surface of its own.

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 :

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 witness. A missing checkpoint at any witness is thereby a detectable event, not an ambiguity.
2. Continuity. Each checkpoint's log_size MUST be greater than or equal to its prev_size, and the consistency relation of MUST hold between prev_commitment at prev_size and commitment at log_size. This internal relation is checkable offline by any verifier holding the two checkpoints and the proof between them; 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. Therefore a checkpoint-aware witness — one representing itself as conferring continuity — MUST additionally verify that the presented prev_size/prev_commitment equal the log_size/commitment of the last checkpoint it itself accepted for this log identity, and on failure MUST refuse to register or countersign and MUST treat the failure as evidence of log mutation, never as an error to be retried. A witness that only registers the checkpoint without this check confers inclusion under the service's key — and signed time if and only if the resulting Receipt carries a signed time claim — but not continuity ().
3. Named, independent witnesses. A producer representing a log as witnessed to a relying party MUST name the witnesses it relies on for that representation. A witness operated by the producer confers no witnessed status; it is a replica.
4. No claims beyond the last witnessed checkpoint. Entries appended after the most recent witnessed checkpoint are, to a relying party, exactly as strong as an unwitnessed log. Producers MUST NOT represent them otherwise.

Witnessing A checkpoint is conveyed to a witness by any transport. The checkpoint's protected header MUST carry the CWT_Claims required by for Signed Statements: iss identifies the producer, and sub identifies the log (together, the log identity all continuity checks key on). A witness's confirmation takes one of two forms:

1. SCITT registration. The checkpoint COSE_Sign1 is registered as a Signed Statement per , and the Receipt returned by the Transparency Service is the witness's confirmation — third-party evidence of the checkpoint's inclusion under the service's key, and of the time of registration if and only if the Receipt carries a signed time claim. A Transparency Service unaware of this document can accept the checkpoint as an ordinary Signed Statement; one that additionally performs the continuity check before registration is a checkpoint-aware witness, and only its Receipts carry the continuity meaning of .
2. Direct countersignature. A witness that is not a Transparency Service returns a COSE countersignature (Countersignature version 2, ) over the checkpoint COSE_Sign1, conveyed in the checkpoint's unprotected header or alongside it. Such a witness MUST perform the continuity check before countersigning.

Either confirmation attests inclusion under the confirming party's key; if and only if the confirmation carries a signed time claim does it additionally attest the time of that inclusion. The continuity attestation — that this checkpoint extends the last one this witness accepted — is exactly what adds, and a verifier weighing a witnessed checkpoint SHOULD know which kind of witness produced it. Multiple independent witnesses strengthen the log against equivocation (presenting different histories to different parties): an equivocating producer must partition every witness a verifier might consult ().

Stub Countersignatures — Future Work Implementations commonly want a local, non-witness countersigner for test and development use (a "stub"): something that exercises the countersigning code path in without standing up an independent witness. This document does not yet define that mechanism. Known implementations as of this revision mark such stubs with a local, implementation-private JSON field for their own internal test harnesses; none constructs an Countersignature or Countersign0 structure for this purpose, so there is no shipped cll-stub wire format to normalize on yet. A future revision of this document is expected to define a stub countersignature as an countersignature whose protected header carries a dedicated, crit-listed () marker, so that: a verifier that recognizes the marker treats the countersignature as conferring no witnessing, and a verifier that does not recognize it treats it as invalid under ordinary crit processing — in either case the result is unwitnessed, never witnessed, and never presentable as an Receipt. Until that definition ships, implementations MUST NOT represent any local, non-witness marker as satisfying , and a witness MUST NOT emit one.

Verification Given a checkpoint (witnessed or not), a verifier can check, using only the proof formats of :

• Inclusion: a given entry is committed at a given position under commitment.
• Consistency: a later checkpoint's log extends an earlier checkpoint's log without modification.
• Range completeness: the entries between positions i and j under a checkpoint are exactly the presented set — nothing between them was omitted.

Given a witnessed checkpoint, each of these claims additionally holds against a party who does not trust the producer, to the extent the verifier trusts that the witnesses are independent of the producer and would not jointly conceal an inconsistency.

What a CLL Does and Does Not Establish A CLL with witnessed checkpoints establishes: that each committed entry existed no later than the first witnessed checkpoint covering it (contemporaneity); that the committed sequence has not been reordered, had entries removed, or been rewritten (order and integrity); and that a presented range is complete (completeness). These claims come from what the witness sees, which is only checkpoints, not entries. A checkpoint witness receives commitments; it does not receive, index, or retain the entries themselves. It therefore attests the shape of the committed history — existence, order, completeness of the committed sequence — and nothing about any individual entry beyond its membership. Two consequences a reader familiar with per-record transparency logs must not overlook: a checkpoint witness cannot be queried as an independent index or lookup for a particular record, because it never held one; and verifying any individual entry still requires the producer, or another holder, to present that entry and its inclusion proof — the witness confirms the commitment they resolve against, not the entry. A deployment that needs a witness to independently serve or attest individual records registers those records with a Transparency Service directly (); that is a different trade — publication and per-record registration cost in exchange for independent per-record lookup — and is outside this document, which commits only the checkpoint. A CLL establishes nothing about the truth of any entry's content. A perfectly witnessed log of false records is a perfectly witnessed set of false records. Whether a record's content is accurate, whether its signer was authorized, and whether any claimed real-world effect occurred are separate claims requiring separate evidence (counterparty confirmation, external corroboration), outside this document's scope. Producers and tools MUST NOT present witnessed status as evidence of content accuracy. A CLL likewise does not establish that the log is the producer's only log, nor that all records the producer created were appended. It bounds omission within the committed history; it cannot prove a parallel uncommitted history does not exist. Deployments for which that distinction matters bind the log identity to an accountable party by mechanisms outside this document.

Security Considerations Equivocation. A producer maintaining two divergent logs under one identity must present each witness a consistent view. With k independent witnesses and a verifier that checks any subset of them, sustained equivocation requires controlling or partitioning every witness that verifier consults; the cheapness of MMR checkpoint verification (a witness verifies consistency from the prior commitment and a logarithmic proof, holding no entry data) is what makes a meaningful number of independent witnesses economically plausible. Verifiers SHOULD consult more than one witness where the deployment's threat model includes producer-witness collusion. Backdating. An entry can be created with any internal timestamp, but its position in the log bounds its creation time from above by the first witnessed checkpoint covering it. The backdating window is therefore the declared cadence plus witness latency. Producers wanting a smaller window declare a shorter cadence. Key compromise. A stolen signing key permits forged future checkpoints but cannot rewrite history already held by witnesses: a forged checkpoint inconsistent with a witnessed predecessor is detected by constraint 2 of . Witness retention of checkpoints is therefore part of the security function, and witnesses SHOULD retain all checkpoints for a log identity, not merely the latest. Privacy. A checkpoint reveals the log's size and cadence and nothing else; entries are digests; content never leaves the producer. Deployments for which entry count is sensitive MAY pad with reserved entries; this document does not define a padding scheme.

IANA Considerations This document makes no IANA requests. A future revision defining the stub countersignature mechanism of is expected to request registration of a COSE header parameter in the "COSE Header Parameters" registry at that time.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. CBOR Object Signing and Encryption (COSE) defines a set of security services for CBOR. This document defines a countersignature algorithm along with the needed header parameters and CBOR tags for COSE. This document updates RFC 9052. CBOR Object Signing and Encryption (COSE) Receipts prove properties of a Verifiable Data Structure (VDS) to a verifier. VDSs and associated Proof Types enable security properties, such as minimal disclosure, transparency, and non-equivocation. Transparency helps maintain trust over time and has been applied to certificates, end-to-end encrypted messaging systems, and supply chain security. This specification enables concise transparency-oriented systems by building on Concise Binary Object Representation (CBOR) and COSE. The extensibility of the approach is demonstrated by providing CBOR encodings for Merkle inclusion and consistency proofs. This document defines a new verifiable data structure type for COSE Receipts [I-D.ietf-cose-merkle-tree-proofs] specifically for use with ledgers based on post-order traversal binary Merkle trees and which are designed for high throughput, ease of replication and compatibility with commodity cloud storage. Post-order traversal binary Merkle trees, also known as history trees, are more commonly known as Merkle Mountain Ranges. Traceability in supply chains is a growing security concern. While Verifiable Data Structures (VDSs) have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility and interoperability between different transparency services as well as compliance with various auditing procedures and regulatory requirements. Informative References This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. Action State Group, Inc. Tyche Institute Independently written systems that anchor records to a SCITT Transparency Service repeatedly re-derive the same construction: a canonical form of structured content, a content-addressed identifier derived from that form, a receipt placed in the unprotected header of the Signed Statement, and a typed reference mechanism that lets one record cite another by digest across profile boundaries. This document defines that construction as a reusable profile — the Canonical Payload Binding — so that each payload class declares its canonicalization algorithm and exclusion set once, obtains an interoperable derived identifier, and inherits statement-to-receipt binding and typed digest reference semantics without restating the mechanics in every profile. It complements the COSE Hash Envelope mechanism defined in RFC 9995: where that mechanism signals that a Signed Statement's payload is a digest standing in for content held elsewhere, this document defines how that digest is computed from structured content so that independently written implementations converge on the same bytes. An IANA registry governs the canonicalization algorithms; entries are immutable. This document defines no payload content formats and registers no artifact types; the artifact types that a typed reference may cite, and their meaning, are registered in a single shared Artifact Type Registry, governed separately from this document, that payload profiles register into.

Changes since -00

• Clarified : named the bagged-root fold as an explicit, non-wire, implementation-internal alternative to the peak-list commitment, and stated the peak-list encoding as the required wire form. No claim names changed: the commitment/prev_commitment claims already denoted the peak-list form in -00; independent implementations' COSE wire encoders already produce it, cross-validated byte-for-byte against each other. This revision makes explicit what was previously only implicit in the "commitment object" cross-reference.
• Downgraded from a normatively-specified mechanism to a Future Work note: no shipping implementation constructs an countersignature for local stub use as of this revision, so the -00 text described a wire format nothing produces. Removed the corresponding IANA registration request until the mechanism is actually defined.
• No checkpoint claim names were renamed. An earlier plan for this revision considered renaming the CBOR claims to match each implementation's internal, non-wire JSON field names (mmr_size/root/prev_root/ timestamp); that internal shape is real and shared across independent implementations, but is deliberately kept off the wire by those same implementations, which already emit this document's -00 claim names (log_size/commitment/prev_commitment/issued_at) on the wire, cross-validated byte-for-byte between two of them. Renaming would have put this document out of sync with the format actually in use.

Acknowledgments The Merkle Mountain Range structure and its COSE proof formats are the work of the authors of ; this document exists because that structure makes streaming local commitment practical.