Verifiable Telemetry Ledgers

4.1. Canonical-Record Input Boundary

The protocol input defined by this document is one exact canonical-record byte string. The byte string MUST encode exactly one CBOR data item using the record shape below and the deterministic encoding constraints in Section 4.2. A ledger producer MUST reject a proposed input that does not satisfy those byte-level constraints.¶

Once admitted, the exact supplied octets are authoritative. The ledger producer MUST use those octets, without modification, as the leaf preimage under Section 4.3. It MUST NOT decode and re-encode, normalize, enrich, remove, reorder, or otherwise substitute a different byte string for commitment. Each admission event contributes one record occurrence, including when two admitted occurrences have identical byte strings.¶

Source transport, framing, authentication, decryption, anti-replay processing, duplicate-submission policy, device-identifier mapping, message-type mapping, payload interpretation, and construction of the canonical-record byte string are upstream of this boundary and are not specified or verified here. A physical gateway MAY perform those functions and ledger production in one implementation, but its interoperability claim under this document begins only with the exact byte string passed across this logical boundary.¶

Under the commitment profile defined by this document, each canonical-record byte string encodes the following fixed seven-element CBOR array:¶

canonical-record-v1 = [
  version: 1,
  device_id: bstr .size 8,
  fc: uint,
  ingest_time: uint,
  device_time: uint / nil,
  kind: uint,
  payload: restricted-cbor-item
]

restricted-cbor-item =
  int / bstr / tstr / bool / nil / finite-float /
  [* restricted-cbor-item] /
  { * tstr => restricted-cbor-item }

finite-float = float

The positional labels are conventional names for inspecting disclosed records; they do not move source-to-record mapping into this profile. Their byte-level requirements are:¶

• version is the unsigned integer 1.¶
• device_id is an opaque 8-octet identifier assigned upstream. This document defines no mapping from a transport or deployment alias to this value.¶
• fc is an unsigned upstream-supplied sequence value. This document defines no replay or duplicate-suppression semantics for it.¶
• ingest_time is an unsigned count of whole non-leap seconds since 1970-01-01T00:00:00Z. Its assignment and accuracy are upstream responsibilities, and it MUST NOT select segment membership.¶
• device_time is an unsigned application timestamp or null. Its epoch and unit are upstream semantics, and it MUST NOT select segment membership.¶
• kind is an unsigned application discriminator. This document defines no message-type or payload-family mapping for it.¶
• payload is one recursively restricted CBOR data item of the type above. Its schema and meaning are outside this profile.¶

A different record array shape or different byte-level field type is a different commitment profile and requires a distinct commitment_profile_id. Application schemas MAY separately define the meanings of device_id, fc, device_time, kind, and payload, but successful verification under this document does not validate those external semantics.¶

Class A recomputation starts with the disclosed canonical-record byte strings. It demonstrates that those exact bytes produce the disclosed leaf digests, roots, and authoritative segment artifact. It does not reconstruct the bytes from source telemetry. Conformance vectors for this profile therefore MUST begin with exact canonical-record byte strings; transport messages and upstream projection fixtures, if supplied, are informative and are not inputs to baseline conformance.¶

4.2. Deterministic CBOR Commitment Encoding

Commitment bytes MUST satisfy the general deterministic-encoding requirements of Section 4.2.1 and the length-first core deterministic-encoding requirements of Section 4.2.3 of [RFC8949]. Items MUST use definite-length encoding; integers and finite floating-point values MUST use their shortest exact encodings. Accordingly, shorter encoded map keys sort first; encoded map keys of equal length sort in bytewise lexical order.¶

Map keys MUST be CBOR text strings. Duplicate map keys and invalid UTF-8 text strings MUST be rejected. CBOR tags, NaN, positive infinity, and negative infinity MUST NOT appear. Permitted values are integers, byte strings, text strings, arrays, maps, booleans, null, and finite deterministic floating-point values.¶

JSON projections are optional and non-authoritative and MUST NOT be commitment inputs. Implementations can use [RFC8785] when stable JSON projection octets are useful. Once a canonical-record byte string is admitted, its exact octets MUST be committed without re-encoding.¶

4.3. Deterministic Commitment Tree Calculation

For a given segment S, the current commitment profile computes segment_root from canonical-record bytes using the domain-separated tree shape of Section 2.1.1 of [RFC9162], specialized to SHA-256 and to the multiset ordering below. SHA-256 is defined by [RFC6234].¶

For each exact canonical-record byte string record, compute leaf_hash = SHA-256(0x00 || record). Sort the resulting raw 32-octet leaf hashes in ascending byte order. Lowercase hexadecimal is only their artifact representation; sorting those fixed-width lowercase strings is equivalent to sorting the raw bytes.¶

Let MTH(L) operate on the sorted list of already-computed leaf hashes. MTH({}) = SHA-256("") and MTH({x}) = x. For a list of n > 1 hashes, let k be the largest power of two strictly less than n, and compute MTH(L) = SHA-256(0x01 || MTH(L[0:k]) || MTH(L[k:n])). Implementations MUST NOT duplicate an unpaired final hash. The prefixes 0x00 and 0x01 provide leaf/parent domain separation, and the recursive split gives every leaf count a unique tree shape.¶

For an emitted empty segment, batches MUST be an empty array and segment_root MUST equal MTH({}), the SHA-256 digest of zero bytes: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855. Its closure_policy.empty_mode MUST be emit; an empty artifact under suppress mode is invalid. For a non-empty segment, batches MUST contain at least one non-empty batch. The resulting segment_root is deterministic for the multiset of committed canonical records. Because leaf digests are sorted before reduction, the root does not commit to admission order. Admission order selects segment membership at the boundary but is not itself a verifier-visible total-order claim.¶

