]> Assault Consulting

Kyiv Ukraine as@assault.consulting https://palimpsests.dev/pala-1/

Assault Consulting

Kyiv Ukraine ov@assault.consulting https://palimpsests.dev/pala-1/

audit trail tamper-evident logging AI inference hash chain crypto-shredding local-first This document describes PALA-1 -- version 1 of the Portable Append-only Log for Audit -- a compact binary record format for tamper-evident audit trails produced by AI inference runtimes and robotic control systems. It is designed for a class of deployment defined by three constraints that hold together: the hardware is computationally modest and its cycles are reserved for the workload and the power budget rather than for the audit trail; no external witness is reachable, whether because policy forbids outbound contact or because the platform operates beyond connectivity, so a witness is unavailable by rule or by physics rather than by circumstance; and the right to verify the trail is separated from the right to read what it records. Records form an append-only hash chain. Integrity verification requires no key material of any kind, inspects no record bodies, and costs one hash per record rather than one signature. The format distinguishes three separately answerable questions -- internal consistency, completeness against an external anchor, and existence at a point in time against an external witness -- and states which of the three a given trail actually supports rather than implying all three. The format is frozen at version 1.0 and is described here as it is. This document presents an existing wire format; it does not revise one. Where a deployment does permit an external witness, a chain head may be published to a transparency service such as that of the Supply Chain Integrity, Transparency, and Trust architecture (SCITT, RFC 9943); that path is described but is not part of the hashing contract.

Introduction An AI inference runtime executing on a workstation, an edge device, or a robot produces a sequence of events that someone may later need to reconstruct: what was asked, what was answered, which tools were dispatched, what came back, and what the operator did about it. A growing body of work addresses this by making a record transparent: the producer signs a statement, registers it with an external service maintaining an append-only log, and receives a receipt proving registration . Where that construction is available it answers questions this format cannot answer alone, and this document describes how to reach it (). It presupposes two things: that cycles are available to sign each record, and that a witness is reachable. This document addresses the deployments where neither holds.

The constraints Three constraints defined this format. They are stated first because every subsequent decision follows from them, and a reader who rejects them will reject the format. C1 -- the hardware is modest, and its cycles are reserved for the workload and the power budget. The target is a control system or an inference runtime on commodity or embedded hardware, frequently one that carries its own power. A trail that writes thousands of records in a session cannot spend an asymmetric signature on each one: that cost is taken directly from the workload the device exists to run, and on a self-powered platform it is taken from endurance as well. The usual answer to a compute constraint -- provision a faster processor -- does not resolve the second of those, since a faster processor draws more. Integrity therefore has to come from hashing a chain, not from signing a record. C2 -- no external witness is reachable. This is not a network that happens to be down. It is either a regime under which reaching an external service is not permitted, or a platform operating beyond connectivity by the nature of its task; in both cases the witness is unavailable by rule or by physics, and no engineering effort changes it. The distinction from C1 matters: C1 is a constraint that better hardware partly relaxes over time, while C2 does not relax at all. Any design that requires a service to be reachable before a record is trustworthy is inapplicable here, not merely inconvenient. C3 -- the right to verify is separated from the right to read. An auditor may be entitled to establish that a trail is intact and complete while holding no clearance for what the trail records. This is an access regime, not a privacy preference, and it makes "verification requires reading the records" an unsatisfiable requirement rather than an acceptable cost.

What the constraints force Each of the following is a consequence, not a preference. From C1: the chain hash covers a fixed-length record header, one hash per record, no asymmetric operation on the write path. From C1 and C3 together: because there is no per-record signature, there is no per-record signature to check, and integrity verification consequently needs no key material at all. A verifier reads headers, reports that a million records contain no break, and has read none of the bodies. The header is fixed-length so that it can be scanned and sought without parsing a variable structure. From C3: bodies are bound into the chain by a digest carried inside the header, so a body may be encrypted, or its key destroyed, while the chain continues to verify. Key destruction is an ordinary lifecycle operation in such a deployment rather than an exceptional one. From C2: existence in time is never asserted by the format on its own authority. Where a deployment does permit publication, the claim is made after the fact by a record naming an explicit range and a witness, and a verifier reports the witnessed range and the unwitnessed remainder separately (). A trail that has never been witnessed says so. And from all three: the format is binary and has no canonicalisation step, because a canonicalisation step is a place where two conforming implementations can disagree about the bytes being hashed. A JSON canonicalisation such as serialises numbers through double semantics, and a nanosecond wall-clock value exceeds the largest integer a double represents exactly, so its canonical form is lossy. The available workarounds -- the value as a string, truncation to milliseconds -- each trade the property JSON was chosen for against the one property this format cannot trade: byte-exact agreement between independent implementations. Inspectability is recovered by a converter, which is a tool and not part of the hashing contract.

On COSE The question this section exists to answer is why the records are not COSE_Sign1 structures, given that CBOR encodes a nanosecond integer exactly and is not subject to the objection above. The objection above is to JSON canonicalisation, and it does not apply to CBOR. A CBOR encoding could carry the same chain semantics this document defines, and an implementer who values ecosystem alignment over the constraints of should consider that a reasonable design. What C1 and C3 exclude is not the encoding but the envelope. COSE_Sign1 places a signature on each record and a verification key in the hands of anyone checking one. Both are intrinsic to what a single-signer signature envelope is, not parameters of it, and both are the two properties C1 and C3 rule out. A signature per record is the cost C1 forbids; a key required to verify is the dependency C3 forbids. The trade-off applies in both directions and is stated here rather than left for a reader to find. A COSE_Sign1 record is self-sufficient: it carries its own evidence, and one such record proves something on its own. A PALA-1 record proves nothing on its own -- the sequence is what carries the evidence, and a single record removed from its chain is inert. For deployments that write few records, are not compute-constrained, and need per-record self-sufficiency, the envelope is the better choice and this format is the wrong tool. Where the two meet is : a chain head expressed as a Signed Statement is a COSE_Sign1 structure, so the envelope is used exactly where its cost is paid once rather than per record.

Scope In scope: the byte layout of a record, the rules linking records into a chain, the aggregation of record digests, the encoding of assurance claims, and a normative verification procedure any party can implement from this document alone. Out of scope: agent-to-agent protocols, authorization decisions, policy evaluation, transport, and the internal protocol of any witness. This document records what a runtime did. It does not decide what a runtime may do, and it makes no claim about the honesty of the runtime at the moment of recording ().

A note on regulation The constraints of arose in deployments that are also subject to record-keeping, data-minimisation and erasure obligations, and those obligations shaped what the format was required to support: that a trail can be verified without disclosing its contents, and that a record's content can be destroyed without falsifying the trail it sits in. No claim is made that this format satisfies any legal obligation. Regulations of this kind do not prescribe formats, and a format cannot discharge a duty that falls on an operator. The relationship is only that a set of obligations produced a set of technical requirements, and this document specifies a format meeting them.

Terminology PALA stands for Portable Append-only Log for Audit. Portable: a PALA-1 log verifies on any machine, offline, with no key material. Append-only: records are only ever added to a hash chain. For audit: that is its purpose. The expansion is descriptive and has no normative effect. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Record layout A record is header || body. The body may be empty.

Fixed header -- 156 bytes Offset Size Field Type Notes 0 4 magic bytes PALA (0x50 0x41 0x4C 0x41) 4 2 format_version u16 1 6 2 header_len u16 156 + TLV bytes. Total header length. 8 2 record_type u16 10 1 assurance_tier u8 11 1 time_trust u8 12 8 seq u64 Monotonic within a chain. Never reused. 20 16 boot_id bytes Opaque, unique per boot 36 32 prev_hash bytes record_hash of the previous record 68 16 span_id bytes Zero if not span-scoped 84 16 parent_span_id bytes Zero = root 100 8 monotonic_ns u64 Since boot. Never wall-clock. 108 8 wall_clock_ns i64 Nanoseconds since Unix epoch, or 0 116 4 key_id u32 0 = no body, or a cleartext body. 120 4 body_len u32 124 32 body_digest bytes SHA-256 of the body bytes, or 32 zero bytes if body_len = 0 All multi-byte integers little-endian. No padding. header_len MUST be >= 156 and MUST equal the actual number of header bytes.

