Verifiable Telemetry Ledgers for Resource-Constrained Environments

1.1. Scope Boundary

This profile covers the ledger evidence path beginning with admission of an already-formed canonical-record byte string:¶

• byte-preserving record validation, admission, and segment assignment;¶
• deterministic hashing, batching, and chaining into authoritative segment artifacts;¶
• binding the segment-artifact digest to external timestamping or attestation evidence;¶
• verifier-facing manifests, disclosure, and export behavior; and¶
• scoped independent verification and reporting.¶

It does not specify source transport or framing, authentication, decryption or other transport security, anti-replay processing, manufacturer identity, onboarding, fleet inventory, PKI policy, network admission, source buffering, identifier or message-type mapping, payload schemas, source-to-record projection, or firmware orchestration. Those functions can be colocated with the ledger producer, but they remain outside the interoperability claim made by this document.¶

1.2. Ledger Producer Trust Boundary

The ledger producer is trusted to validate and admit each accepted byte string, assign it to one segment, preserve its exact octets, maintain durable segment state, and construct the specified artifacts. An upstream system that constructs the record bytes is separately trusted for their source semantics but is outside this profile.¶

This profile makes post-admission inconsistency detectable. It does not prove that upstream admission was correct, reveal a source event that was never admitted, establish ingestion completeness, validate a source-to-record mapping, or show that a committed measurement was physically true.¶

1.3. Document Roadmap

Section 2 defines the common terminology, and Section 3 identifies the system roles. Producer implementers should focus on Sections 4 through 6, Section 9, and Section 10. Verifier implementers should focus on Sections 4 through 7, Section 9, and Appendices A through D. Operators should additionally read Sections 10 through 12 and Section 14. Commitment-profile, versioning, and registry designers should read Sections 8, 13, and 15.¶

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

For verifiable-telemetry-canonical-cbor-v2, 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: any
]

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 CBOR data item permitted by Section 4.2. 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 Concise Binary Object Representation (CBOR) Commitment Encoding

This section does not define a new general-purpose CBOR variant. It records the narrow deterministic CBOR encoding used for commitment bytes by this profile. The identifier verifiable-telemetry-canonical-cbor-v2 names this commitment recipe so verifiers can tell which byte-level rules were used; see Section 13.3 for allocation policy.¶

The authoritative commitment artifacts, namely CBOR canonical-record artifacts and the canonical segment artifact, use a constrained subset of the length-first core deterministic encoding requirements in Section 4.2.3 of [RFC8949]. For commitment bytes in this profile, the following concrete choices apply:¶

• All commitment-path items MUST use definite-length encoding.¶
• Integers MUST use the shortest encoding width permitted by [RFC8949].¶
• Map keys MUST be CBOR text strings.¶
• Map keys MUST be sorted by encoded key length ascending, then by lexicographic order of the encoded key bytes.¶
• Duplicate map keys and invalid UTF-8 text strings MUST be rejected.¶
• Finite floating-point values MUST be encoded using the shortest of float16, float32, or float64 that exactly preserves the value.¶
• NaN, positive infinity, and negative infinity MUST be rejected in commitment paths.¶
• CBOR tags MUST NOT appear in commitment bytes.¶
• Supported values are unsigned integers, negative integers, byte strings, text strings, arrays, maps, booleans, null, and deterministic finite floats.¶

Implementations MUST NOT accept generic CBOR serializers as authoritative commitment encoders. An encoder is acceptable only if it yields the same bytes as these rules.¶

JSON projections of canonical-record artifacts and segment artifacts are optional and non-authoritative. They MUST NOT be used as commitment inputs. When produced, such projections SHOULD follow [RFC8785].¶

Upstream systems MAY use any transport or internal encoding. Only the exact canonical-record byte string admitted at Section 4.1 is an authoritative record commitment input. A different record encoding is not this profile unless it is identified by a distinct commitment_profile_id and verified under its own rules.¶

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 a gateway elapsed-time source that MUST be non-decreasing and MUST progress during normal operation while an interval is open. Its resolution MUST be no greater than the configured interval_ms. The configured interval_ms is 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 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 gateway 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 gateway 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 gateway MUST determine deadline expiry by checked elapsed-time subtraction; it MUST NOT add interval_ms to an absolute counter in a way that can wrap. If elapsed time cannot be represented or compared safely, the gateway MUST enter the recovery procedure below before accepting another record.¶