Any future change to this calculation that alters commitment bytes MUST use a new commitment_profile_id.¶

4.4. Segment Formation and Closure

Normal Interval Timing and Admission¶

Segment formation uses an elapsed-time source maintained by the ledger producer. That source MUST be non-decreasing and MUST progress during normal operation while an interval is open. Its resolution MUST be no greater than the configured closure_policy.interval_ms value. That field is a positive uint64 number of milliseconds and specifies a fixed elapsed duration. It is not a civil-time duration and MUST NOT be aligned by local midnight, UTC midnight, time zone, daylight-saving transition, or leap second. The first logical interval of an epoch opens when the ledger is activated. Each normal or early closure other than shutdown immediately opens the next logical interval. Logical intervals continue across idle periods in both empty modes; suppress changes artifact emission and serial consumption, not the elapsed-time schedule.¶

The producer MUST serialize the interval-boundary transition with the admission linearization point. For an interval whose elapsed-time deadline is T:¶

• A record whose acceptance linearizes before T belongs to the current logical interval.¶
• At T or later, the producer MUST process the boundary before another acceptance can linearize.¶
• Upstream processing can begin before T, but if canonical-record admission linearizes at or after T, the record belongs to the next logical interval.¶
• Source arrival time, upstream validation or record-construction time, device_time, and ingest_time MUST NOT override this assignment.¶

The producer MUST determine deadline expiry by checked elapsed-time subtraction; it MUST NOT add closure_policy.interval_ms to an absolute counter in a way that can wrap. If elapsed time cannot be represented or compared safely, the producer MUST enter the recovery procedure below before accepting another record.¶

Policy Changes and Early Closure¶

The producer snapshots closure_policy when a logical interval opens. That snapshot MUST remain unchanged through closure. A normal configuration update becomes effective for the next logical interval. An immediate update MUST first close the current logical interval under the old snapshot. It emits an artifact with close_reason equal to reconfigure unless the interval is empty under suppress mode, in which case it emits no artifact and consumes no segment number.¶

Early closure is permitted only for a condition represented by the committed close_reason. A producer MUST NOT place a record whose acceptance linearizes after the interval deadline into the expired interval merely because closure processing was late. Late closure is an operational fault and SHOULD generate an alarm.¶

A manual closure occurs when a deployment-authorized administrative action requests immediate closure for a reason not represented by another close_reason. The producer MUST serialize that action with admission, close the current logical interval under its existing policy snapshot, and immediately open the next logical interval. A shutdown closure occurs when the producer closes the current logical interval as part of an orderly cessation of ledger operation. It MUST NOT open another logical interval until the ledger is reactivated. Artifact emission and serial consumption for an empty manual or shutdown interval follow the committed empty_mode.¶

Limits and Close-Reason Selection¶

closure_policy.record_limit, when non-null, is the maximum number of admitted records in one logical interval. The interval closes immediately after the acceptance that makes the record count equal to record_limit.¶

closure_policy.size_limit_bytes, when non-null, is a close threshold for the sum of the lengths of the exact admitted canonical-record byte strings. After an acceptance has linearized, if the resulting byte total is greater than or equal to size_limit_bytes, the producer MUST close that logical interval before another acceptance can linearize. The triggering record remains assigned to the interval because segment assignment is final at the admission linearization point. Consequently, size_limit_bytes is not a hard pre-admission maximum and an emitted segment can exceed the threshold by the contribution of its final admitted record. If a single record admitted to an empty interval exceeds size_limit_bytes, that record forms a one-record interval, which MUST close before another acceptance can linearize. Threshold comparisons and byte-count updates MUST use checked arithmetic; the producer MUST enter recovery or stop acceptance before acknowledging a record if the new total cannot be represented safely.¶

If multiple close conditions are simultaneously true, the committed close_reason MUST be selected by this precedence, from highest to lowest: recovery, shutdown, reconfigure, size_limit, record_limit, interval, then manual. The selected reason does not change which acceptances already linearized into the interval.¶

Empty Intervals and Timer Continuity¶

While elapsed-timer continuity is maintained, in emit mode every logical interval produces an artifact; an empty interval uses the empty construction in Section 4.3. In suppress mode, an empty logical interval produces no artifact and consumes no segment number. The next emitted artifact uses the next contiguous number. A suppressed interval makes neither a completeness claim nor a claim that no event occurred.¶

Suspend time counts toward closure_policy.interval_ms when the selected elapsed-time source advances across suspend. If it does not, or if its continuity is uncertain, the producer MUST apply the recovery procedure before accepting another record.¶

Recovery and Durable State¶

After restart or failover, the producer MUST recover the active ledger_id, next segment number, policy snapshot, and any open interval state before accepting more telemetry. If elapsed-time or open-interval state is uncertain, the producer MUST NOT infer the boundary from a possibly regressed wall clock. It MUST either stop acceptance or seal recoverable material with close_reason equal to recovery before accepting into a new interval. It MUST NOT synthesize historical empty artifacts and represent them as having been sealed at missed deadlines.¶

The admission linearization point is a durable transaction boundary. Before acknowledging acceptance, the producer MUST make the exact canonical-record octets, their membership in the open interval, the interval record count and byte count, and the corresponding recovery state atomically durable or recoverable. After a crash, an acceptance MUST be recovered exactly once in the same logical interval, or it MUST be treated as never having completed. Segment sealing MUST atomically persist the authoritative segment artifact, its digest, the next serial allocation, and the new open-interval state before admission resumes.¶

