Verifiable Telemetry Ledgers

1.1. Relationship to Existing Work

VTL reuses the Merkle Tree Hash construction from [RFC9162] to commit a producer-local segment, but it does not define a Certificate Transparency log or protocol. In particular, VTL defines no transparency service, public append-only log, statement-registration protocol, receipt, inclusion proof, consistency proof, gossip protocol, or log-auditing API.¶

Unlike Certificate Transparency, VTL commits to a multiset rather than an append-ordered sequence: it sorts leaf hashes before tree reduction. The resulting root is independent of admission order and cannot support append-order, prefix, or consistency claims between partial snapshots. Chaining orders sealed segment artifacts, not records within a segment.¶

The SCITT architecture in [RFC9943] defines signed statements, registration with transparency services, verifiable data structures, and receipts. Those services and claims are outside the VTL baseline. A separate specification can publish a VTL artifact or bundle through SCITT, but doing so does not replace or alter the VTL commitment and verification rules.¶

[RFC9052] defines COSE signing and encryption structures. VTL does not use a COSE object as its authoritative segment artifact and does not require a COSE producer signature. A deployment can wrap or publish VTL artifacts using COSE under a separate profile without changing the bytes committed by VTL.¶

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

A baseline producer MUST accept every conforming canonical-record byte string whose total encoded length is no greater than 4096 octets. A producer MAY accept larger conforming records under its documented resource policy. A configured maximum below 4096 octets does not satisfy baseline producer conformance. The 4096-octet value is a shared minimum acceptance capability that permits bounded-resource implementations; it is not derived from a network MTU and is not a protocol maximum or a default deployment limit.¶