Policy Changes and Early Closure¶

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

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 no completeness or non-observation claim.¶

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

Recovery and Durable State¶

After restart or failover, the gateway 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 gateway 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 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. 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.¶

A segment artifact is interpreted only under its in-band commitment_profile_id. Because that identifier is inside the authoritative bytes, every proof over the segment-artifact digest binds the commitment semantics. A verifier-facing manifest MUST repeat the same value and verifiers MUST reject a mismatch. Verifiers MUST NOT infer the commitment profile from the file name, 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 verifiable-telemetry-canonical-cbor-v2.¶
• 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 previous authoritative segment-artifact bytes, 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 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.¶

segments/<segment-number>.cbor is authoritative. The corresponding segments/<segment-number>.json file is a projection only. The path label is the 20-digit, zero-padded decimal rendering of the unsigned serial number; it is not a protocol field. A verifier MUST compare the decoded segment_number with the manifest claim rather than trusting the file name.¶

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 predecessor's exact authoritative CBOR bytes.¶
• 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 gateways 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 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 segment chain validation as skipped because the predecessor is unavailable.¶

6.1. Anchoring Contract

The generic anchoring contract is simple: a gateway 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 segment artifact digest locally; proof validation occurs only after digest binding validation succeeds.¶

A timestamp or attestation over the 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 checks exercised unless the timestamped object separately includes those items.¶

A deployment conforming to this profile MUST use at least one timestamping channel for each emitted segment. Conforming producers and verifiers MUST implement the [RFC3161] channel defined below. Implementation support is mandatory, but a deployment MAY use OTS ([OTS]) instead of RFC 3161 for a particular emitted segment. Peer signatures are optional attestations and do not by themselves satisfy the timestamping-channel requirement. OTS and peer signatures are not baseline interoperable timestamp profiles.¶

time ------------------------------------------------------------>

Upstream |--record bytes-->|      |--record bytes-->|              |
Ledger   | admit exact bytes      | admit exact bytes              |
         |----- segment N open for configured elapsed interval ----|
         |          write segments/SEGMENT-N.cbor                  |
         |---------- submit digest to OTS / RFC 3161 ------------->|
Channel  |                pending / delayed proof        | upgrade |
Verifier |                                      verify later from  |
         |<---------------- disclosed bundle --------------------->|

Figure 2 illustrates the current lifecycle. The upstream path can be intermittent, although it lies outside this profile. Proof completion or later publication can lag behind the authoritative segment-artifact write.¶

6.2. RFC 3161 Interoperable Timestamp Channel

Conforming producers and verifiers MUST implement this channel. As specified in Section 6.1, a deployment is not required to use it for every segment.¶

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

A deployment using this channel MUST define the accepted TSA trust anchors and any required TSA policy OIDs or other validation constraints.¶

A verifier evaluating disclosed RFC 3161 evidence MUST recompute the segment-artifact digest and validate the TimeStampResp and time-stamp token under [RFC3161]. Validation MUST include response status, confirmation that TSTInfo.messageImprint uses SHA-256 and contains the recomputed digest, the token signature, and the TSA signer certificate and certification path under the configured trust anchors and policy constraints. Successful validation MUST be reported as tsa_verification.¶

6.3. Optional OTS Channel

When [OTS] is used, the gateway stamps SHA-256(segments/<segment-number>.cbor) and stores an OTS proof plus an OTS sidecar.¶

OpenTimestamps is referenced here as a deployed public timestamping ecosystem rather than an IETF-standardized proof format. Implementations claiming OTS support depend on the interoperable behavior of the public OTS project, its calendar servers, and compatible client tooling. OTS proof-format interoperability is therefore defined operationally by that ecosystem and its reference implementations. A verifier reports this deployment-specific check using an extension identifier beginning with x-, for example x-ots-verification; it MUST NOT report tsa_verification for an OTS proof.¶

6.4. Optional Parallel Attestation

Deployments MAY also produce:¶