Deterministic Batch Partitioning¶

For a non-empty interval, compute the complete sorted leaf-hash list defined in Section 4.3. Partition that list into consecutive batches of at most closure_policy.batch_record_limit hashes. Batch zero contains the first hashes, batch one the next hashes, and so on; only the last batch can contain fewer than the limit. This rule is the sole baseline batch partitioning rule and is independent of storage flushes, worker scheduling, or input-file layout.¶

4.5. Authoritative Segment Artifact Schema

The authoritative segment artifact is a deterministic CBOR-encoded segment record produced under Section 4.2. It is the stable segment-scoped object of commitment verification. It commits to one record multiset, its ledger identity, serial number, closure policy and reason, and predecessor artifact. It is not a transport envelope, publication statement, or complete verification claim.¶

An authoritative segment artifact is interpreted only under its in-band commitment_profile_id. Because that identifier is inside the authoritative segment artifact bytes, every proof over its digest binds the commitment semantics. A producer manifest MUST repeat the same value and verifiers MUST reject a mismatch. Verifiers MUST NOT infer the commitment profile from the filename, media type, segment-record version, or proof sidecar alone.¶

The segment record contains exactly these fields:¶

• version (uint): segment-record schema version, exactly 2.¶
• commitment_profile_id (tstr): exactly the profile UUID defined in Section 2.¶
• ledger_id (tstr): stable ledger identifier consisting of exactly 32 lowercase hexadecimal characters.¶
• site_id (tstr): non-empty site identifier.¶
• segment_number (uint): serial number in the range 0..(2^64-1).¶
• closure_policy (map): immutable policy snapshot for this logical interval, containing exactly version equal to 1; positive uint64 interval_ms and batch_record_limit; record_limit and size_limit_bytes, each a positive uint64 or null; and empty_mode equal to emit or suppress.¶
• close_reason (tstr): exactly one of interval, reconfigure, record_limit, size_limit, shutdown, recovery, or manual.¶
• prev_segment_sha256 (tstr): SHA-256 digest of the exact bytes of the previous authoritative segment artifact, as 64 lowercase hexadecimal characters, or the epoch predecessor value defined in Section 4.6.¶
• batches (array): authoritative batch objects sorted by batch_number; exactly empty for an empty emitted segment.¶
• segment_root (tstr): deterministic segment root as 64 lowercase hexadecimal characters.¶

Each batch object contains exactly these fields:¶

• version (uint): batch-record schema version, exactly 2.¶
• ledger_id (tstr): the containing segment's ledger_id.¶
• site_id (tstr): the containing segment's site_id.¶
• segment_number (uint): the containing segment's segment_number.¶
• batch_number (uint): batch serial in the range 0..(2^64-1), unique within the segment.¶
• merkle_root (tstr): batch Merkle root as 64 lowercase hexadecimal characters.¶
• count (uint): positive number of committed canonical records in the batch.¶
• leaf_hashes (non-empty array of tstr): leaf hashes sorted as lowercase hexadecimal strings.¶

The batch objects embedded in the authoritative segment artifact are authoritative batch metadata. For a non-empty segment, batch objects MUST be sorted by ascending batch_number, and batch numbers MUST be unique and contiguous starting at zero. Their leaf lists MUST be the consecutive partitions of the complete sorted segment leaf list required by Section 4.4.¶

• For each batch, ledger_id, site_id, and segment_number MUST equal the containing segment fields.¶
• For each batch, count MUST equal the length of leaf_hashes and MUST be greater than zero.¶
• For each batch, merkle_root MUST equal the Merkle reduction of that batch's leaf_hashes under Section 4.3.¶
• The multiset union of all batch leaf_hashes MUST equal the segment leaf-digest multiset from which segment_root is computed.¶

The deterministic-CBOR object is the authoritative segment artifact. A JSON projection, filename, and storage path are non-authoritative. A verifier MUST compare the decoded segment_number with the producer manifest claim rather than trusting a path or filename.¶

4.6. Segment Chaining

Segment identity and chaining are defined within one stable ledger_id. They do not depend on UTC dates or elapsed idle time.¶

• The epoch segment MUST have segment_number equal to 0 and prev_segment_sha256 equal to 64 zero characters, representing 32 zero bytes.¶
• Every non-epoch segment MUST have a serial number exactly one greater than its predecessor, MUST retain the same ledger_id and site_id, and MUST set prev_segment_sha256 to SHA-256 over the exact bytes of the predecessor's authoritative segment artifact.¶
• A producer MUST NOT reuse, skip, or wrap segment_number. Before serial exhaustion, it MUST stop the ledger and start a new ledger with a new ledger_id.¶
• A closure-policy change MUST take effect only in a newly opened logical interval. It does not reset segment_number or ledger_id.¶

When a new epoch begins, the producer MUST generate ledger_id from a cryptographically strong random source. If durable sequence state cannot be recovered unambiguously, a producer MUST stop acceptance or begin a new ledger with a fresh identifier; it MUST NOT reset the serial under the old identifier. Redundant producer instances MUST use single-writer fencing or an atomic shared allocator so that they cannot emit different artifacts for the same (ledger_id, segment_number).¶

A verifier given adjacent authoritative segment artifacts MUST validate serial continuity and predecessor-digest linkage. A partial disclosure that omits the predecessor can still support validation of the disclosed artifact and its external proof, but the verifier MUST report chain_status as predecessor_not_disclosed.¶