TLV extensions Immediately after the fixed header, until header_len is reached:

bytes ]]>

A TLV item MUST NOT overrun header_len. The last item MUST end exactly at header_len. Unknown TLV types MUST be hashed and MUST NOT cause rejection. They are opaque bytes to a verifier that does not know them. This is what makes possible. Type Name Value 0x0001 ORIGIN_ROLE UTF-8 role of the emitting component, e.g. planner.main; vocabularies are profile-defined () 0x0002 ORIGIN_MODEL_DIGEST 32 bytes 0x0003 ORIGIN_CONFIG_DIGEST 32 bytes 0x0011 MERKLE_TREE_HASH 32 bytes 0x0012 MERKLE_LEAF_COUNT u32 0x0020 SHED_CLASS u16 0x0021 SHED_COUNT u32 0x0022 SHED_WINDOW_NS u64 0x0030 WITNESS_KIND u16 -- 1 = transparency log, 2 = TSA 0x0031 WITNESS_RANGE_LO u64 0x0032 WITNESS_RANGE_HI u64 0x0033 WITNESS_RECEIPT opaque 0x0040 SHRED_KEY_ID u32 0x0050 ANCHOR_HEAD 32 bytes -- the head written to the anchor store. TLV type numbers and record type numbers are separate namespaces. TLV 0x0011 MERKLE_TREE_HASH and record type 0x0020 MERKLE both concern Merkle aggregation and are different numbers in different spaces. The names are kept distinct for that reason; do not read one table with the other's numbers. origin is three TLVs, not a name. (ORIGIN_ROLE, ORIGIN_MODEL_DIGEST, ORIGIN_CONFIG_DIGEST) -- because the first question after an incident is which weights produced an output, and a component name alone does not answer it. A model update is a different origin and the chain shows it.

body_len -- exactly what it counts

• body_len is the total number of bytes following the header, up to the start of the next record. A reader that consumes body_len bytes after header_len has consumed the whole body and nothing else.

For an encrypted body () that total covers nonce || ciphertext || tag -- the nonce is inside the count, not additional to it. body_digest is taken over exactly those body_len bytes. This is stated explicitly because it is the most likely implementer error: a reader that treats the 12-byte nonce as a prefix outside body_len truncates the GCM tag, fails to decrypt, and attributes the failure to the cipher.

File container A log file is records concatenated back-to-back, with no file header, no framing, and no trailing metadata. The first record starts at byte 0. A reader finds record boundaries from the records themselves: read the fixed header at the current offset, confirm magic, take header_len and body_len, and the next record begins at offset + header_len + body_len. A file whose final record ends exactly at end-of-file is well-formed; anything else is a truncated tail and MUST be reported as such (it is not a chain break at any earlier record). There is deliberately nothing else at file level. A file header would be one more thing to version, and the records are already self-delimiting; rotation, segmentation and naming are storage concerns outside this format -- a segment boundary is invisible to the chain, which continues across files exactly as it continues across boots.

Record types Value Name Class Meaning 0x0001 GENESIS never-shed Chain origin. 0x0002 BOOT never-shed New boot. Its prev_hash is the cross-boot link. 0x0010 SPAN_START normal Opens a span 0x0011 SPAN_END normal Closes it. 0x0012 EVENT normal Point event. Payload semantics are profile-defined (). 0x0020 MERKLE sheddable Digest aggregation over a window. 0x0021 AGGREGATE sheddable Tier 0 statistics over a window. 0x0030 SHED never-shed Records that records were dropped. 0x0040 SAFETY never-shed Written by the safety path; the audit only observes 0x0050 ANCHOR never-shed Local anchor written. 0x0051 WITNESS never-shed External witness receipt. 0x0060 KEY_SHRED never-shed A key was destroyed.

Spans are two records SPAN_START and SPAN_END are separate chained records. Duration is derived at read time. The alternative -- one record written on close -- loses exactly the case that crashed. A crash must leave a visibly unclosed span, because that is the evidence. This also fixes the limit of the whole design: the audit cannot guarantee a record precedes the action it describes -- that would require blocking, which the architecture forbids. It guarantees only that absence is visible: the property provided is detectable absence, not write-ahead semantics.

AGGREGATE body schema Tier 0 statistics are not personal data, so an AGGREGATE body SHOULD be cleartext (key_id = 0). Encrypting it would only make the post-market monitoring export useless to the party entitled to read it. The body is a TLV sequence, encoded exactly as , in its own type namespace. The core defines the window framing; the measured quantities are profile-defined: Type Name Value 0x0001 AGG_WINDOW_NS u64 -- length of the aggregation window. Core. 0x0002 AGG_SAMPLE_COUNT u32 -- samples folded into this record. Core. 0x0003+ profile-defined Allocated upward from 0x0003 by the chain's profile () A reader treats body tags it does not know as opaque -- reported, never rejected -- the same posture takes for the header. Because one chain follows exactly one profile (), profile allocations cannot collide within a chain. Milli-units, not floats -- a constraint on profiles. A float in a body reintroduces exactly the cross-implementation disagreement rejects JSON for -- and it would do so in the one record type whose whole purpose is being comparable across versions and vendors. A profile MUST express fractional quantities as fixed-point integers (milli-, micro-). Fixed-point integers carry no cross-implementation ambiguity. The framing is defined here rather than left to implementations because AGGREGATE is the PMM instrument: a wholly undefined body means two conformant implementations produce incomparable exports, which defeats the record type. The core fixes the window; each profile fixes the quantities -- so two implementations of the same profile are comparable. The robotics profile published with the specification defines optical-flow statistics at 0x0003-0x0005.

SHED is in the never-shed class The audit never blocks the execution path. Therefore records are dropped under saturation, and which records is a design decision, not an accident. A dropped record is survivable. A silently dropped record is a log that misrepresents by omission, which is worse than no log. SHED carries class, count and window, and it is never itself shed.

Profiles The envelope must outlive any one domain, so the split is structural: this document defines everything a verifier needs -- layout, chain, tiers, time, cryptography, the three questions -- and profiles define what the records are about. A profile is a companion document that fixes, for one domain: EVENT payload semantics -- what lives in the bodies; AGGREGATE quantities -- body tags from 0x0003 upward (); MERKLE leaf source -- what the aggregated digests are digests of, and at what rate (); ORIGIN_ROLE vocabulary -- the component names that appear in headers. One chain follows exactly one profile. Which profile is a property of the deployment, stated by the emitting system's documentation; the format does not carry a profile identifier in version 1 (a chain's ORIGIN_ROLE vocabulary makes it evident in practice, and adding a field is a v1.0 freeze decision, not a retrofit). Mixing profiles within one chain is out of scope. Verification is profile-independent. Every check in reads the envelope only; a verifier needs no profile knowledge to answer the three questions, and profile content it does not understand is opaque bytes -- reported, never rejected (, ). Two profiles are published with the specification : a robotics profile -- the first, and the one the committed test vectors follow -- and an inference profile, under which the reference implementation audits its own serving loop.

Recording at the dispatch boundary This section is informative and describes an emitter obligation that the record types of this document are shaped to support. A hash chain constrains the relationship between records. On its own it does not constrain when a record was written relative to the event it describes. A producer could execute an entire session and afterwards emit a chain that is internally consistent, verifies correctly, and records only what the producer chose to say about itself. Such a trail is conformant and evidentially weak, and the distinction matters wherever the question is whether a control actually operated. The record types here are designed so that a conforming emitter does not have that freedom in the one place it matters most: the tool-dispatch boundary, where an inference runtime causes an effect outside itself. A tool call is recorded when the call is handed to its executor, before any result is known. The result is recorded as a separate record bound by digest to the call it answers, so an attempt cannot be presented as a completion. On shutdown, a call with no recorded outcome is explicitly cancelled in the chain, so a reader never encounters a dispatch whose fate is unstated. Span-structured events are two records -- one at open, one at close -- for the same reason. The consequence a verifier can rely on: for every dispatch in a conforming trail there is a record written before the outcome existed, and every such record has a stated fate. What no format can supply is an assurance that the emitter obeyed this. That is a property of the implementation, which is why the verification procedure treats an unpaired dispatch as an advisory finding to be surfaced rather than silently tolerated, and why independent implementations of this document are the evidence that matters (). A second limit is stated for the same reason. An emitter can record only the dispatches it mediates as structured data. A client that negotiates tool use with the model in free text and executes the result locally produces no dispatch at the emitter's boundary, and therefore no record; the reference implementation measured this with a widely used agent client and documents it as a visibility limit rather than concealing it (). A trail's silence about tool use is evidence of what the emitter observed, not of what the client did.