• An OTS proof over the same segment-artifact digest.¶
• A deployment-specific peer signature quorum over the same segment-artifact digest.¶

This document does not define an interoperable peer-signature validation profile. Peer-signature validation MUST be reported under an extension identifier beginning with x-, for example x-peer-quorum-verification. A future specification can register interoperable peer-signature semantics.¶

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

If a verifier is configured in strict mode for optional channels, failure of those channels MUST cause overall verification failure.¶

6.5. Verification

Verifiers MUST first decode the authoritative segment artifact and determine the applicable commitment_profile_id from its in-band field. The verifier MUST reject an absent or unsupported value. When a verifier-facing manifest is disclosed, its repeated value MUST exactly match the artifact field.¶

The verifier MUST treat commitment_profile_id as the semantic key for interpreting the authoritative segment artifact. A structurally well-formed segment artifact and a valid timestamp proof are insufficient for semantic verification if the applicable commitment_profile_id is absent or unsupported. A manifest mismatch is a verification failure even when the artifact and timestamp are otherwise valid.¶

Verifiers MUST determine the applicable verification scope from the disclosed artifacts, the claimed disclosure class, and local verifier policy. Reported outcomes MUST NOT claim checks or assurances outside that scope.¶

Producer manifests do not report executed or skipped checks. A verifier produces those lists only in its separate result after validating the disclosed artifacts.¶

Verifiers SHOULD apply checks in the following fail-fast order, subject to the claimed disclosure class:¶

1. Validate that disclosed artifacts are sufficient for the claimed disclosure class, and report bundle_disclosure_validation.¶
2. Validate the authoritative segment artifact and, when disclosed or consumed, the verifier-facing manifest, and report segment_artifact_validation and verification_manifest_validation as applicable.¶
3. For an epoch segment, validate serial zero and the zero predecessor value. For a non-epoch segment whose predecessor is disclosed, validate ledger and site identity, contiguous serials, and prev_segment_sha256. Report segment_chain_validation as executed or, when the predecessor is unavailable, as skipped with reason predecessor_not_disclosed.¶
4. For Class A bundles, validate each disclosed canonical-record CBOR artifact, hash its exact disclosed octets without re-encoding, validate the batch metadata contract, and recompute segment_root. Compare the recomputed result to the authoritative segment_root, and report record_level_recompute and batch_metadata_validation. Do not attempt to reconstruct a record from source telemetry.¶
5. For Class B bundles, validate the authoritative segment artifact and any disclosed batch metadata. If withheld material prevents public recomputation, report record_level_recompute in checks_skipped. Deployment-specific withheld-material checks MAY be reported only through extension names beginning with x-.¶
6. For Class C bundles, report record_level_recompute and batch_metadata_validation in checks_skipped as out of scope, and treat the result as anchor-only evidence.¶
7. Recompute SHA-256(segments/<segment-number>.cbor) and compare it with every applicable disclosed binding value: the manifest's artifacts.segment_cbor.sha256 value, an RFC 3161 messageImprint.hashedMessage, an OTS sidecar artifact_sha256, or deployment-specific peer-attestation binding metadata. A mismatch in any consumed binding is a verification failure. Report segment_digest_binding. If no binding value is disclosed, report the check as skipped with reason missing_binding_metadata; the bundle is then insufficient for any disclosure class defined here.¶
8. Validate an [RFC3161] timestamp response when present or required by verifier policy, and report tsa_verification.¶
9. Validate OTS proofs or peer attestations as configured and report them only through distinct x- extension check identifiers.¶

When batch metadata is within the exercised verification scope, verifiers MUST apply the following checks before accepting a result:¶

• each batch count equals the length of its leaf_hashes;¶
• each batch repeats the containing ledger_id, site_id, and segment_number exactly;¶
• batch numbers are unique, contiguous from zero, and ordered numerically;¶
• batch leaf lists are the consecutive partitions of the sorted segment leaf list under the committed batch_record_limit;¶
• each batch merkle_root equals the Merkle reduction of its leaf_hashes;¶
• the union multiset of batch leaf_hashes equals the leaf digest multiset derived from disclosed canonical records when canonical-record artifacts are available; and¶
• any standalone batch-metadata projection matches the corresponding batch object in the authoritative segment artifact.¶