5.1. Producer Manifest

The artifact's in-band commitment_profile_id is the cryptographically bound profile identifier. The producer manifest repeats the ledger identity, segment number, commitment profile, claimed disclosure class, artifact digests, and claimed channel state. It MUST NOT contain a segment-chain validation conclusion, per-channel verifier status, failure reasons, or an overall verification outcome.¶

Each entry in artifacts.records represents one admitted record occurrence. Duplicate entries are permitted and MUST be counted separately. When two or more occurrences have identical canonical-record bytes, their entries MAY reference the same disclosed artifact; a Class A verifier MUST hash its exact octets once for each listed occurrence. Artifact-reference order does not assert admission order.¶

Producer channel state is limited to present when the corresponding evidence artifact is disclosed and pending when the channel was selected but evidence is not yet available. An unselected channel is omitted. Producer manifests MUST NOT use verifier states such as verified or failed.¶

A pending channel MAY omit its evidence artifact. A present TSA channel MUST reference tsa_tsr. A present OTS channel MUST reference segment_ots and MUST include the sidecar reference and binding required by the applicable deployment-specific OTS profile. A present peer channel MUST reference peer_attest and the applicable binding metadata.¶

The producer manifest is the primary disclosure surface for verifier-visible producer claims. Its schema is defined in Appendix B. Deployment-specific data can be carried only in explicit extension containers and MUST preserve the semantics defined here.¶

5.2. Verifier Result

Verification under Section 6.6 produces a logical verifier result. Only that verifier-authored result states the exercised scope, any segment-chain conclusion, per-channel validation status, verifier-policy identifier when applicable, overall outcome, and failure reasons. The result reports conclusions needed by a relying party; local step-by-step diagnostics and execution traces are implementation-specific. A producer manifest and a verifier result MUST NOT be represented as the same object.¶

A verifier MAY serialize its result as JSON. A serialized result that claims conformance with this document MUST use the schema in Appendix B and the application/json media type. This document does not request a specialized media type for verifier results.¶

5.3. Portable Artifact References and Binding

Every path-bearing object consumed during verification, including a producer manifest artifact reference, a deployment-specific sidecar, or an extension object, MUST satisfy the requirements in this subsection. Each path is a UTF-8 string interpreted relative to the disclosed evidence bundle root, using / as the only separator. A path MUST be non-empty; MUST NOT begin with /, \, or a drive-letter prefix; MUST NOT contain \, a colon, a control character in the ranges U+0000 through U+001F or U+007F, an empty path component, or a component equal to . or ..; and after resolution MUST remain below the bundle root. Verifiers MUST reject a symbolic link, reparse point, or equivalent filesystem indirection, or MUST use a containment-enforcing open operation that prevents such indirection from changing the target between validation and access.¶

For every such consumed path, path validation and file opening MUST be one race-resistant operation; a check-then-open sequence that permits target substitution is nonconformant. These checks are semantic requirements and do not depend on a regular-expression dialect. Every artifact listed in the producer manifest MUST carry a lowercase hexadecimal SHA-256 digest entry.¶

The producer manifest binds claim semantics to the authoritative segment artifact. The producer manifest's ledger_id, site_id, segment_number, and commitment_profile_id MUST match the corresponding fields in the authoritative segment artifact. A verifier obtains the applicable profile identifier from the artifact itself rather than from a path or filename.¶

5.4. Deployment-Specific Sidecars

A deployment-specific OTS profile that uses a sidecar MUST bind at least:¶

• artifact,¶
• artifact_sha256, and¶
• ots_proof.¶

Any path-valued artifact or ots_proof member, and any other path-bearing member consumed from a deployment-specific sidecar, MUST satisfy Section 5.3. Verifiers MUST recompute the authoritative segment artifact digest and compare it with the sidecar before accepting any proof validation result.¶

6.1. Baseline Conformance

For every emitted segment, a baseline producer MUST select and initiate the [RFC3161] channel. Its RFC 3161 evidence MAY remain pending while issuance is incomplete, but a baseline success result requires verified RFC 3161 evidence.¶

OTS and peer channels are additive. A baseline verifier MAY report either channel as skipped without preventing success. If validation of selected optional evidence is attempted and fails, that failure prevents success and produces failure when verifier policy requires the channel; otherwise it produces partial. A selected optional channel whose evidence is pending or missing produces partial unless verifier policy requires failure.¶

6.2. Anchoring Contract

The generic anchoring contract is simple: a producer computes the SHA-256 digest of the authoritative segment artifact and submits that digest to one or more external timestamping channels. Verifiers MUST first recompute the authoritative segment artifact digest locally; proof validation occurs only after digest binding validation succeeds.¶

A timestamp or attestation over the authoritative segment artifact digest binds the complete artifact bytes, including the in-band commitment_profile_id. It does not bind a disclosure class, producer manifest, verifier policy, or verifier result.¶

For each emitted segment, a baseline producer MUST select and initiate the RFC 3161 timestamping channel over the authoritative segment artifact digest. The producer MUST seal and durably write the authoritative authoritative segment artifact without waiting for timestamp proof completion. A deployment MAY also select a deployment-specific timestamp channel, such as OTS ([OTS]), under an explicitly identified deployment profile. Such a channel is additive and is not a baseline interoperable timestamp profile under this document. Peer signatures are optional attestations and do not by themselves satisfy the timestamping-channel requirement.¶

6.3. RFC 3161 Timestamp Channel