Chain rules

Linking

seq MUST increase by exactly 1 within a chain. A gap in seq is a break, whether or not the hashes link, and a verifier MUST report it as one (). The rule is not redundant with the hash link. An actor holding the key can rebuild a shorter, perfectly linked chain that omits a range of seq; the hashes will chain and only the gap reveals it.

Genesis and boots GENESIS has prev_hash = 32 zero bytes and record_type = GENESIS. A distinguished type is required so that "no predecessor" and "predecessor removed" are distinguishable. prev_hash = 0 alone is not sufficient. A verifier MUST report as a violation any chain whose first record is not a GENESIS (the record is the wrong kind; the links around it may be perfectly sound), and MUST report a GENESIS at any position other than the first as a violation. Defining the type and then not checking it adds nothing. A BOOT record's prev_hash is the previous boot's head. The chain is continuous across power cycles; a deleted segment leaves a head nothing references. What this does not fix -- stated in the format, not hidden in prose: an owner with the key can start a new GENESIS and present the device as new. Chain continuity cannot prove device continuity. Only addresses that, and only partly.

Merkle aggregation High-rate digests are aggregated per window into one MERKLE record -- the digest source and rate are profile-defined (): the robotics profile folds a second of sensor-frame digests into one record; an inference profile might fold a batch of token or KV-operation digests. The tree is the same either way. tree hash, domain-separated:

An unpaired node is PROMOTED, never duplicated. Duplicating the last node is the CVE-2012-2459 mistake: two distinct leaf sets collapse to the same root. An inclusion proof for a leaf is the list of sibling hashes on the path from that leaf to the root, each tagged with the side the sibling occupies: an entry ["L", s] means the sibling is the left operand of node() -- the step computes node(s, h) -- and ["R", s] computes node(h, s). Folding the leaf's leaf() hash through the entries in order MUST reproduce the tree hash. This is the encoding the published vectors use for the inclusion proof . Two constructions are in circulation and they agree, which is worth stating so an implementer does not go looking for a discrepancy: RFC 6962 defines the tree recursively, splitting at the largest power of two below n; the iterative bottom-up form that promotes an unpaired node yields the same root. Either may be implemented. This provides selective disclosure: one leaf can be proven with about log2(n) hashes without revealing the other n-1 -- one moment, without the rest of the window. The count is a commitment, verified against the leaves -- never in the header. MERKLE_LEAF_COUNT states how many leaves the root covers. Because the MERKLE record does not carry the leaves, only a party that has them -- checking a disclosure, or holding the full set -- can confirm it, and such a verifier SHOULD check that the number of leaves equals MERKLE_LEAF_COUNT and reject a disclosure whose count disagrees. A mismatch is a defect of that disclosure, not a chain violation: the header and its chain are intact; what was revealed is inconsistent with what was committed. A header-only verifier () neither has the leaves nor checks the count.

Bodies, encryption and crypto-shredding A body is one of two shapes, and key_id says which: key_id Body 0 Absent (body_len = 0), or cleartext: body is the raw bytes != 0 Encrypted: body = nonce (12) \|\| ciphertext \|\| tag (16) In both cases body_digest = SHA-256(body_bytes) over exactly body_len bytes. The digest does not know which shape it covered -- which is why crypto-shredding does not disturb it. Body encryption is AES-256-GCM .

The AAD binds the ciphertext to its position in the chain: bodies cannot be swapped between records. The nonce is derived from seq, not random. A random 96-bit nonce is not safe past ~2^32 records under one key -- a horizon a sustained high-rate writer actually reaches within the ten-year lifetime this format must survive (a 30 Hz emitter crosses it in under five years; higher rates get there sooner). A seq-derived nonce is unique per record by construction -- seq never repeats within a chain () -- and its only leak is the record's position, which the cleartext header states anyway. A key MUST NOT be reused across chains with independent seq spaces. Order of operations is normative (it is otherwise circular): 1. encrypt -> 2. compute body_digest -> 3. fill the header -> 4. record_hash. Crypto-shredding. Keys live outside the log, addressed by key_id. Erasure = destroying K[key_id]; a KEY_SHRED record notes it. The body becomes noise, body_digest stays, the chain still verifies. A verifier reports "record exists, body unreadable" -- a reported condition, not a gap in the chain. Shred granularity equals key granularity, and that is a deployment decision, not a format one. Per subject, per session, per day -- the format only requires that key_id exists and that destroying a key breaks nothing structural. key_id scope is one device. 2^32 keys is ample per device and ambiguous across a fleet: two devices may both use key_id = 7 for unrelated keys. A fleet key-management layer MUST qualify key_id with a device identity of its own; the format does not carry one.

Time A device without a battery-backed real-time clock boots with its wall clock at the Unix epoch, and network time synchronisation is unavailable under C2. Therefore: monotonic_ns and seq are authoritative for ordering. Always present. wall_clock_ns is advisory and always accompanied by time_trust: time_trust Meaning 0 UNKNOWN -- wall_clock_ns MUST be 0 1 UNSYNCED -- free-running, no external reference 2 HW_RTC -- battery-backed clock, unverified 3 NTP_SYNCED -- externally synchronised Values above 3 are undefined in version 1. A verifier MUST report a record whose time_trust is UNKNOWN with a non-zero wall_clock_ns as a violation (): an unenforced requirement is not a requirement, and this one separates an explicit statement that the time is unknown from a timestamp that cannot be justified. The first can be defended; the second cannot.

Assurance tiers The format states how much it can be trusted. It does not overstate. Tier Mechanism Proves Does not prove A = 0 Chain + local anchor A record was modified; with the anchor, that nothing was truncated Everything else B = 1 + hardware root of trust Device identity Fresh genesis -- a TPM signs any chain B+ = 2 + monotonic NV counter bound to seq Counter never returns to zero -> fresh genesis visible Platform-bound Tier C is deliberately not a header value. Tier C -- periodic publication of the chain head to a transparency log or an TSA -- proves existence at time T, which is the guarantee that actually defeats a fresh genesis. But a header cannot honestly claim to have been witnessed before the witness exists. So tier C is asserted after the fact, by a WITNESS record covering a seq range. A verifier reads:

• records 0-9: externally witnessed at 2026-07-16T10:00Z records 10-...: tier A, no existence claim

C is strictly stronger than B here, because fresh genesis is a question of existence, not identity. Its cost is one published hash, not data: the model of Certificate Transparency applied to an audit trail.