Verifier implementations SHOULD expose machine-usable failure categories:¶

• malformed or missing artifacts,¶
• missing or unsupported commitment_profile_id,¶
• Merkle mismatch,¶
• batch metadata mismatch,¶
• segment serial, ledger identity, site identity, or predecessor-digest mismatch,¶
• missing or invalid required timestamp proof,¶
• sidecar mismatch or digest mismatch,¶
• insufficient disclosure for the claimed verification level, and¶
• optional-channel failure.¶

Verifier output SHOULD state the claimed disclosure class, the verification scope actually exercised, the per-channel proof status, which checks were executed, which checks were skipped, and whether the resulting claim is public recompute, partial verification, or anchor-only evidence.¶

Standardized Check Identifiers¶

When verifier results report checks_executed or checks_skipped, this profile defines the following interoperable check identifiers:¶

• bundle_disclosure_validation: disclosure-class sufficiency was validated.¶
• verification_manifest_validation: the verifier-facing manifest was validated.¶
• segment_artifact_validation: the authoritative segment artifact was validated structurally and semantically under the claimed profile.¶
• segment_chain_validation: epoch-segment state or adjacent segment serial, identity, and predecessor-artifact digest linkage were validated.¶
• record_level_recompute: record-level recomputation from disclosed canonical-record artifacts was performed.¶
• batch_metadata_validation: authoritative or disclosed batch metadata was validated against the segment artifact and disclosed record material within scope.¶
• segment_digest_binding: the recomputed SHA-256(segments/<segment-number>.cbor) digest was compared with disclosed binding metadata.¶
• tsa_verification: the [RFC3161] timestamp channel was validated.¶

A verifier result that reports one of these standardized checks MUST use the exact identifier listed here. For any standardized check whose applicability conditions are met within the exercised verification scope, the verifier result MUST report that check exactly once in either checks_executed or checks_skipped. The same standardized identifier MUST NOT appear in both lists and MUST NOT appear more than once. Silent omission of an applicable standardized check is non-conformant.¶

Applicability is determined as follows:¶

• bundle_disclosure_validation and segment_artifact_validation apply whenever verification proceeds on a disclosed bundle.¶
• verification_manifest_validation applies when a verifier-facing manifest is disclosed or consumed to obtain verifier-visible metadata.¶
• segment_chain_validation applies to every disclosed segment. For an epoch segment it validates the zero predecessor and serial zero. For a non-epoch segment, it MUST be executed when the predecessor is disclosed and otherwise MUST be reported as skipped.¶
• For Class A bundles, record_level_recompute, batch_metadata_validation, and segment_digest_binding apply. If required artifacts for one of these checks are absent, that check MUST appear in checks_skipped with a reason indicating insufficient disclosure or missing artifacts.¶
• For Class B bundles, batch_metadata_validation and segment_digest_binding apply when the corresponding artifacts are disclosed. If withheld material prevents public recomputation, record_level_recompute MUST appear in checks_skipped.¶
• For Class C bundles, record_level_recompute and batch_metadata_validation MUST appear in checks_skipped as out of scope, while segment_digest_binding applies when the segment artifact and binding metadata are disclosed.¶
• tsa_verification applies when the RFC 3161 channel is disclosed or required by verifier policy. Other channels use x- extension identifiers.¶

Additional deployment-specific checks MAY be reported, but they MUST NOT redefine these identifiers and MUST use a distinct extension name beginning with x-.¶

Verifier output MUST NOT be represented as proving more than the exercised verification scope. In particular, a successful result does not by itself establish dataset completeness, physical truth of measurements, or suitability for autonomous actuation or sanctions.¶

10.1. Record Timestamps and UTC Health

Any ingest_time or device_time value is already part of the canonical-record byte string at the profile boundary. Its assignment, source authentication, accuracy, leap-second handling, and clock-health policy are upstream responsibilities. The ledger producer MUST preserve that value unchanged and MUST NOT use it for segment selection, renumbering, or reopening. Segment closure uses only the elapsed-time rules in Section 10.2.¶

10.2. Segment Sequencing and Closure