Baseline producers MUST select this channel for every emitted segment, and baseline verifiers MUST implement it.¶

When this channel is used, the producer MUST set TimeStampReq.messageImprint.hashAlgorithm to SHA-256 and its hashedMessage to the exact 32-octet result of SHA-256 over the authoritative segment artifact bytes. The producer MUST NOT hash that 32-octet result again. The producer MUST set TimeStampReq.certReq to TRUE.¶

The TimeStampReq, TimeStampResp, and timestamp token MUST conform to [RFC3161], as updated by [RFC5816] and restricted by this section. The token MUST contain exactly one CMS SignerInfo as defined by [RFC5652].¶

A successful TimeStampResp.status.status MUST be granted (0). A verifier MUST reject grantedWithMods (1) under this profile.¶

The SignerInfo signed attributes MUST contain exactly one SigningCertificateV2 attribute with exactly one attribute value, as defined by [RFC5035]. The first ESSCertIDv2.certHash MUST equal SHA-256 over the complete DER encoding of the selected signer certificate. If hashAlgorithm is present, it MUST identify SHA-256; omission denotes the SHA-256 default. If issuerSerial is present, it MUST identify that same certificate. The signed attributes MUST NOT contain a legacy SigningCertificate attribute.¶

Because this profile requires TimeStampReq.certReq=TRUE, SignedData.certificates MUST contain exactly one X.509 certificate that matches both SignerInfo.sid and the first ESSCertIDv2; zero or multiple matching certificates are a verification failure. The set MAY also contain unrelated certificates or certification-path certificates.¶

A deployment using this channel MUST define accepted TSA trust anchors, accepted TSA policy identifiers, certificate-revocation policy, acceptable signature and certificate algorithms, and any constraints applied to the token's generation time. When operators control the TSA, responses SHOULD include necessary intermediates and SHOULD omit an already provisioned trust anchor. A verifier MUST NOT rewrite a received response or reject it merely because it contains additional nonmatching certificates.¶

A verifier evaluating disclosed RFC 3161 evidence MUST recompute the authoritative segment artifact digest and validate the TimeStampResp and token under [RFC3161], as updated by [RFC5816]. Validation MUST include a response status of granted (0) and required token presence; the CMS id-signedData content type and id-ct-TSTInfo encapsulated content type; exact SHA-256 message-imprint equality; the CMS signature and signed attributes; unambiguous signer-certificate binding; the signer certificate's single critical extended-key-usage extension containing only id-kp-timeStamping; certification-path validation under [RFC5280] and configured trust anchors; configured TSA policy and certificate-validation constraints; and nonce equality when the corresponding original request is evaluated and contained a nonce. Any failure is a timestamp-channel verification failure. The corresponding TSA channel status in a verifier result MUST be verified on success and failed on failure.¶

6.4. Optional Deployment-Specific OTS Channel

When [OTS] is used, the producer stamps the SHA-256 digest of the exact authoritative segment artifact bytes and stores an OTS proof plus its binding metadata.¶

OpenTimestamps is referenced here as a deployed public timestamping ecosystem rather than an IETF-standardized proof format. This document does not define an OTS wire format, calendar trust model, accepted attestation set, upgrade procedure, or validation algorithm. A deployment claiming OTS interoperability MUST define those items, identify the profile and verifier policy in use, and specify the exact binding metadata. Baseline VTL implementations are not required to implement OTS.¶

A verifier reports OTS validation under a distinct OTS channel. The channel result MUST identify the collision-resistant deployment- specific validation profile in use, for example com.example.ots-verification; it MUST NOT report an OTS proof as an RFC 3161 TSA channel.¶

6.5. Optional Parallel Attestation

Deployments MAY also produce a deployment-specific peer signature quorum over the same authoritative segment artifact digest.¶

This document does not define an interoperable peer-signature validation profile. A peer channel result MUST identify the collision-resistant deployment-specific validation profile in use, for example com.example.peer-quorum-verification. A future specification can define interoperable peer-signature semantics.¶

When multiple channels are present, verifiers SHOULD validate all available channels independently and report per-channel results.¶

Failure of a peer-attestation channel is fatal only when local verifier policy makes that channel required. Otherwise, an attempted peer-attestation failure prevents success but permits partial.¶

6.6. Verification

7.1. Class A (Public Recompute)

Class A is appropriate when public recomputation from disclosed canonical records and authoritative segment artifacts is required. A Class A bundle MUST include all canonical-record artifacts required to recompute the claimed segment root, the authoritative segment artifact including its batch objects, the producer manifest, and the selected timestamp- channel states required above. For each channel claimed present, the bundle MUST include its required evidence artifact and binding metadata. A peer attestation does not satisfy the timestamp- channel selection requirement. The authoritative segment artifact records the commitment_profile_id.¶

A Class A verifier can perform record-level recomputation, batch-metadata validation, segment-root recomputation, authoritative segment artifact digest validation, producer manifest artifact-digest validation, and enabled anchor or external-evidence validation when the corresponding artifacts are disclosed. A successful public_recompute result asserts that those required validations succeeded. A public-recompute claim is invalid if required record artifacts are missing, root recomputation was not performed, the in-band profile is absent or unsupported, or a required digest validation fails.¶

7.2. Class B (Partner Audit)

Class B is appropriate for controlled disclosure where some record material is withheld while commitment and anchor evidence remain auditable. Class B outputs MUST NOT be represented as publicly recomputable. A Class B bundle MUST include the authoritative segment artifact, the producer manifest, and the selected timestamp-channel states required above. For each channel claimed present, it MUST include the timestamp proof and binding metadata. It MAY include commitments covering withheld material, and a policy artifact describing withheld or partitioned material.¶