A larger byte string remains in this commitment profile when it otherwise conforms. An implementation MAY receive or validate such a byte string incrementally, but admission still applies to one complete byte string encoding exactly one canonical record. An upstream system MAY instead produce multiple independently conforming canonical records, but each is a separate admitted occurrence. This profile does not treat such records as transparent chunks of one canonical record or define their reassembly semantics.¶

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 = [
  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 ; Finite only; deterministic rules follow.

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

Canonical-record identity is exact-octet identity, not numeric or application-level equality. Within payload, the integer 1 and the floating-point value 1.0 are distinct values and have distinct deterministic encodings. Positive floating-point zero and negative floating-point zero are also distinct: both are finite and permitted, and their shortest exact CBOR encodings are respectively f90000 and f98000. A producer or verifier MUST NOT normalize negative zero to positive zero or convert between an integer and a numerically equal floating-point value.¶

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 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 core deterministic-encoding requirements of Section 4.2.1 of [RFC8949]. Items MUST use definite-length encoding; integers and finite floating-point values MUST use their shortest exact encodings. Map keys MUST be ordered in the bytewise lexicographic order of their deterministic encodings.¶

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. Negative floating-point zero is finite and is permitted. Exact type, sign, and encoded-octet distinctions described in Section 4.1 are preserved by admission and verification.¶

Because this profile permits only text-string map keys and requires their preferred deterministic encodings, bytewise ordering of their encoded heads first orders them by UTF-8 byte length and then orders equal-length keys by their encoded bytes. The resulting order is also the length-first order described in Section 4.2.3 of [RFC8949]. This coincidence does not replace any other core deterministic-encoding requirement in Section 4.2.1.¶

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

Unless a rule explicitly says otherwise, every digest in this document is computed over the exact received or disclosed octets; no implementation may re-encode, normalize, or reserialize input before hashing.¶

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 [FIPS180-4]. [RFC6234] provides informative implementation descriptions and test material for the SHA family.¶

Every SHA-256 invocation in this profile MUST produce the complete 32-octet SHA-256 digest; a truncated digest or a different SHA-2 function is nonconformant. For commitment-tree hashing, an implementation MUST use exactly the 0x00 leaf prefix and 0x01 internal-node prefix specified below and MUST NOT add, omit, or substitute another tree-domain prefix.¶

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. The authoritative artifact represents hash values as CBOR byte strings; hexadecimal renderings in this document are for human-readable vectors only.¶

Let VTLRoot(L) operate on the sorted list of already-computed leaf hashes. VTLRoot([]) = SHA-256("") and VTLRoot([x]) = x. For a list of n > 1 hashes, let k be the largest power of two strictly less than n, and compute VTLRoot(L) = SHA-256(0x01 || VTLRoot(L[0:k]) || VTLRoot(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, record_count MUST be zero, batch_roots MUST be an empty array, and segment_root MUST equal VTLRoot([]), the SHA-256 digest of zero bytes: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855. Its closure_policy.empty_mode MUST be emit, except that a mandatory empty shutdown or recovery lifecycle artifact retains the committed suppress value as specified in Section 4.4. Any other empty artifact under suppress mode is invalid. For a non-empty segment, record_count MUST be positive and batch_roots MUST contain at least one root. 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. Producer conformance requires sorting the complete segment leaf multiset before batching. Verification of that global sort rule is complete only under the public_recompute scope defined in Section 6.5.1; weaker scopes provide only the ordering assurances explicitly defined for those scopes.¶

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

4.4. Segment Formation and Closure

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 coarser than the smaller of 1000 milliseconds and the configured closure_policy.interval_ms value. Resolution here means the greatest quantization step exposed to the boundary logic. It constrains comparison granularity, not the precision of the underlying clock. A producer MAY sample the elapsed-time source or evaluate the boundary more frequently and MAY use a finer-resolution source. The policy 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. Activation is the deployment-defined start action by which the producer makes the ledger_id and initial segment state durable before admitting a record. Reactivation resumes that durable state after a shutdown closure. 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 so that each admitted input has exactly one segment assignment. 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.¶

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 an operator-initiated action, external to the producer's automatic timer and limit evaluation, requests immediate closure. A producer MUST NOT use manual for a closure triggered by its own timer or limit evaluation. 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. Artifact emission and serial consumption for an empty manual interval follow the committed empty_mode. 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. A shutdown closure MUST emit an artifact and consume a segment number even when the interval is empty and its committed empty_mode is suppress.¶

The interval reason applies when the snapshotted interval_ms elapsed-time deadline expires and no higher-precedence close condition applies.¶

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 the following precedence, numbered from highest to lowest:¶

1. recovery¶
2. shutdown¶
3. reconfigure¶
4. manual¶
5. size_limit¶
6. record_limit¶
7. interval¶

The selected reason does not change which acceptances already linearized into the interval.¶

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, except that shutdown and recovery closures always emit the empty construction and consume a 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.¶

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. A recovery closure MUST emit an artifact and consume a segment number even when the recoverable interval is empty and its committed empty_mode is suppress. 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.¶

These durability requirements specify the observable crash-recovery outcome, not a particular operating-system call. An implementation can use fsync(), a transactional store, replicated durable state, or another mechanism only if the required state is durable or recoverable before acceptance is acknowledged. Calling fsync() alone is not sufficient when the surrounding storage and transaction design does not provide that outcome.¶

In this profile, a batch is not a chronological admission chunk. It is a consecutive slice of the complete globally sorted leaf-hash list, formed only after segment membership is fixed.¶

For a non-empty interval, compute the complete sorted leaf-hash list defined in Section 4.3. Partition that list into consecutive batches of B = closure_policy.batch_record_limit hashes. B MUST be a positive power of two no greater than 2^63. Batch zero contains the first B hashes, batch one the next B hashes, and so on; only the last batch can contain fewer than B hashes. Compute each batch_roots[i] as VTLRoot over that batch's already-computed leaf hashes. This rule is the sole baseline batch partitioning rule and is independent of storage flushes, worker scheduling, or input-file layout.¶

Requiring a power of two makes every full batch align with a recursive VTLRoot split. An aligned batch root can therefore substitute directly for its subtree when composing segment_root, without an auxiliary sibling path or a storage-dependent tree shape.¶

Let N be the segment record_count. For N > 0, the number of batch roots MUST be 1 + ((N - 1) / B) using integer division. To compose a range root from those aligned batch roots, return the sole supplied root when the range contains at most B leaves. Otherwise, let k be the largest power of two strictly less than the range's leaf count. Because B is a power of two and the range spans multiple batches, k is a batch boundary. Recursively compose the roots before and after that boundary, then return SHA-256(0x01 || left || right). The result MUST equal segment_root. This is subtree substitution under the VTLRoot recursion in Sections 2.1.1 and 2.1.2 of [RFC9162]; it does not define a Certificate Transparency log or a CT wire object.¶

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 artifact bytes, a valid timestamp token over its digest binds the commitment semantics. A producer manifest MUST repeat the same value and verifiers MUST report a mismatch as commitment_mismatch. Profile dispatch follows the canonical rules in Section 8.¶

The segment record contains exactly these fields:¶

• version (uint): segment-record schema version, exactly 1.¶
• commitment_profile_id (tstr): a lowercase RFC 9562 UUID string. A baseline producer MUST emit exactly the profile UUID defined in Section 2.¶
• ledger_id (tstr): stable ledger identifier consisting of exactly 32 lowercase hexadecimal characters.¶
• 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; power-of-two uint64 batch_record_limit no greater than 2^63; 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. When record_count is zero, closure_policy.empty_mode MUST be emit unless close_reason is shutdown or recovery.¶
• prev_segment_sha256 (bstr): 32-octet SHA-256 digest of the exact bytes of the previous authoritative segment artifact, or the epoch predecessor value defined in Section 4.6.¶
• record_count (uint): number of canonical-record occurrences committed by the segment.¶
• batch_roots (array of bstr): ordered aligned-subtree roots, each exactly 32 octets; exactly empty for an empty emitted segment.¶
• segment_root (bstr): 32-octet deterministic segment root.¶

Array position is the batch number. The root at position i MUST commit the consecutive sorted-leaf range beginning at i * batch_record_limit. The total root count, final-batch width, and composed segment root are derived from record_count and the committed closure policy as specified in Section 4.4.¶

The deterministic-CBOR object is the authoritative segment artifact. A JSON projection, filename, and storage path are non-authoritative. A verifier MUST validate that the producer manifest segment_number is the shortest unsigned decimal form defined in Appendix B, parse it as a uint64, and compare that numeric value with the decoded CBOR uint. A non-shortest decimal form is a producer manifest schema violation and therefore a bundle-processing error without a verifier result under Section 6.5.1. After a valid parse, a numeric mismatch with the artifact is commitment_mismatch. A verifier MUST NOT trust a path or filename as the segment number.¶

A serialized authoritative segment artifact conforming to this document MUST use the application/vnd.vtl.segment+cbor media type.¶

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 a 32-octet all-zero byte string.¶
• Every non-epoch segment MUST have a serial number exactly one greater than its predecessor, MUST retain the same ledger_id and commitment_profile_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 a new ledger_id so that the probability of collision with any other ledger identifier is negligible. A uniformly random 128-bit value from a cryptographically strong random source satisfies this requirement. 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, exact commitment_profile_id equality, and predecessor-digest linkage. A profile mismatch is a segment_chain_mismatch. A partial disclosure that omits the predecessor can still support validation of the disclosed artifact and its timestamp artifacts, 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 producer timestamp state. It MUST NOT contain a segment-chain validation conclusion, verifier status, failure reasons, or an overall verification outcome.¶

Each artifacts.record_batches entry opens the aligned batch subtree identified by its batch_number. Each nested records entry represents one admitted record occurrence. Duplicate entries are permitted and MUST be counted separately. When occurrences have identical canonical-record bytes, their entries MAY reference the same disclosed artifact. A verifier MAY reuse a successful digest computation for identical bytes, but the resulting leaf hash MUST contribute once for each listed occurrence. Artifact-reference order does not assert admission order.¶

For a non-empty segment, a Class A manifest MUST open every batch exactly once. For an emitted empty segment, a Class A manifest MUST omit record_batches. A Class B manifest MUST open a non-empty proper subset of a non-empty segment's batches and therefore cannot claim an empty segment. A Class C manifest MUST omit record_batches. An opening MUST disclose exactly the number of record occurrences derived for that batch from record_count and batch_record_limit. After hashing and sorting those exact record octets, their VTLRoot value MUST equal the indexed batch_roots value.¶

Producer timestamp state is limited to present when the corresponding timestamp response is disclosed, pending when issuance was initiated but has not reached a terminal state, and unavailable when issuance terminated without a usable response. Producer manifests MUST NOT use verifier states such as verified or failed.¶

A pending or unavailable state MUST omit tsa_tsr. A present TSA state MUST reference tsa_tsr. When a disclosed response contains a nonce, the manifest MUST also reference tsa_req. Producer obligations for a nonce-bearing request are specified in Section 6.4.¶

A serialized producer manifest conforming to this document MUST use the application/vnd.vtl.manifest+json media type.¶

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. Extension data is opaque to baseline verification and does not select an additional evidence channel or affect the baseline outcome.¶

5.2. Verifier Result

Verification under Section 6.5 produces a logical verifier result. Only that verifier-authored result states the exercised scope, any segment-chain conclusion, TSA channel status, verifier-policy identifier, 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 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 ... Verifiers MUST resolve and open every consumed path through a safe resolver that returns an object confined below the bundle root and prevents substitution of that object before it is consumed.¶

These are semantic requirements and do not depend on a regular-expression dialect or operating-system pathname behavior. Every artifact listed in the producer manifest MUST carry a lowercase hexadecimal SHA-256 digest entry.¶

After the primary-input boundary in Section 6.5.1 has been satisfied, an unsafe secondary reference is reported according to the role of the referenced object. A record or batch-opening artifact required for the claimed class or selected scope yields insufficient_disclosure. An unsafe referenced timestamp response yields TSA channel status missing and channel_failure. A disclosed predecessor that cannot be safely resolved yields chain_status equal to failed and segment_chain_mismatch. A reference that is safely opened but whose bytes fail the declared digest uses commitment_mismatch instead.¶

The producer manifest binds claim semantics to the authoritative segment artifact. The producer manifest's ledger_id, segment_number, and commitment_profile_id MUST match the corresponding fields in the authoritative segment artifact. An identity mismatch MUST be reported as commitment_mismatch. Segment-number comparison follows the rule in Section 4.5; profile selection follows Section 8.¶

6.1. Baseline Conformance

A baseline producer MUST emit the fixed commitment_profile_id defined in this document, construct authoritative segment artifacts and producer manifests under this profile, and initiate [RFC3161] timestamping for every emitted segment. Timestamp issuance MAY remain pending while incomplete.¶

A baseline verifier MUST implement this commitment profile and the RFC 3161 validation profile in Section 6.4, obtain the profile identifier from the authoritative segment artifact, and use the result vocabulary and fixed TSA channel key defined here. Every verifier result claiming baseline conformance MUST contain the tsa channel key, including when its status is pending, missing, or failed. A baseline success result requires successful timestamp validation.¶

Extension data is opaque to baseline producers and verifiers. Its presence, absence, or contents MUST NOT change a baseline channel status or overall outcome. A separate specification can define an additional evidence mechanism and its validation result without changing the authoritative segment artifact or the commitment profile defined here.¶

6.2. TSA Channel Status Vocabulary

Verifier results MUST use the following status vocabulary for the TSA channel:¶

• verified: timestamp validation succeeded for the disclosed artifact binding.¶
• pending: timestamp issuance was initiated but its response is not yet available; this is not equivalent to invalid.¶
• missing: an expected timestamp response is absent without a valid pending producer timestamp state.¶
• failed: validation was attempted and did not succeed.¶

A verifier that determines that valid producer timestamp state identifies issuance as incomplete MAY report pending only when its identified verifier policy accepts two out-of-band inputs: an authenticated channel or signature establishing manifest provenance, and an authenticated creation or receipt time for the pending claim, obtained independently of the manifest, that falls within the policy-defined maximum age. This document defines no manifest field carrying either property. A verifier without both inputs MUST report missing. Producer timestamp state unavailable maps to verifier status missing. A baseline verifier always evaluates the TSA channel and uses only the four states defined above.¶

The outcome effects of missing and pending are defined in Section 6.1 and Section 6.5.6.¶

The optional TSA-result reason value is human-readable diagnostic text. This document defines issuance_pending as its only baseline machine-defined token. Any other value is free text and MUST NOT be interpreted as a portable machine-actionable code. A channel result whose status is pending, missing, or failed MUST include reason. A verified channel result MAY include it. Additional machine-readable details MAY be placed in the channel result's extensions member under keys defined by the applicable extension specification or deployment. They are opaque to baseline verification.¶

6.3. Anchoring Contract

The anchoring contract is simple: a producer computes the SHA-256 digest of the authoritative segment artifact and submits that digest using RFC 3161. Verifiers MUST recompute that digest over the exact artifact bytes. Timestamp validation and comparison of its message imprint with that digest do not depend on successful CBOR decoding of the artifact.¶

An RFC 3161 timestamp 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.¶

Consequently, a producer manifest received over an unauthenticated channel can under-claim the available disclosure as Class C, omit record openings, or direct the verifier to a different valid authoritative artifact. Manifest digest checks establish consistency with the received manifest; they do not establish its provenance or that it names the artifact intended by the relying party. A relying party that needs those properties MUST obtain the authoritative artifact bytes or their expected digest independently through an authenticated mechanism and rerun verification from those bytes.¶

Baseline timestamping and success requirements are defined in Section 6.1. The producer MUST seal and durably write the authoritative segment artifact without waiting for timestamp issuance completion. Alternative timestamping or attestation mechanisms require a separate specification and do not alter this baseline contract.¶

6.4. RFC 3161 Timestamp Channel Profile

Baseline selection and implementation requirements for this channel are defined in Section 6.1.¶

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

These requirements deliberately define a narrower profile than generic RFC 3161 interoperability. In particular, this profile rejects grantedWithMods, the legacy SigningCertificate attribute, multiple SignerInfo values, and signer-certificate arrangements or ESS certificate identifiers that do not satisfy the exact rules above. A conforming VTL implementation therefore cannot assume that an arbitrary deployed RFC 3161 TSA is compatible. Deployments SHOULD prequalify a TSA against this profile before relying on it for baseline timestamping.¶

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 additional constraints applied to the token's generation time. It MUST define a maximum acceptable future skew relative to the verifier-local time source identified by the verifier policy. That source MUST be available when the future-skew validation is performed. 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 timestamp artifacts MUST recompute the authoritative segment artifact digest and validate the timestamp response 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] using the token's TSTInfo.genTime as its date/time input and configured trust anchors; configured TSA policy and certificate-validation constraints; a genTime value within the selected signer certificate's validity interval; and the configured maximum future skew.¶

The deployment's certificate-revocation policy MUST define acceptable revocation evidence and the treatment of historical certificate status at TSTInfo.genTime. This profile does not define a long-term archival-PKI validation profile beyond those policy inputs.¶

The optional producer-manifest artifact artifacts.tsa_req carries the exact DER-encoded TimeStampReq as a non-authoritative supporting artifact. A producer that sends a request containing a nonce MUST retain those exact request bytes for at least as long as it retains the corresponding response bytes and MUST disclose the request with that response. The producer MUST NOT treat a response that omits or changes its request nonce as successful timestamp issuance.¶

When a disclosed response contains a nonce, the producer manifest MUST reference tsa_req. Whenever tsa_req is disclosed, the verifier MUST validate that reference's SHA-256 digest, require the request message-imprint algorithm to be SHA-256, require its hashedMessage to equal the recomputed authoritative segment artifact digest, and require certReq=TRUE. If either disclosed object contains a nonce, the request and response MUST both contain a nonce and the two values MUST be equal. A nonce-bearing response without tsa_req, a disclosed nonce present in only one object, unequal disclosed nonces, or any failure of those checks is a timestamp-channel verification failure reported with channel_failure. A nonce-free disclosed request is validated under the same non-nonce rules.¶

If the response contains no nonce and tsa_req is not disclosed, a verifier cannot determine whether the original request contained a nonce. The verifier can validate the signed response and its artifact-digest binding, but the result makes no claim of request-response nonce correlation. The producer obligations above remain applicable and cannot be inferred from the baseline disclosure in this case.¶

Any failure of the RFC 3161 validations above 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.5. Verification