Operators MUST persist the active ledger_id, next emitted segment number, current closure-policy snapshot, open-interval state, record and byte counters, and artifact-write state across restart. Admission, artifact publication, and sequence-state advancement MUST use the atomic or recoverable protocol in Section 4.4 so a crash cannot lose an accepted record or reuse a published serial. Redundant gateways MUST use single-writer fencing or atomic shared allocation.¶

Operators SHOULD monitor elapsed-timer health, closure delay, unexpected early-close reasons, serial conflicts, policy changes, and recovery closures. If deadline state cannot be recovered, the gateway MUST follow Section 4.4 rather than consulting UTC to reconstruct elapsed boundaries.¶

10.3. 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,¶
• segment-artifact write success, digest production, and segment-root calculation,¶
• anchoring backlog, calendar reachability, and proof-upgrade lag for OTS,¶
• status of the mandatory-to-implement [RFC3161] channel when selected for deployment use and of peer-signature channels when configured, and¶
• local storage pressure for retained record artifacts, segment artifacts, proof artifacts, and manifests.¶

An operator-visible fault state SHOULD distinguish an invalid commitment 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.¶

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

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. A configuration change that alters the canonical-record byte syntax or another commitment output requires the versioning action specified in Section 8.¶

When OTS is used, ledger producers SHOULD submit to multiple calendars operated by administratively distinct entities and retain disclosed OTS proof artifacts for at least as long as the corresponding segment artifacts remain available for verification.¶

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

OTS proof exists but is incomplete or awaiting upgrade

Report the OTS channel as pending. Place x-ots-verification in checks_skipped with reason pending_proof unless validation was attempted and failed. Overall success is permitted only when local policy does not require completed OTS evidence.¶

[RFC3161] timestamp response is absent

Report the TSA channel as missing when required by policy, or skipped with reason disabled when the channel is not configured. Report tsa_verification exactly once in either executed or skipped checks when applicable.¶

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 segment_chain_validation as successful across an unknown predecessor, serial conflict, or newly created ledger.¶

10.6. Performance and Scaling

Artifact size grows primarily with the number of accepted canonical records and the number of batches in a segment. Class A verification requires access to the disclosed canonical-record artifacts and scales with the number of records that must be decoded, hashed, and reduced into the segment root. Class C verification can be substantially smaller because it validates the segment-artifact digest and disclosed proof channels without public record-level recomputation. OTS submission traffic is one digest submission per emitted segment artifact per selected calendar; using multiple calendars increases availability but also increases submission attempts and proof-status tracking.¶

Shorter segment intervals reduce the normal time to sealing and anchoring but increase artifact count, anchor submissions, storage, verifier work, and cadence metadata leakage. Longer intervals reduce that overhead but increase the amount of unsealed material and the size of each record-level verification. In emit mode, idle deployments also pay one artifact and anchor submission per interval; suppress mode avoids that cost but makes no continuous- coverage claim.¶

10.7. Verifying Correct Operation

Operators SHOULD periodically run an independent verifier against a recently produced bundle using the same disclosure class that consumers are expected to rely on. A healthy run should confirm that disclosed artifacts are present, the commitment_profile_id is supported, the authoritative segment artifact is well formed, the segment-artifact digest matches binding metadata, disclosed adjacency passes segment-chain validation, expected checks appear exactly once in either checks_executed or checks_skipped, and configured proof channels report a status permitted by local policy and reported according to Section 10.5. Operators SHOULD alert when required checks are silently absent, when OTS proofs remain pending beyond local policy, or when canonical-record handoff, elapsed-timer health, serial allocation, writer fencing, or segment- artifact-write faults occur.¶

13.1. Media Types Registry

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

Because this document is intended for publication on the Independent Submission Stream, the standards-tree registrations in this section require IESG approval under [RFC6838].¶

Type name: application¶

Subtype name: verifiable-telemetry-segment+cbor¶

Required parameters: none¶

Optional parameters: none¶

Encoding considerations: binary¶

Security considerations: see Section 11, especially profile and metadata confusion, artifact mutation, proof substitution, disclosure scope, and resource exhaustion.¶

Interoperability considerations: this media type identifies the authoritative segment-artifact family defined by Section 4.2, Section 4.3, Section 4.4, Section 4.5, and Section 4.6. A recipient uses the artifact's in-band commitment_profile_id to select canonical CBOR, hash, and Merkle semantics for a verification claim.¶