Class B validation includes the complete batch metadata embedded in the authoritative segment artifact. The verifier MUST validate that metadata, including recomputation of segment_root from the complete batch leaf list, even when record preimages are withheld. Validation can additionally cover disclosed withheld-material commitments, auditor-supplied material, and timestamp channels present in the bundle. The partial_verification scope states that public record-level recomputation was not performed and that the result is not publicly recomputable. Deployment-specific withheld-material conclusions MAY be carried in the result's extensions member using collision-resistant names.¶

7.3. Class C (Anchor-Only)

Class C provides segment-level commitment and timestamp evidence without record preimages. A Class C disclosure MUST be labeled as such and MUST NOT claim record-level reproducibility. A Class C bundle MUST include the authoritative segment artifact, the producer manifest, and the selected timestamp-channel states required above. For each channel claimed present, it MUST include the timestamp proof artifact plus the metadata needed to bind it to the authoritative segment artifact digest. The in-band commitment_profile_id supplies the profile identity.¶

A verifier exercising anchor_only can validate authoritative segment artifact digest binding, producer manifest digests, chain or anchor existence, and timestamp-channel status when the relevant artifacts are present. It MUST report the anchor_only scope and MUST NOT claim record-level or batch recomputation. For a non-epoch segment whose predecessor artifact is not disclosed, it MUST report chain_status as predecessor_not_disclosed rather than validated.¶

7.4. Producer Manifest and Verifier Result Summary

The producer manifest MUST include:¶

• ledger_id, site_id, and segment_number,¶
• disclosure_class,¶
• commitment_profile_id,¶
• artifact path and digest entries,¶
• claimed per-channel anchor status.¶

A separate verifier result MUST identify the authoritative segment artifact and producer manifest digests, the commitment profile evaluated, the producer-claimed disclosure class, the verification scope exercised, segment-chain status when a chain conclusion can be made, per-channel validation results, verifier-policy identifier when policy affects applicability or a validation outcome, overall outcome, and failure reasons when the outcome is failure. The channels object MUST be present and non-empty, including when the selected timestamp channel is missing, pending, skipped, or failed.¶

10.1. Health and Fault Management

Operators SHOULD monitor at least the following signals:¶

• canonical-record handoff, validation, admission, and durable-persistence failures,¶
• ledger-identity and segment-sequence persistence, writer fencing, and serial-conflict events,¶
• elapsed-timer health, closure delay, closure reason, and closure-policy revision,¶
• invalid canonical-record encoding and oversize-input rejection rates,¶
• authoritative segment artifact write success, digest production, and segment-root calculation,¶
• anchoring backlog, service reachability, and proof-upgrade lag for deployment-specific timestamp channels,¶
• status of the [RFC3161] channel for every emitted segment and of additive OTS or peer-signature channels when selected, and¶
• local storage pressure for retained record artifacts, authoritative segment artifacts, proof artifacts, and producer manifests.¶

An operator-visible fault state SHOULD distinguish an invalid authoritative segment artifact from a delayed or failed external anchoring channel. A delayed OTS proof, for example, is not by itself evidence that the authoritative segment artifact is malformed.¶

Management integrations SHOULD expose these events in a structured, machine-readable form with a stable event code, event time, severity, state transition, and, when known, the affected site, ledger, and segment number. They SHOULD include correlation data sufficient to reconstruct admission, sealing, anchoring, and verification activity during troubleshooting or digital-forensics review. Human-readable text can supplement, but does not replace, those stable fields.¶

10.2. Configuration Management

Deployments SHOULD document the maximum canonical-record byte length, admission backpressure and durable-write behavior, closure_policy, record and size limits, permitted early-close triggers, artifact and proof retention periods, OTS calendars, optional TSA identities, anchoring policy, verifier strictness for optional channels, and any peer-signature quorum threshold and identity set. These settings are distinct and MUST NOT be silently substituted for one another.¶

An implementation SHOULD expose the effective value of each operationally significant setting and whether that value is an implementation default or an operator override. Deployment documentation SHOULD explain the rationale for defaults and identify defaults expected to change as capacity, algorithms, or external services evolve.¶

Transport, decryption, anti-replay, source buffering, source identity, and source-to-record mapping configuration are upstream of this profile. When one implementation contains both upstream and ledger functions, operator documentation SHOULD still identify the byte-level handoff and distinguish upstream failures from ledger admission or commitment failures.¶

When a deployment-specific OTS profile is used, its calendar selection, redundancy, trust assumptions, finality criteria, and retention policy MUST be documented. Producers SHOULD retain disclosed proof artifacts for at least as long as the corresponding authoritative segment artifacts remain available for verification.¶

Coordinated configuration changes SHOULD be validated for compatibility before activation, applied atomically where the deployment permits, and accompanied by a documented rollback plan. A rollback MUST follow the interval-transition rules in Section 4.4 and MUST NOT mutate sealed artifacts, reuse a segment number, or conceal a chain discontinuity.¶

10.3. Performance and Capacity Management

Producers SHOULD expose cumulative counters, high-water marks, and time-in-state measurements for admission and rejection, durable-write and sealing latency, anchoring backlog, proof-completion latency, retained-artifact storage, and verification duration. Counter definitions SHOULD state what is included, their reset behavior, and how wrap or discontinuity is reported. Reporting time spent in a delayed or failed state is generally more useful than a current-state snapshot alone.¶