Relationship to transparency services This section is informative. It adds no requirement and changes no byte. The strongest question this format cannot answer from its own bytes is existence at a point in time. A chain proves that its records have not been altered relative to one another. It does not prove that the chain was not created wholesale after the fact, because a producer in possession of its own keys can construct a consistent history at any time. Defeating that requires a party other than the producer to have observed a commitment, and the observation has to have happened. PALA-1 handles this by deferring the claim rather than asserting it. A witness record covers an explicit range of sequence numbers and states that the head of that range was published externally. The record is itself chained, so the claim cannot be inserted retroactively without breaking the chain, and a verifier reports the witnessed range and the unwitnessed remainder separately. The protocol by which the external publication is verified is the witness's own and is out of scope here. A SCITT transparency service is one such witness, and a natural one where a deployment permits it. A producer takes the chain head, expresses it as a Signed Statement -- a COSE_Sign1 whose payload commits to the head by digest -- registers it with a transparency service, and attaches the returned Receipt -- a COSE Receipt -- to the statement's unprotected header, producing what calls a Transparent Statement, which is then carried in the evidence the producer exports. What the producer publishes is one digest, not the trail: no record body, no personal data, no model output leaves the device. The envelope's cost is paid once per published head rather than once per record (), which is what makes it affordable under C1. The construction published with the specification is stated here so that it can be checked rather than assumed. The statement's protected header carries the algorithm, the payload's content type, a key identifier, and CWT claims for issuer and subject under the header label registered by . The key identifier is the COSE Key Thumbprint of the verification key . The subject names the full chain head, for two reasons. A transparency service indexes by the subject, and distinct chains must not collide under it. And lets a later Signed Statement from the same Issuer with the same subject supersede an earlier one, which is the wrong relation between two heads of one chain: a later head does not replace an earlier one, it extends it, and the earlier statement remains true. Distinct subjects keep a reader from setting an earlier head aside; the relation between two heads is carried instead by the root. The payload is attached, so that the statement is readable offline, without the service: a CBOR map of the head, the sequence range the publication reports, the format identifier, and the root -- the tree of over the record hashes of records 0 through the last one covered, whatever range the publication reports. The root is what connects two registered statements of one chain without the chain: a consistency proof between their roots shows that the earlier state is a prefix of the later one. Such a proof establishes something only when its two roots have independent provenance, and a registered statement is exactly that -- a root fixed at one registration and another at the next . The construction published first, without the root, remains valid and is told apart by its content type; it can be checked against a chain but cannot be connected to another statement without one. Section 6 of requires the kid header parameter when neither x5t nor x5chain is present in the protected header; its initial omission was found by a reproduction of the statement performed under a stated contamination boundary and was corrected before any registration took place (). Two properties of the envelope bear on what such a statement can be said to be. First, byte-for-byte reproduction of a statement by an independent implementation is achievable only when the signature is deterministic: EdDSA provides that by construction, whereas an ECDSA signature is deterministic only as a per-library choice, so two conforming implementations may emit different signature bytes over identical input. The published vector therefore uses EdDSA, and a vector over ECDSA could claim that a statement verifies, not that it reproduces. Second, a valid signature and the published bytes are two different facts: content in the unprotected header, the presence or absence of the outer CBOR tag, a detached payload, or a non-canonical Ed25519 scalar each yield an artifact with different bytes over which the signature still verifies. An auditor comparing an artifact to a published one compares bytes; an auditor accepting a statement checks the signature; the two checks are not substitutes for each other. enumerates these cases with executable expectations. Under C2 this path is closed -- by policy or by the absence of any reachable service -- and the format is designed so that its closure costs nothing structural: a trail that is never witnessed is still verifiable for internal consistency and, against a local anchor, for completeness. It simply does not claim the third question, and says so. Two properties of this arrangement are worth stating plainly, because the difference between them is the difference between a claim and a proof. A verifier that has checked a Receipt against a log key it trusts may report the covered range as externally witnessed. A verifier that has not checked one MUST NOT, whatever the trail says about itself. The overclaim rule that governs every assurance field in this document governs this one. And the guarantee itself is bounded. A Receipt establishes that a commitment was registered, and therefore bounds when the trail can have been constructed and makes later substitution or omission detectable. It does not establish that the recorded content is true. That boundary is not peculiar to this format; it applies to every construction of this kind, including the transparency service's own.

Verification Verification answers three questions, and they MUST NOT be collapsed into one boolean. Each needs different inputs and each fails differently. Question Needs Answers Is what I hold internally consistent? Nothing Modification, reordering, seq gaps Is what I hold all of it? An anchor, from outside the log Truncation, replacement, rollback Did this history exist at time T? A witness receipt Fresh genesis A verifier that reports only as "ok" is misleading, because cannot see a truncated tail: dropping the last N records leaves a perfectly linked chain with a different head and no other trace.

Header-only chain verification Requires no key. Touches no bodies.

chain_ok is true iff breaks, gaps and violations are all empty. It means internally consistent, nothing more. A chain whose first record is not a GENESIS yields exactly one violation -- the wrong kind of first record. Per , the links around it may be perfectly sound: the zero-prev_hash requirement applies only when the first record is a GENESIS, and the break check compares only records that have a predecessor in the file. (Aligned at the final pre-freeze verification run: read literally, the earlier pseudocode produced two violations and a spurious break on this case, contradicting this section's own prose above and . The published missing-GENESIS demonstration had not discriminated the two readings -- its input satisfied both -- until that run constructed the discriminating case; the demo input was strengthened accordingly, with its published outputs unchanged.) breaks and gaps are reported at the record's seq. Violations from per-record checks are likewise keyed by seq; the chain-does-not-start-with-GENESIS violation is reported at position 0, because it is a property of the chain, not of any record's seq.

Completeness against an anchor The anchor is the head this chain is supposed to have, obtained from outside the log: the current head held in the local anchor store (an OS keychain entry), or the head covered by the newest WITNESS receipt. An in-chain ANCHOR record with its ANCHOR_HEAD TLV records a store write at the time it occurred -- a historical note, not the anchor itself. Because a writer may append records after a store write, the newest ANCHOR record's head can lag the store's current head; a completeness check therefore uses the store's current head, not any in-chain ANCHOR record's TLV. Given an anchor A and a computed head H: Condition Report A == H Complete to the anchor A is the record_hash of some record in the chain Unanchored tail: anchor_lag = N records past the anchored head. A crash between write and anchoring, or an anchor-store outage -- or records appended by a writer without anchor access. A names no record in the chain Replaced, rolled back, or truncated. This is not the history that was anchored. Both non-matching cases are failures; the diagnosis differs, and the diagnosis is what an auditor acts on. Without an anchor a verifier MUST report completeness as not checked -- never as passing.

Existence against a witness A WITNESS record asserts that the head of records [RANGE_LO, RANGE_HI] was published to an external log at some time. Verification is out of scope for this document -- it follows the witness's own protocol (a COSE Receipt , a Rekor inclusion proof, an token). What this format guarantees is only that the claim is in the chain, is itself chained, and names its range explicitly. A verifier SHOULD report the witnessed range and the unwitnessed remainder separately ().

Semantic checks On records whose version and type are known -- GENESIS and BOOT included. The position checks makes at index 0 (the record is a GENESIS, its prev_hash is zero) are in addition to these, not in place of them: a GENESIS with time_trust = UNKNOWN and a non-zero wall_clock_ns is as much a violation as any other record. The checks: time_trust == UNKNOWN => wall_clock_ns == 0 () time_trust <= 3 () body_len == 0 if and only if body_digest == 32 zero bytes () key_id != 0 and body_len > 0 => body_len >= 28 (nonce + tag, ) TLV items parse and end exactly at header_len () These are violations, not breaks: the record is defective, the chain around it may be sound. They MUST be reported distinctly. MERKLE_LEAF_COUNT is deliberately not among these checks. A MERKLE record carries the root and the count but never the leaves (body_len = 0, ), so a header-only verifier does not have the leaves to count and does not treat the field as verifiable here -- it is a commitment, checked only when the leaves are disclosed. says how.

Body verification (needs the key) SHA-256(body) == header.body_digest, then -- if key_id != 0 -- AES-256-GCM decrypt with the nonce and AAD of . Failure to decrypt with a matching digest means the key is wrong or destroyed -- not that the log is corrupt. These MUST be reported distinctly.

Forward compatibility A verifier meeting an unknown format_version, record_type or TLV type: MUST still chain-verify it -- the hash is over raw bytes MUST report it as uninterpretable MUST NOT reject the chain MUST NOT apply to it -- those checks belong to a version it claims These fields are frozen for all future versions: magic, format_version, header_len, record_type, seq, boot_id, prev_hash, body_len, body_digest, at their stated offsets. body_len is in the frozen set for a mechanical reason: without it a verifier cannot find the next record, and forward compatibility ends at the first unknown record with a body. That freeze is what allows a tool written today to report, on a trail written ten years later:

• "Chain intact, 1.2M records, no gaps, 400 records I cannot interpret."

Test vectors The full set -- every record byte, the Merkle leaves and the inclusion proof -- is published as . The vectors are deterministic: a fixed key, derived nonces and fixed identifiers -- real cryptography over deterministic inputs. Such inputs MUST NOT be used outside a test vector. The vector chain's record bodies and narrative follow the robotics profile (). Every property demonstrated below is an envelope property and holds under any profile. The chain is a representative ten seconds: genesis, boot with no clock, a brain span, a c' write with an encrypted body, a second of frames, a second of Tier 0 statistics, a divergence event, a shed notice, span close, a local anchor, an external witness, and an erasure.

000000000300000000000000 body plaintext (seq 3) = "clear path ahead, one pedestrian at 12m, static" ]]>

