PALA-1: A Tamper-Evident Audit Record Format for Constrained and Disconnected Deployments

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 7 March 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

Table of Contents

1. 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 [RFC9943]. Where that construction is available it answers questions this format cannot answer alone, and this document describes how to reach it (Section 8).¶

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

2. Record layout

A record is header || body. The body may be empty.¶

3. Record types

4. 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 (Section 12).¶

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 (Section 12). A trail's silence about tool use is evidence of what the emitter observed, not of what the client did.¶

5. Chain rules

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

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 (Section 9.1): 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.¶

7. Assurance tiers

The format states how much it can be trusted. It does not overstate.¶

Tier C is deliberately not a header value.¶

Tier C -- periodic publication of the chain head to a transparency log or an [RFC3161] 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.¶

8. 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 [RFC9943] 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 [RFC9052] whose payload commits to the head by digest -- registers it with a transparency service, and attaches the returned Receipt -- a COSE Receipt [RFC9942] -- to the statement's unprotected header, producing what [RFC9943] 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 (Section 1.3), which is what makes it affordable under C1.¶

The construction published with the specification [PALA-INTEROP] 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 [RFC9597].¶

Two of those values are digests, and they are treated differently on purpose. The subject names the full chain head: a transparency service indexes by the subject, distinct chains must not collide under it, and a truncated digest collides at the birthday bound of whatever length is kept. The key identifier is the COSE Key Thumbprint of the verification key [RFC9679] truncated to its first 20 bytes, which is not a thumbprint and is not claimed to be one. The asymmetry is deliberate: kid is a hint for locating a key and [RFC9052] places no collision-resistance duty on it, since presenting the wrong key simply fails the signature check, whereas the subject is the identifier by which a relying party decides that two statements concern the same thing, and nothing downstream catches a collision there. Truncation is acceptable exactly where a collision is self-correcting and unacceptable where it is not. The payload is attached -- a CBOR map of the head, the sequence range and the format identifier, encoded as CBOR [RFC8949] -- so that the statement is readable offline, without the service. Section 6 of [RFC9943] 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 (Section 12).¶

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 [RFC8032] 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. [PALA-INTEROP] 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.¶

9. Verification

Verification answers three questions, and they MUST NOT be collapsed into one boolean. Each needs different inputs and each fails differently.¶

A verifier that reports only Section 9.1 as "ok" is misleading, because Section 9.1 cannot see a truncated tail: dropping the last N records leaves a perfectly linked chain with a different head and no other trace.¶

10. Test vectors

The full set -- every record byte, the Merkle leaves and the inclusion proof -- is published as [PALA-VECTORS]. 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 (Section 3.4). 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.¶

key = 000...02a (32 bytes) key_id = 7 nonce = 4 zero bytes || seq (u64 LE) seq 3 -> 000000000300000000000000 body plaintext (seq 3) = "clear path ahead, one pedestrian at 12m, static" ¶

Expected results -- an implementation that disagrees with any of these is wrong, or this specification is:¶

``` chain_head = 3a1a3673f50498eb1d1c6f94b983d6c606cd85ed53627b4e4ffe55153c7af813 chain_ok = true record_count = 12 breaks = [] gaps = [] violations = [] complete_to_anchor = true (the anchor is the store's current head = the tip) anchor_head = 3a1a3673f50498eb1d1c6f94b983d6c606cd85ed53627b4e4ffe55153c7af813 (== chain_head)¶

merkle_tree_hash = 518f5be5173250f705e3bda029ec1c11ac5c4459115c07dde5bc1021d9f468db merkle_leaf_count = 30 proof(index 7) verifies proof_len = 5 ```¶

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

A companion vector [PALA-INTEROP] publishes a Signed Statement over this chain head in the construction of Section 8: 331 bytes, EdDSA under the published test key of [RFC8032] Section 7.1, with the expected bytes, digest, key identifier and a set of tamper expectations that includes the byte-stability cases stated there. The vector was reissued once, after a reproduction performed under a stated contamination boundary found the conformance defect described in Section 12; both versions and their digests are on the record.¶

11. 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. [RFC9943] 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 Section 8, 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. [I-D.mih-scitt-agent-action-capsule] 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. [I-D.munoz-scitt-permit-profile] records pre-execution authorization -- whether an action was permitted, rather than what occurred. [I-D.emirdag-scitt-ai-agent-execution] defines operator-signed interaction records with redaction receipts. [I-D.kamimura-vap-framework] frames hash chaining, signatures and anchoring as a conformance-tiered provenance architecture. [I-D.dawkins-scitt-ai-article50] profiles receipts for a specific regulatory transparency obligation. [I-D.sato-soos-gar] records session-level governance audit records produced by an enforcing component.¶

These are per-action or per-session statement profiles, expressed in JSON or CBOR, made transparent by registration with a service. This document specifies a wire format for a continuously appended local trail, verifiable without a service and without a key, under the constraints of Section 1.1. 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 Section 8.¶

Statement construction and binding. [I-D.mih-sokolov-scitt-payload-binding] extracts, as a reusable profile, the construction that systems anchoring structured records to a transparency service repeatedly re-derive: a canonical payload form, a content-derived identifier, receipt binding in the unprotected header, and typed digest references between records. Its envelope conventions -- alg, kid or x5chain, and a content type in the protected header -- are the ones the statement of Section 8 follows. [I-D.nobuo-scitt-protected-object-binding] defines a common model for relating Signed Statements to the objects they describe, including device instances. [RFC9995] defines a COSE structure carrying a digest of a payload that the verifier obtains elsewhere. The statement of Section 8 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. [I-D.daniel-ai-agent-internet-architecture] 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. [RFC3161] timestamp tokens and [RFC6962]-style logs are alternative witnesses for the existence claim of Section 8. This document is deliberately indifferent to which is used; the witness record names a range and a witness, not a mechanism.¶

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

12. Implementation status

This section records implementation experience per [RFC7942] 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 [PALA-VECTORS]. Each of the latter four reproduces the published expected values of the specification's test-vector section without access to any prior implementation.¶

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 [PALA-COST]. On the embedded targets of Section 1.1 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 Section 8 has its own record, kept separately from the wire-format runs above because neither is evidence for the other [PALA-INTEROP]. 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 [RFC9943] 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 [RFC8032] Section 5.1.7); the reference implementation's verifier was measured to enforce it, and the case is now an executable expectation.¶

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 [RFC9942]. One finding resulted: the emulator expected the CWT-claims header under a draft-era label, whereas [RFC9597] 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 Section 4 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.¶

13. 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 (Section 8) 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.¶

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

2. It does not defend against the owner at tier A. Key and anchor are both theirs. Tier A is self-diagnostics. Section 7 is the only mitigation, and it is partial.¶

3. It does not bind to hardware. "This is the same device" needs tier B+.¶

4. A digest without its frame proves nothing about content. Commitment defeats fabrication; it does not reconstruct.¶

5. Cleartext headers are metadata, and metadata discloses. The span graph, origins and timing are readable without a key. That is the cost of Section 1.1, and it is not zero.¶

6. It does not guarantee an action was logged before it happened. Section 3.1.¶

7. The chain alone does not detect truncation. Section 9.2 is not optional; without an anchor the last N records can be removed silently.¶

14. IANA considerations

This document has no IANA actions.¶

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

Contributors

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

Authors' Addresses