Monitoring interfaces SHOULD support bounded, change-driven collection where practical and MUST NOT permit polling or automated queries to silently bypass admission, durability, or closure rules. Deployments SHOULD test behavior at record, storage, anchoring, and verifier capacity limits and document the resulting backpressure, rejection, and recovery behavior.¶

10.4. Fault-to-Verifier-Result Mapping

Operational faults do not all have the same verifier meaning. Verifier output MUST distinguish at least the following cases when the condition is visible from disclosed artifacts or local verifier policy:¶

Selected OTS evidence is incomplete, not yet available, or awaiting upgrade

Report the OTS channel as pending, identify its deployment-specific validation_profile, and use pending_proof as the channel reason unless validation was attempted and failed. The outcome is partial when policy permits pending OTS evidence and failure when policy requires completion.¶

[RFC3161] timestamp response is absent

If the producer manifest reports tsa as pending, report the TSA channel as pending and use pending_proof unless a more specific human-readable diagnostic is needed. The outcome is partial unless verifier policy requires failure. Otherwise report the selected TSA channel as missing; a channel claimed present without tsa_tsr is a verification failure. A baseline result cannot treat the TSA channel as unselected or inapplicable.¶

Canonical-record handoff or admission durability is reported as uncertain

Report the operational continuity condition and do not claim input completeness. Verification of a disclosed sealed segment can still succeed when its artifacts are internally consistent, but that success does not establish which upstream records should have been admitted.¶

Segment sequence or elapsed-time state is lost

Report a continuity break and any recovery closure. Do not report chain_status as validated across an unknown predecessor or serial conflict; a newly created ledger reports epoch only after the epoch-segment requirements succeed.¶

10.5. Verifying Correct Operation

Operators SHOULD periodically run an independent verifier against a recent bundle using the disclosure class expected by consumers. Operators SHOULD alert on verification failures, proofs pending beyond policy, or admission, timer, serial, fencing, and artifact-write faults.¶

Deployments that must preserve verifiability beyond the useful life of a timestamp certificate or current algorithms can define a separate archival-evidence profile using the timestamp-renewal or hash-tree-renewal mechanisms described in [RFC4998]. Such renewal evidence is outside the baseline VTL bundle.¶

11.1. Bundle Paths and Object Authentication

The authoritative segment artifact, producer manifest, and verifier result formats contain no executable content and define no intrinsic compression, but they provide no confidentiality. A producer manifest directs a verifier to open bundle-relative paths, creating path-traversal, symbolic-link or reparse-point substitution, and check-then-open race risks; verifiers MUST apply the containment and race-resistant access rules in Section 5. A timestamp over the authoritative segment artifact does not authenticate the producer manifest or verifier result. The baseline does not otherwise authenticate either object. When their provenance matters, those objects require separate authentication or the relying party must rerun verification from authenticated inputs.¶

11.2. Ledger Producer Compromise and Pre-Commit Omission

An attacker can compromise the ledger producer or its canonical-record handoff and then fabricate byte strings, suppress proposed inputs before commitment, substitute different bytes, or assign a record to the wrong segment. This profile does not by itself detect a malicious producer; it makes outputs tamper-evident only after commitment, as described in Section 1. Operational guidance for admission persistence, elapsed time, health, and verification procedures is consolidated in Section 10.¶

11.3. Segment Sequence Rollback, Fork, and Truncation

An attacker or failed multi-writer deployment can reuse or roll back a segment number, emit conflicting artifacts for one ledger and serial, substitute a predecessor from another ledger, or disclose only a chain prefix or suffix. Fresh ledger identity, single-writer fencing, contiguous serials, and full predecessor-artifact digest validation detect conflicts when the relevant artifacts are disclosed. They do not prove global completeness to an isolated verifier: a producer can still withhold undisclosed segments or a chain suffix. Verifier output MUST therefore distinguish validated adjacency from a completeness claim.¶

Ledger-identifier generation is security sensitive. The random-source requirement in Section 4.6 reduces accidental identifier collision but does not replace durable state or writer fencing. Operators SHOULD audit random-source initialization and failures, record each new-epoch allocation, and alert on any observed reuse of a ledger_id or conflicting use of a (ledger_id, segment_number) pair.¶

11.4. Upstream Admission and Semantic Substitution

An attacker can exploit an upstream transport, replay mechanism, credential system, decryption path, identifier mapping, or payload parser so that incorrect, duplicated, or misattributed record bytes are presented at the profile boundary. Those controls are outside this document. This profile neither prevents nor detects such an attack once the resulting byte string has been admitted. A separate upstream specification is needed for claims about source authentication, anti-replay, confidentiality, or source-to-record semantics, and a successful ledger verification MUST NOT be reported as validation of those claims.¶

11.5. Canonicalization, Profile, and Metadata Confusion

An attacker can exploit differences in CBOR validation, re-encoding, record occurrence handling, hash composition, or non-authoritative metadata handling while implementations still claim the same commitment_profile_id. An attacker can also present a producer manifest or OTS sidecar that does not match the authoritative segment artifact in the hope that a verifier will treat convenience metadata as authoritative. The mitigation is that this profile fixes the canonical-record byte syntax, deterministic encoding, and hash rules; requires producers and verifiers to hash the exact authoritative record bytes without re-encoding; treats the authoritative segment artifact as the cryptographic source of truth; requires verifiers to recompute commitment material from authoritative segment artifacts; requires the applicable commitment_profile_id to be disclosed and bound to the same authoritative segment artifact digest, and requires non-authoritative metadata and sidecars to match the authoritative segment artifact. Any future semantic or hash-composition change MUST use a new UUID as its commitment_profile_id.¶