seq type note 0 GENESIS tier A, time UNKNOWN 1 BOOT wall_clock_ns = 0, time_trust = UNSYNCED 2 SPAN_START brain 3 EVENT AES-GCM body, key_id = 7, origin = eyes.tier1 + digests 4 MERKLE 30 frame digests 5 AGGREGATE cleartext TLV body, key_id = 0 6 SAFETY divergence, origin = perception_health 7 SHED class 1, 400 records, 12 s window 8 SPAN_END   9 ANCHOR carries the head anchored at seq 8 10 WITNESS transparency log, covers seq 0-9 11 KEY_SHRED key 7 destroyed -> seq 3 body unreadable Expected results -- an implementation that disagrees with any of these is wrong, or this specification is:

The ANCHOR record at seq 9 carries, in its ANCHOR_HEAD TLV, the head as of seq 8 (14434088e5f5866cf0276ba5a9055d8ee0d115a750b2cdf9cc4006d9481b29b4) -- a historical store write that lags the tip by 3. It is not the completeness anchor (which is the store's current head, anchor_head above); the stale_anchor demonstration below checks against it deliberately. Seven properties the vectors demonstrate rather than assert: Demo Result Flip one bit in the seq-3 body body_digest mismatch detected and the chain still verifies -- body damage and chain damage are distinct failures Append a record of unknown type 0x7fff chain_ok = true, count = 13, uninterpretable = [12] -- works Destroy key 7 seq 3 body unreadable forever, chain unchanged -- works Drop the last record chain_ok = true without an anchor; complete_to_anchor = false with one -- cannot see truncation, can. This is why the two questions are separate. Stale anchor (anchor names seq 8, chain has 12) anchor_lag = 3, reported as an unanchored tail, not a replacement seq gap 11 -> 99 with valid hashes chain_ok = false, gaps = [99] -- Chain with no GENESIS chain_ok = false, violation "chain does not start with a GENESIS record" -- time_trust = UNKNOWN with a non-zero clock chain_ok = false, violation -- Companion vectors publish Signed Statements over this chain in the construction of , EdDSA under the published test key of Section 7.1. The first, over the chain head without a root, is 331 bytes; it was reissued once, after a reproduction performed under a stated contamination boundary found the conformance defect described in , and both versions and their digests are on the record. The second publishes two statements of 369 bytes each -- over the first 8 records and over all 12, the later one reporting the range 8 to 11 with its root still over records 0 to 11 -- together with the consistency proof between the roots they carry: two signatures, two roots and a proof, with no chain. Each comes with expected bytes, digests and tamper expectations, including the byte-stability cases stated in .

Related work Evidence for the conduct of AI systems is an active area, and most of the current work sits in a different place in the stack than this document. The distinctions below are stated to locate this format, not to rank the documents. Transparency substrate. defines an architecture in which an issuer registers a signed statement with a transparency service and receives a receipt, generalising the approach of certificate transparency to arbitrary content. It is the substrate a number of the documents below profile, and, as described in , the natural witness for a PALA-1 chain head. This document does not compete with it; the two operate at different points and compose. Statement profiles for agent conduct. A cluster of individual submissions profiles that substrate for AI agents. records verdict-level disposition for a single agent action, with a binding that distinguishes a dispatched effect from an observed result and a flag that prevents a policy approval from being presented as human oversight. records pre-execution authorization -- whether an action was permitted, rather than what occurred. defines operator-signed interaction records with redaction receipts. frames hash chaining, signatures and anchoring as a conformance-tiered provenance architecture. profiles receipts for a specific regulatory transparency obligation. records session-level governance audit records produced by an enforcing component. defines a signed record of one agent action -- an in-toto predicate in a DSSE envelope -- carrying both the authorization decision and the observed effect, with a derived agreement between them. These are per-action or per-session statement profiles, expressed in JSON or CBOR, made transparent by registration with a service or by external anchoring. This document specifies a wire format for a continuously appended local trail, verifiable without a service and without a key, under the constraints of . The difference is not a disagreement about design: none of the documents above targets a deployment in which signing each record is unaffordable, an external service is forbidden by policy, and the verifier may not read what it verifies. A single agent action in one of those profiles may correspond to many PALA-1 records; conversely a PALA-1 chain head may be carried into that ecosystem as a signed statement. The layers are complementary, and the practical relation is the anchoring path of . Statement construction and binding. specifies how a Signed Statement declares the canonicalization applied to its payload, and leaves payload formats, serialization and structure out of scope. Its envelope conventions -- alg, kid or x5chain, and a content type in the protected header -- are the ones the statement of follows. defines a common model for relating Signed Statements to the objects they describe, including device instances. defines a COSE structure carrying a digest of a payload that the verifier obtains elsewhere. The statement of is a narrow instance of these concerns: its payload is a fixed-shape commitment to a chain head -- which is not a digest of a file but the result of the chain rules -- together with the range and format identifier a verifier needs to recompute it. It could be expressed under either binding document, or as a hash envelope over the head, without loss, and this document does not preclude that. Architectural requirements. states requirements for supporting AI agents on the Internet, among them that audit evidence be tamper-evident and support selective disclosure, and that protocols not require the collection of private reasoning traces as a condition of accountability. This format was designed before those requirements were written and satisfies the second by construction: chain verification inspects headers only and never requires a body to be disclosed. Time and existence. timestamp tokens and -style logs are alternative witnesses for the existence claim of . This document is deliberately indifferent to which is used; the witness record names a range and a witness, not a mechanism. Deployed tamper-evident logs. Two deployed mechanisms address the same broad problem and are the nearest prior art. Signed syslog has an originator periodically emit Signature Blocks that carry hashes of the messages it has sent and a signature over them, with the signer's key conveyed in Certificate Blocks; the cost of a signature is amortised over a group of messages, an idea this document shares through its checkpoint and witness records. It differs in what a verifier needs: checking a signed-syslog stream requires the signer's public key, whereas the integrity of a PALA-1 chain is checked with no key at all; and signed syslog is a mechanism for text messages in transit rather than a stored record format whose bodies can be erased without falsifying the record. The systemd journal's Forward Secure Sealing appends a message authentication tag at a fixed interval -- every fifteen minutes by default -- under a sealing key that evolves irreversibly, so that compromise of the current key does not permit undetected alteration of entries sealed earlier. That forward-security property is one a tier A PALA-1 trail does not have on its own; PALA-1 obtains the corresponding guarantee only from an anchor or witness held outside the device (). In the other direction, verifying a sealed journal requires a verification key from which every sealing key can be derived, so a party able to verify is also able to forge, which C3 excludes; entries written since the last seal are unprotected until the next one; and the journal provides neither selective disclosure nor erasure that leaves the record verifiable. Both mechanisms are reasonable choices where their assumptions hold. Neither is a substitute where C1 to C3 hold together. What is not addressed here. Selective disclosure at field granularity, agent identity, authorization, and cross-party attestation are all outside this document. Where a deployment needs them, the profiles above address them directly and this format is not a substitute.

Relationship to the agent auditing architecture This section is informative. describes an architecture for auditing agent-driven interactions in which each acting role records its own behaviour, records are linked by a propagated audit context, and attestation and transparency logging are composed as optional trust mechanisms. It proposes four record types -- Interaction, Action, Delegation and Authorization Transition Records -- and roles including an Auditing Service, an Audit Store, a Transparency Log and an Auditor. This section states where PALA-1 sits in that architecture and, as importantly, where it does not. What PALA-1 corresponds to. A PALA-1 trail written by an inference runtime records, at the runtime's dispatch boundary, the events that architecture assigns to Action Records: a tool call when it is handed to its executor, its result bound by digest to the call, and the explicit cancellation of a call that never returned (). Arguments and results enter the chain only as digests, which is the treatment that architecture's privacy considerations recommend for tool-call outputs. The container is an Audit Store substrate in that architecture's sense -- append-only, and readable by an Auditor without the runtime that produced it -- and the verification of is the Auditor's integrity check over it. The chain-head publication of is the composition with the Transparency Log, in the form that architecture already allows when it lets registration happen as soon as network conditions permit: a head published after the fact covers every record before it. Where it sits differently. That architecture's Action Records are produced where an action takes effect and, preferably, by the Tool or Service, reflecting a request as observed there rather than as reported by the agent. A PALA-1 trail of the kind described here is agent-side: it records what the runtime dispatched and what it received back. In that architecture's terms this is the co-located recorder of its role-aggregation discussion, with the recorder-collusion threat that discussion names. The mitigation it offers -- non-repudiable registration with a Transparency Service -- is the one provides, and under C2 that mitigation is deferred rather than absent. PALA-1 also does not sign records with an identity bound to the recorder: its integrity is the chain's, and signed statements exist only at a published head. What PALA-1 does not provide. Interaction Records -- user prompts, approvals and human-in-the-loop dialogue -- for which that architecture names as the principal candidate. Delegation Records and Authorization Transition Records. Propagation of an audit context across protocol interactions, and the actor and on-behalf-of identities that context carries. A per-record serialisation in CBOR/COSE or JSON/JWS: PALA-1 records are binary TLV () and enter a COSE-based ecosystem only at the chain head. Each of these is a non-goal of this document, not a gap it intends to close. How the two compose. A record in that architecture can reference a PALA-1 record by its record hash, or a window of them by a Merkle root, without carrying any PALA-1 body; and a PALA-1 chain head registered as a Signed Statement is an artifact a SCITT Transparency Log already accepts. The intended relation is a profile, not a competitor: PALA-1 as the local recorder of action events in deployments where an independent Auditing Service is not reachable at the moment of recording.

Implementation status This section records implementation experience per and is to be removed before publication as an RFC, should that occur. The wire format described here is frozen at version 1.0. Five implementations of it exist: the reference implementation; one written by a co-maintainer under a stated contamination boundary; and three by implementers who were external to the project at the time of their runs -- one has since become a maintainer -- and who worked from the specification text and the published test vectors alone . Each of the latter four reproduces the published expected values of the specification's test-vector section without access to any prior implementation. # Implementer Language Date Spec tested Result 1 reference (authors) Python -- -- the format's origin, not a verification run 2 O. Verteletskyi (co-maintainer, stated boundary) Python, stdlib 2026-08 776aa15a, ce877e4 chain + completeness reproduced; Merkle first blocked (leaves unpublished); 2 spec defects filed, closed; Merkle then reproduced 3 R. Bakaiev (external, unaffiliated) Python, stdlib 2026-08 c8e8247 8/9 blind; 1 divergence -- the verifier was right, the vectors were inconsistent; confirmed at 1294bd0, verifier unchanged 4 V. Kurdybailo (external, unaffiliated) Python, stdlib 2026-08 ff2720a 11/11 blind first run + 7/7 demos; own adversarial construction exposed a common-mode pseudocode/prose defect; fixed, vectors byte-identical 5 O. Turak (external and unaffiliated at the time of the run; a maintainer since) Perl 5, core only 2026-08 tag pala1-v1.0 11/11 + 7/7 first run; 13 own adversarial cases, 140 checks, 0 failures; 8 ambiguities logged; span-pairing gap reported; AES-GCM built from the primitive standards, NIST-tested first Run kind, stated in the vocabulary in current use for interoperability reporting: rows 2 through 5 are each an independent implementation from the text, checked against author-supplied vectors. None is an independent implementation with independent vectors, since the vectors are this project's; rows 4 and 5 additionally constructed their own adversarial inputs beyond the published set, and in row 4 that construction is what exposed the defect. The distinction is recorded here rather than left to be inferred. The fifth run is described in more detail because it is the one that changed the specification after the freeze. The gap concerned span pairing: the specification states that a crash must leave a visibly unclosed span, because that is the evidence, yet defines no pairing check anywhere -- so two conformant verifiers would differ on whether a user ever sees an unpaired span. The resolution deliberately did not make span pairing a verification verdict, since a trail truncated by a crash is incomplete without being falsified; it is surfaced as an advisory finding instead. The finding, the reasoning and the resolution are on the public record, as are the verifiers, run records and ambiguity logs of every run above. The reference implementation ships the published vectors inside its distribution package, so an installed build can be checked against them without network access. The cost claim of C1 has been measured rather than argued. An in-repository harness compares chain hashing with per-record COSE signing, and a second run of the same comparison, performed by a co-maintainer under a stated contamination boundary, agrees with it: with native primitives on a workstation, which is the case least favourable to the format, per-record signing costs between 45 and 61 times the header hash on the write path and between 116 and 168 times on the verify path . On the embedded targets of the ratio is larger. These are measurements of two implementations, not properties of the format, and are reported as such. The transparency path. The Signed Statement construction of has its own record, kept separately from the wire-format runs above because neither is evidence for the other . Two runs by a maintainer, each performed under a stated contamination boundary from the referenced standards and the published vector alone, and each with its own implementation of the CBOR and Ed25519 primitives, reproduced the statement byte-for-byte. The first run found that the protected header omitted the kid header parameter that Section 6 of requires when neither x5t nor x5chain is present, and that the subject truncated the chain head; the construction was corrected, the vector reissued, and the second run reproduced the corrected statement and independently re-derived the key thumbprint. The second run additionally established that the published tamper expectations had not exercised Ed25519 signature non-uniqueness (a scalar increased by the group order verifies unless the verifier enforces the range check of Section 5.1.7); the reference implementation's verifier was measured to enforce it, and the case is now an executable expectation. The construction carrying the root was added afterwards and published with its own vector; it has not yet been reproduced outside the project. Registration was then exercised end to end: a statement over the head of a chain written during a co-maintainer's session with the serving interface described below was registered with the SCITT API emulator published by the scitt-community project (scitt-api-emulator -- an emulator, not a production service), and the receipt was verified both by that emulator's own verifier and offline from the published artifacts alone. The run is reported with its scope: the emulator was operated by the authors on a local host for the duration of the run, under a single-use key, and its receipt structure is the emulator's own, predating . One finding resulted: the emulator expected the CWT-claims header under a draft-era label, whereas registered a different one; the statement was not altered to match, the emulator received a one-line correction whose diff is published with the run, and the matter is reported upstream. A registration with a transparency service operated by an unrelated party is the next class of evidence and is not claimed here. The reference implementation also serves an interface compatible with a widely deployed inference API, recording the tool-dispatch boundary of for any client of that interface. A measured limit of that recording is stated in the same record: when a client negotiates tool use with the model in free text and executes locally, no structured dispatch crosses the interface and nothing is recorded; the reference implementation reports this as a visibility limit and does not reconstruct dispatches from prose.

Security considerations Tamper-evidence applies to record bytes, not to the honesty of the recorder. This format makes alteration of a written trail detectable. It cannot establish that the runtime which wrote the trail reported truthfully at the moment of writing, and no format can: a dishonest producer with no external observer can construct an internally valid record of a fiction. Publication of a chain head to an external witness () bounds when such a trail can have been constructed and makes its later substitution or omission detectable; it does not make its content true. Every claim elsewhere in this document is bounded by this paragraph. The boundaries below are stated here rather than discovered later. It does not make the log true. The chain proves this is what the system recorded, unmodified. Not this is what happened. A hallucinated model output is preserved faithfully. It does not defend against the owner at tier A. Key and anchor are both theirs. Tier A is self-diagnostics. is the only mitigation, and it is partial. It does not bind to hardware. "This is the same device" needs tier B+. A digest without its frame proves nothing about content. Commitment defeats fabrication; it does not reconstruct. Cleartext headers are metadata, and metadata discloses. The span graph, origins and timing are readable without a key. That is the cost of , and it is not zero. It does not guarantee an action was logged before it happened. . The chain alone does not detect truncation. is not optional; without an anchor the last N records can be removed silently.

IANA considerations This document has no IANA actions.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. National Institute of Standards and Technology National Institute of Standards and Technology This document describes the format of a request sent to a Time Stamping Authority (TSA) and of the response that is returned. It also establishes several security-relevant requirements for TSA operation, with regards to processing requests to generate responses. [STANDARDS-TRACK] This document describes a mechanism to add origin authentication, message integrity, replay resistance, message sequencing, and detection of missing messages to the transmitted syslog messages. This specification is intended to be used in conjunction with the work defined in RFC 5424, "The Syslog Protocol". [STANDARDS-TRACK] This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. This document describes how to include CBOR Web Token (CWT) claims in the header parameters of any CBOR Object Signing and Encryption (COSE) structure. This functionality helps to facilitate applications that wish to make use of CWT claims in encrypted COSE structures and/or COSE structures featuring detached signatures, while having some of those claims be available before decryption and/or without inspecting the detached payload. Another use case is using CWT claims with payloads that are not CWT Claims Sets, including payloads that are not CBOR at all. This specification defines a method for computing a hash value over a CBOR Object Signing and Encryption (COSE) Key. It specifies which fields within the COSE Key structure are included in the cryptographic hash computation, the process for creating a canonical representation of these fields, and how to hash the resulting byte sequence. The resulting hash value, referred to as a "thumbprint", can be used to identify or select the corresponding key. CBOR Object Signing and Encryption (COSE) Receipts prove properties of a Verifiable Data Structure (VDS) to a verifier. VDSs and associated Proof Types enable security properties, such as minimal disclosure, transparency, and non-equivocation. Transparency helps maintain trust over time and has been applied to certificates, end-to-end encrypted messaging systems, and supply chain security. This specification enables concise transparency-oriented systems by building on Concise Binary Object Representation (CBOR) and COSE. The extensibility of the approach is demonstrated by providing CBOR encodings for Merkle inclusion and consistency proofs. Traceability in supply chains is a growing security concern. While Verifiable Data Structures (VDSs) have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility and interoperability between different transparency services as well as compliance with various auditing procedures and regulatory requirements. This document defines new CBOR Object Signing and Encryption (COSE) header parameters for signaling a payload as an output of a hash function. This mechanism enables faster validation, as access to the original payload is not required for signature validation. Additionally, hints of the hashed payload's content format and availability are defined, providing references to optional discovery mechanisms that can help to find the original payload content. Samsung Electronics Opaque Autonomous AI agents are evolving from interactive assistants into networked software workloads that discover services, invoke tools, delegate authority, transact, communicate with other agents, and act asynchronously on behalf of humans and organizations. Existing Internet protocols provide strong foundations, but agent autonomy, dynamic delegation, machine-speed execution, long and unpredictable model-processing intervals, and cross-domain interaction create requirements that span multiple protocol families. This document describes architectural requirements for supporting AI agents on the Internet across naming and discovery, HTTP, authentication, authorization and delegation, TLS and workload identity, transport and connection continuity, asynchronous messaging, capability and intent-based resolution, payments, provenance, auditability, revocation, security, and privacy. It favors profiling and extending existing Internet protocols over defining a monolithic new agent protocol, and identifies the need for IETF-wide architectural coordination. Action State Group, Inc. This document defines a SCITT statement profile for recording what an AI agent did: the Agent Action Capsule. A Capsule is a digest- committed record of one agent action carrying its verdict-level disposition (executed, blocked, denied, errored, timed out), the deterministic constraints that were evaluated, the effect that was committed together with a confirmed-effect binding that distinguishes a dispatched attempt from an observed result, and an honest human-in- the-loop flag. Capsules are identified independently of signing and MAY be authenticated by one or more COSE_Sign1 Producer Envelopes. Its Capsule ID can separately be made transparent by registration in a SCITT Transparency Service [I-D.ietf-scitt-scrapi]. A Capsule is recorded on every verdict, including refusals: a blocked or denied Capsule is the auditor-grade evidence that a gate worked. Keel API, Inc. This document specifies a SCITT (Supply Chain Integrity, Transparency, and Trust) profile for pre-execution authorization records of AI agent actions. The profile defines a Signed Statement type, the "Pre-Execution Authorization Record" (also called a Permit), that records a policy-evaluated decision to allow, deny, or challenge an AI agent action before that action is dispatched to a model provider, tool, or service. The profile cryptographically binds the authorization decision to the canonical bytes of the request that is authorized. When the paired Closure Record carries a dispatch digest, a Verifier can compare the authorized-request digest against the recorded dispatched-request digest; on the managed dispatch path the reference implementation additionally enforces this equality before the request is sent. This revision also introduces authorization-lineage vocabulary. It defines how a Verifier can determine whether the authority conveyed by a child Permit is equal to or narrower than the authority conveyed by its parent (attenuation), given a signed or chain-committed Authority Representation and a declared Comparator Profile. The Permit remains an evidence artifact; this profile specifies the evidence a Verifier needs to make that determination, not a delegation or policy protocol. The profile composes with adjacent profiles for human-authority binding, post-execution material-action evidence, and content-refusal events, referenced rather than replicated. Veridic Inc. Veridic Inc. This document defines a SCITT (Supply Chain Integrity, Transparency, and Trust) profile for creating independently verifiable, tamper- evident records of autonomous AI agent actions. The profile defines the AgentInteractionRecord (AIR) as the COSE_Sign1 signed statement payload for material agent actions; maps SCITT roles to the agent execution context, with the Agent Operator as Issuer and an independent Evidence Custodian as Transparency Service; specifies Registration Policy requirements including hash chain integrity, temporal ordering, and sequence completeness; defines a redaction receipt mechanism for privacy-preserving evidence custody; and provides compliance mappings to EU AI Act Articles 12 and 19, DORA, NIST AI RMF, MAS AI Risk Management Guidelines, PCI DSS, and MiFID II. VeritasChain Standards Organization Automated decision-making systems, including AI and algorithmic systems in critical infrastructure, currently lack standardized mechanisms for producing evidentiary-grade provenance records that can withstand independent verification. Traditional logging approaches fail to provide the cryptographic guarantees required for regulatory compliance, forensic investigation, and cross- organizational accountability. This document describes the Verifiable AI Provenance Framework (VAP), an architectural framework that defines requirements for producing verifiable decision trails using existing IETF security technologies. VAP does not define new protocols or cryptographic primitives; rather, it provides an architectural coordination layer that enables domain-specific profiles to leverage Supply Chain Integrity, Transparency and Trust (SCITT), Remote Attestation Procedures (RATS), CBOR Object Signing and Encryption (COSE), and related IETF work in a consistent manner. This document is intended to frame the problem space and facilitate discussion about whether architectural coordination work is needed in this area. LedgerProof Foundation This document defines a Supply Chain Integrity, Transparency, and Trust (SCITT) profile for machine-readable cryptographic transparency receipts addressing all four sub-obligations of Article 50 of Regulation (EU) 2024/1689 (the "EU AI Act"): interactive AI system disclosure (50(1)), machine-readable marking of synthetic media (50(2)), emotion recognition notification (50(3), referenced for completeness), and AI-generated text disclosure with human editorial review exemption (50(4)). The profile defines three SCITT statement content types ("ai/article-50/v1", "ai/human-review/v1", and "ai/chatbot-session/v1") and specifies validation, verification, and chain-of-custody semantics suitable for presentation to European Union supervisory authorities, national competent authorities, and judicial proceedings. The profile is substrate-agnostic but presumes a SCITT Transparency Service backed by a publicly verifiable append-only log. A reference implementation using the Bitcoin blockchain as the SCITT log substrate, via RFC 6962 Merkle aggregation anchored in OP_RETURN transactions, is described in companion document draft-dawkins-scitt-lpr-00. MyAuberge K.K. This document specifies the Governance Audit Record (GAR), the audit architecture for agentic AI systems. GAR defines five audit types, the Session Audit Record (SAR), the Audit Alert system, auditor principal categories, and the Audit Package for external regulatory inspection. GAR provides verifiable evidence that AI agent sessions were governed in accordance with the Intent Declaration Primitive and the Human Escalation Mechanism. GAR answers the governance question: can any of this be proven to a regulator? GAR is a domain-specific application of the SCITT (Supply Chain Integrity, Transparency and Trust) architecture extended with causal ordering semantics for agentic governance events. GAR defines the Authority Lifecycle Event (ALE) category: a normative set of causally-ordered event types covering the complete agent session revocation and recovery lifecycle, including single-agent revocation, authority suspension, partial state recording, recovery initiation, credential restoration, and multi-agent delegation tree events. Version -03 adds the SOOS Governance Semantic Convention: the normative soos.governance.* OpenTelemetry attribute namespace for governance observability, the SOOS GAR Processor specification for OTel-to-SAR pipeline construction with Session Block Merkle integrity, four new Authority Lifecycle Events, three mandatory provenance fields on Cedar evaluation records, and the XPID mirror field on ACD session ALEs. Version -04 made the Session Block construction rules more explicit, closing three ambiguities found during independent interop verification at the IETF 126 Hackathon. Version -05 supersedes -04's Session Block construction text with a corrected construction: the Merkle leaf and internal-node hashes are now domain-separated (RFC 9162's Merkle Tree Hash, with 0x00/0x01 prefix octets) and odd-length levels use RFC 9162's k-split recursive tree shape rather than duplicate-node padding, closing a malleability class structurally equivalent to CVE-2012-2459 that was present in -04's construction. This revision is fully self-contained: unlike -03 and -04, it does not carry forward unreproduced text from an earlier version. Version -05 also adds a subject_digest field to Cedar-evaluation GAR records, the same construction used by the Agent Accountability Composition as its cross-slot join key, positioning GAR as a conforming AEP instance under the RATS-bound composition; the field is normatively scoped to prohibit independent re- serialization where an upstream party has already established the action's canonical serialization, per the failure mode documented in the SCITT typed-reference specification. Version -06 closes gaps surfaced by a WIMSE-style security review pass against -05's own text and reference sample code: a JWKS trust- anchor bootstrap requirement, a corrected key-compromise remediation procedure that no longer requires re-signing already-committed audit artifacts, an explicit Level 1/2 residual-risk disclosure for a compromised-but-signing GEC, a defined failure path for KIA signer quorum failure at Session Block close, referential-integrity enforcement for causal_parent_id, and guidance against alert-fatigue false positives in session_sequence_number gap detection. This revision also carries an idnits repair pass covering reference classification, citation hygiene, and formatting. Version -08 is an editorial revision with no normative content changes: nine sibling-draft citations had gone stale against those drafts' current live versions and are updated to draft-sato-soos-idp-06, draft-sato-soos-hem-07, draft-sato-soos-cap-06, draft-sato-soos-sov-03, draft-sato-soos-mjwt-06, draft-sato-soos-mad-05, draft-sato-soos-kia-06, draft-sato-soos-cap-rrs-04, and draft-sato-soos-acd-02 respectively. Action State Group, Inc. Tyche Institute Independently written systems that anchor records to a SCITT Transparency Service repeatedly need the same construction: a canonical form of structured content, a content-addressed identifier derived from that form, binding to a SCITT Signed Statement and Receipt, and references that cite external artifacts by digest. This document, referred to as CPB, specifies that construction as declarations rather than as a payload format. A payload profile declares its canonicalization algorithm and exclusion set and thereby obtains a reproducible derived identifier. A CPB Signed Statement carries either the complete statement content as specified by RFC 9943 or a digest of content held elsewhere using the COSE Hash Envelope of RFC 9995. CPB also defines an abstract typed digest reference information model and one optional protected-header encoding, cpb-refs; a payload profile may instead define its own reference serialization. An IANA registry assigns the canonicalization algorithm identifiers that these declarations name. CPB does not define payload content formats, establish or require a universal artifact-type registry, or require either typed-reference carrier. The Graduate University for Advanced Studies (SOKENDAI) This document defines a small common model for relating Supply Chain Integrity, Transparency, and Trust (SCITT) Signed Statements to the supply-chain objects that those statements describe, measure, authorize, revoke, or audit. The model can be used for software artifacts, firmware artifacts, hardware components, device instances, cloud compute resources, and other objects that appear in supply- chain evidence. The document also defines a relationship vocabulary and an optional Statement Graph Manifest. These parts help verifiers connect heterogeneous SCITT statements without requiring SCITT to define the payload formats of those statements. This document does not define SBOM, HBOM, CBOM, attestation, audit, vulnerability, or regulatory payload formats. It only defines a common binding and graph layer around SCITT statements and receipts. This document defines a record format for AI agent authorization decisions and the effects that followed them. The format is one in- toto predicate type, signed inside a DSSE envelope. A record carries the decision and the observed effect with a derived agreement between them, whether the decision point could evaluate the request and how fresh each input it relied on was, and a canonicalization contract under which a party that trusts neither the agent nor its operator recomputes the record's consistency from its bytes. The document also defines what a party that retains a record keeps beside it, so that the record can later be dated from anchors that party does not control. The format carries the seven minimum audit fields of the WIMSE AI Identity Management System framework, and it is offered as a data model for the audit records the proposed AUDIT working group would specify. It defines no policy. Ericsson Fraunhofer SIT This document describes an architecture for auditing of agent-driven interactions on the Internet. Autonomous and semi-autonomous software agents, including those based on artificial intelligence, increasingly act on behalf of users, organizations, and services. Existing auditing mechanisms often capture isolated system events but do not consistently represent delegation relationships, user intent, or evolving authorization. In agent-driven systems, auditability requires linking intent, delegation, authorization, and execution. The proposed architecture enables this through distributed audit record generation, propagation of audit context, optional attestation, and additional logging for transparency. Autonomous agents based on large language models increasingly perform consequential tasks on behalf of humans and other agents. Demonstrating that recorded agent behavior truthfully represents actual behavior is essential for accountability, compliance, and human oversight. This document defines a data format for verifiable agent conversation records using CDDL, with representations in both JSON and CBOR. The format captures session metadata, message exchanges, tool invocations, reasoning traces, and system events in a structured, extensible CDDL definition for verifiable agent conversation records. COSE is used as the signing method to allow for native interoperability in SCITT Transparency Services and the CDDL definition allows for seemless integration in Evidence as specified in RFC 9334. The specification supports cross-vendor interoperability by defining a common representation that accommodates translation from multiple existing agent implementations with distinct data structure layouts that are typically represented in JSON. The systemd project

Acknowledgments The specification was hardened by its independent verifiers, whose findings were resolved on the public record before this document existed, and the transparency path was hardened in the same way by the runs recorded in . The authors thank every external contributor to that effort, the maintainers of the scitt-community reference implementation, and the SCITT and COSE working groups, whose published work this document refers to and builds no claim upon.

Changes from draft-sparysh-pala-audit-01 This section is to be removed before publication as an RFC. : the key identifier is described correctly, as the COSE Key Thumbprint of the verification key. -00 and -01 described it as truncated to its first 20 bytes; no published statement was ever constructed that way, and the paragraph built on that description is removed. : the statement payload carries the root over the record hashes of records 0 through the last covered, so that two registered statements of one chain are connected by a consistency proof without the chain. Why the subject names the full head is restated in terms of the supersession rule of . : a companion vector with two root-carrying statements and the proof between their roots; the table of the vector chain's records is rendered as a table (in -01 it rendered as running text). Related work: . Authors' addresses carry the project page.

Changes from draft-sparysh-pala-audit-00 This section is to be removed before publication as an RFC. Literal blocks now use kramdown's native fence. In the -00 rendering seven blocks, including the verification procedure of , had been flattened into running text. No normative content changed. References: corrected an empty co-author entry and missing publication months introduced by the -00 build. Related work: added signed syslog and the systemd journal's Forward Secure Sealing; the description of follows its -05 reframing as a canonicalization declaration. Added , the relationship to the agent auditing architecture. The expansion of the name PALA is stated.

Contributors

olexii.turak@gmail.com

Produced the fifth implementation of the frozen wire format, in Perl 5, working from the specification text and published vectors alone under the project's stated contamination boundary, and surfaced a specification-completeness gap in span pairing that was resolved on the public record before this document existed. Later, as a maintainer, reproduced the SCITT-bridge Signed Statement byte-for-byte from the referenced standards in two further runs, the first of which identified a conformance defect against RFC 9943 that was corrected on the record.