Published specification: this document, especially Section 4.2, Section 4.3, Section 4.4, Section 4.5, and Section 4.6.¶

Applications that use this media type: producers, verifiers, disclosure tools, and archival or audit systems that exchange or retain authoritative segment artifacts.¶

Fragment identifier considerations: no fragment identifier syntax is defined by this document for application/verifiable-telemetry-segment+cbor. Fragment identifiers, if present, are processed according to the +cbor structured syntax suffix rules in [RFC8949].¶

Additional information:¶

• Magic number(s): none¶
• File extension(s): none¶
• Macintosh file type code(s): none¶

Person & email address to contact for further information: Bilal El Khatabi <elkhatabibilal@gmail.com>¶

Intended usage: COMMON¶

Restrictions on usage: none¶

Author: Bilal El Khatabi¶

Change controller: IESG¶

Type name: application¶

Subtype name: verifiable-telemetry-manifest+json¶

Required parameters: none¶

Optional parameters: none¶

Encoding considerations: binary¶

Security considerations: see Section 11, especially profile and metadata confusion, artifact mutation, stale or substituted manifests, disclosure scope, and resource exhaustion.¶

Interoperability considerations: this media type identifies the verification manifest defined by Section 5, Section 6.5, and Verification Manifest and Result CDDL. The manifest is a metadata and digest-binding surface; it is not an authoritative commitment artifact. A recipient still needs the referenced authoritative artifact and MUST compare the manifest's commitment_profile_id with the artifact's in-band value to interpret and verify a claim. The JSON representation conforms to [RFC8259].¶

Published specification: this document, especially Section 5, Section 6.5, and Verification Manifest and Result CDDL.¶

Applications that use this media type: producers, verifiers, disclosure tools, publication services, and archival or audit systems that exchange verification manifests.¶

Fragment identifier considerations: no fragment identifier syntax is defined by this document for application/verifiable-telemetry-manifest+json.¶

Additional information:¶

• Magic number(s): none¶
• File extension(s): none¶
• Macintosh file type code(s): none¶

Person & email address to contact for further information: Bilal El Khatabi <elkhatabibilal@gmail.com>¶

Intended usage: COMMON¶

Restrictions on usage: none¶

Author: Bilal El Khatabi¶

Change controller: IESG¶

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. commitment_profile_id Registry

IANA is requested to create the Verifiable Telemetry Ledger Commitment Profiles registry under a new Verifiable Telemetry Ledger Parameters registry group. This registry is tied to the application/verifiable-telemetry-segment+cbor media type registered in Section 13.1 and records values of the commitment_profile_id sub-code carried in that representation. Registry change control belongs to the Independent Stream. The registry records four columns: Identifier, Description, Reference, and Change Controller.¶

A registered identifier is 1 through 63 lower-case ASCII characters. It begins with a letter, ends with a letter or digit, and otherwise contains only lower-case letters, digits, and single hyphens between non-hyphen characters. Comparison is case-sensitive; an identifier containing an upper-case letter is invalid. Identifiers beginning with x- are reserved for Private Use, are not registered, and MUST NOT be used as interoperable public profile identifiers.¶

The registration policy is RFC Required as defined by [RFC8126] and constrained by [RFC8726] for the Independent Submission Stream.¶

A registration request MUST provide all four registry fields and an RFC reference. The referenced RFC MUST define the canonical input bytes, deterministic encoding rules, hash and tree calculation, authoritative artifact schema, verification procedure, profile identifier binding, positive and negative conformance vectors, and relevant security considerations. An identifier that does not satisfy the syntax above is invalid and MUST NOT be registered.¶

An update request requires authorization from the registered change controller and an RFC reference. An update MUST NOT change commitment bytes or verification semantics for an existing identifier; such a change requires a new identifier. A deprecated entry remains recorded with its reference and MUST NOT be reassigned.¶

This registry is created by a document published on the Independent Submission Stream. Any issues that arise with management of the registry will be resolved by IANA in consultation with the Independent Submissions Editor.¶

This document requests no CoAP Content-Format entry.¶