11.6. Artifact Mutation and Proof Substitution

An attacker can modify a committed authoritative segment artifact after disclosure, or can present a valid proof over the wrong artifact digest. The mitigation is that verifiers recompute the authoritative segment artifact digest independently and compare it with the disclosed binding metadata before accepting any proof result. Mutation or substitution therefore changes the digest or its binding and causes verification to fail.¶

11.7. Timestamp Meaning and Attribution

Successful RFC 3161 validation proves that the bytes bound by the validated message imprint existed no later than the TSA-asserted time, under the configured TSA trust and validation policy. It does not prove the ledger producer's identity, the source of the telemetry, or attribution of those bytes to a particular producer, device, site, or physical event.¶

11.8. Calendar Withholding and Optional-Channel Downgrade

An attacker can operate or compromise a timestamping or attestation service so that proof issuance is delayed, withheld, or selectively unavailable, can present pending or placeholder proofs as if they were final attestations, or can exploit verifier policy that silently ignores a missing required channel. The channel-status vocabulary is defined in Section 6.4.2, and operational reporting for missing or pending channels is described in Section 10.4.¶

11.9. UTC Timestamp Manipulation

An attacker can alter an upstream UTC source so that canonical records carry misleading ingest_time or device_time values. Timestamp assignment and source authentication are outside this profile, as described in Section 4.1. Verification can detect byte or artifact inconsistencies, but it cannot reconstruct true real-world time from a false admitted value. UTC changes MUST NOT affect segment membership or reopen sealed segments.¶

11.10. Segment Policy and Elapsed-Time Manipulation

An attacker can lengthen the closure interval, regress or freeze the elapsed-time source, alter an active policy, misstate a close reason, or race boundary processing in order to delay anchoring or assign a record to a different segment. Committing the policy snapshot and close reason makes the producer's claim tamper-evident after sealing, while the serialized boundary algorithm and operational monitoring reduce accidental races. These controls do not independently prove that the producer honestly observed real elapsed time. Likewise, an OTS proof validated under an identified deployment profile establishes only the time claim defined by that profile; it does not prove when the segment opened or that every configured deadline was honored.¶

11.11. Resource Exhaustion

An attacker can flood a ledger producer with malformed, oversized, or excessive-rate canonical-record inputs in order to exhaust admission capacity, artifact storage, or verifier computation. Producers need deployment-appropriate input-size limits, rate controls, and backpressure at the byte-level handoff; relevant operational signals and sizing considerations are described in Section 10.1. This profile does not define a complete denial-of-service defense.¶

11.12. Verification Scope, Completeness, and Disclosure

An attacker can rely on a successful verifier result being misread as proof of dataset completeness, physical truth of measurements, or authorization for autonomous actuation. An attacker can also obtain sensitive information if disclosed bundles expose more record material than intended for the chosen disclosure class. This profile mitigates those risks only partially: verifier output is required to state the exercised verification scope, a successful result establishes internal consistency and proof binding for the disclosed bundle rather than completeness of all observed or emitted telemetry, and disclosure classes constrain what is expected to be published. Deployments that need stronger completeness, safety, or confidentiality guarantees must add external operational controls, independent observation, and access-control and retention policies that match the sensitivity of the disclosed artifacts.¶

11.13. Withheld-Record Guessing and Confidentiality

Leaf hashes are unsalted. If withheld telemetry has low entropy or its possible record inputs are enumerable, an observer can hash guesses offline and compare them with disclosed leaf hashes. Class B and Class C therefore provide limited confidentiality for enumerable record inputs. A high-entropy, application-layer nonce included in each record can make guessing impractical, but nonce generation and protection are outside this profile and do not constitute confidentiality supplied by VTL.¶

Even when payloads are withheld, producer manifests, authoritative segment artifacts, proof sidecars, and operational summaries can disclose source-activity metadata such as record counts, outage windows, and anchoring delay. Segment serials, interval values, close reasons, and the difference between emitted and suppressed empty intervals can add cadence and activity information. Deployments SHOULD account for that metadata exposure in disclosure and retention policy.¶

13.1. Vendor-Tree Media Type Registration Templates

IANA is requested to register the following media types in the vendor tree of the "Media Types" registry in accordance with [RFC6838]:¶

These requests allocate values from an existing registry under the Expert Review procedure defined by [RFC6838]. They do not require IETF Review or Standards Action and are available to an Independent Stream document under [RFC8726].¶

13.2. No CBOR Tag Allocation

This document requests no new CBOR tag allocation. Commitment bytes defined by Section 4.2 forbid CBOR tags, and the authoritative segment artifact defined by Section 4.5 does not require additional tag semantics for exchange.¶

13.3. No Commitment Profile Registry

This document requests no IANA registry for commitment_profile_id. The two vendor-tree media-type registrations in Section 13.1 are independent registration requests under [RFC6838]. Neither registration creates a namespace or subregistry for commitment-profile identifiers, and this document requests no new IANA registry. This document instead assigns the fixed UUIDv4 defined in Section 2 as its sole profile identifier. UUID generation under [RFC9562] does not require a central allocation registry. Section 8 specifies the identifier's binding and collision behavior. Any future registry requires a separate specification with an appropriate publication stream and registration policy.¶

13.4. No CoAP Content-Format Allocation

This document requests no CoAP Content-Format allocation for either media type registered by Section 13.1.¶