Network Working Group L.J. Reilly Internet-Draft REM Technologies & Consulting, LLC Intended status: Informational 24 August 2026 Expires: 25 February 2027 Reilly Sentinel Protocol (RSP): Blockchain-Anchored Integrity for AI Datasets, Training, Fine-Tuning, and Inference Provenance draft-reilly-sentinel-protocol-02 Abstract The Reilly Sentinel Protocol (RSP) specifies an interoperable, multi-layer method for establishing integrity, provenance, and auditability across the artificial intelligence (AI) lifecycle. RSP defines a Sentinel Evidence Package (SEP) that binds payload digests, provenance metadata, signatures, blockchain timestamp proofs, and resolvable identifiers. This enables tamper-evident, independently verifiable receipts for datasets, data transformations, training jobs, checkpoints, fine-tuning runs, evaluations, inference outputs, and agentic AI action logs. This revision (-02) supersedes draft-reilly-sentinel-protocol-01 and corrects defects in it. The cross-chain binding hash of -01 was computed under SHA3-512 alone over an unframed concatenation of hex strings, which made a single algorithm the point of failure for a construction whose stated purpose was to survive the failure of any single algorithm, and which admitted field-boundary ambiguity. It is replaced by an entangled link construction over a fixed-length framed input, with a concatenated braid that privileges no algorithm. The post-quantum analysis of -01 applied Grover's algorithm to collision resistance, a property Grover does not meaningfully reduce, and stated SHA-256's collision resistance as 256 bits when it is 128 bits classically. The claim that combining three hash functions requires an adversary to break all three is replaced, following [JOUX], by a hedging claim. Merkle tree construction, left unspecified in -01 while relied upon by three separate extensions, is now normatively specified per [RFC6962]. Digest-only selective disclosure is replaced by salted commitments. Automated repair of chain integrity violations is prohibited. RSP is transport-agnostic and serializable in JSON and CBOR. It leverages existing IETF building blocks including COSE signatures, CBOR, CDDL, JSON, and NTS-secured time. Anchoring is done via append-only blockchain receipts and identity is stabilized with persistent identifiers. 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 25 February 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Defects Corrected in This Revision . . . . . . . . . . 5 1.2. Implementation Status . . . . . . . . . . . . . . . . . 9 2. Conventions and Terminology . . . . . . . . . . . . . . . . 10 3. Architecture and Roles . . . . . . . . . . . . . . . . . . 13 4. Sentinel Evidence Package (SEP) Data Model . . . . . . . . 16 5. Multi-Algorithm Hash Architecture . . . . . . . . . . . . . 21 5.1. Which Property Binds a Provenance Record . . . . . . . 21 5.2. Corrected Security Figures . . . . . . . . . . . . . . 22 5.3. Hedging, Not Addition . . . . . . . . . . . . . . . . . 24 5.4. Corrected Post-Quantum Statement . . . . . . . . . . . 25 5.5. Digest Computation . . . . . . . . . . . . . . . . . . 27 6. Chain Construction and Composite Proof Objects . . . . . . 29 6.1. The Defect in -01 . . . . . . . . . . . . . . . . . . . 29 6.2. Context Commitment and Record Commitment . . . . . . . 31 6.3. Link Construction and Entanglement . . . . . . . . . . 33 6.4. The Braid . . . . . . . . . . . . . . . . . . . . . . . 34 6.5. Composite Proof Object, Version 2.0 . . . . . . . . . . 35 6.6. What Is Anchored . . . . . . . . . . . . . . . . . . . 37 6.7. Migration from CPO 1.0 . . . . . . . . . . . . . . . . 39 7. Merkle Tree Construction . . . . . . . . . . . . . . . . . 40 8. Serialization and Media Types . . . . . . . . . . . . . . . 43 9. Anchoring and Proofs . . . . . . . . . . . . . . . . . . . 44 10. Persistent Identifier Registration . . . . . . . . . . . . 48 11. REM Protocol Integration . . . . . . . . . . . . . . . . . 50 12. Protocol Operations . . . . . . . . . . . . . . . . . . . . 53 13. Verification Algorithm . . . . . . . . . . . . . . . . . . 55 14. Agentic AI Provenance Extensions . . . . . . . . . . . . . 59 15. Streaming Inference Provenance . . . . . . . . . . . . . . 63 16. Federated Learning Provenance . . . . . . . . . . . . . . . 66 17. Revocation . . . . . . . . . . . . . . . . . . . . . . . . 70 18. Conformance Framework . . . . . . . . . . . . . . . . . . . 73 19. Error Handling . . . . . . . . . . . . . . . . . . . . . . 76 20. Manageability and Telemetry . . . . . . . . . . . . . . . . 78 21. Privacy Considerations . . . . . . . . . . . . . . . . . . 79 22. Security Considerations . . . . . . . . . . . . . . . . . . 82 23. IANA Considerations . . . . . . . . . . . . . . . . . . . . 89 24. Implementation Status . . . . . . . . . . . . . . . . . . . 93 25. References . . . . . . . . . . . . . . . . . . . . . . . . 95 Appendix A. CDDL for CBOR SEP (v1.2) . . . . . . . . . . . . 101 Appendix B. Example JSON SEP . . . . . . . . . . . . . . . . 105 Appendix C. Verification Report . . . . . . . . . . . . . . 107 Appendix D. Anchoring Notes . . . . . . . . . . . . . . . . 109 Appendix E. Persistent Identifier Metadata Mapping . . . . . 110 Appendix F. CPO 2.0 Format . . . . . . . . . . . . . . . . . 111 Appendix G. Agentic Action Log Example . . . . . . . . . . . 113 Appendix H. Change Log . . . . . . . . . . . . . . . . . . . 115 Appendix I. Chain Test Vectors . . . . . . . . . . . . . . . 120 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 123 Author's Address . . . . . . . . . . . . . . . . . . . . . . 123 1. Introduction Artificial Intelligence (AI) systems are increasingly deployed in high-stakes contexts including defense, healthcare, finance, critical infrastructure, and autonomous systems. Confidence in AI outcomes depends on the ability to demonstrate where data originated, how models were trained or adapted, when inferences were produced, by which agents actions were taken, and whether any of these artifacts have been altered after the fact. Agentic AI systems, which execute multi-step tasks, invoke tools, and produce outputs without direct human supervision per step, introduce provenance requirements beyond static artifact integrity. An agentic system may perform thousands of actions per session, each of which may affect downstream artifacts, decisions, and liability. RSP defines a minimal yet extensible evidence container, the Sentinel Evidence Package (SEP), together with a multi-algorithm chain construction and a verification process that any independent party can execute without trusting the producer's infrastructure. RSP is content- and model-agnostic: it does not dictate model architecture or task; it standardizes how integrity, time, identity, and lineage are recorded and verified. RSP combines three complementary layers: * Multi-algorithm digests and chaining: SHA-256, SHA3-512, and BLAKE3 computed simultaneously and bound by the entangled link construction of Section 6. * Blockchain anchoring: append-only proof of existence, with the pending and attested states distinguished per Section 9. * Persistent identifier registration: globally resolvable, citable identifiers with metadata, lineage, and retention semantics. The REM Protocol [REM02] provides the permanence infrastructure on which RSP anchoring operations are built in the reference deployment. RSP does not require REM; Section 11 describes the integration where it is used. 1.1. Defects Corrected in This Revision Revision -01 introduced a multi-algorithm architecture whose central claim was that an adversary would have to defeat three structurally distinct hash functions. The architecture did not deliver that property as constructed, and the supporting security analysis contained errors. This section states them. A reader who has implemented -01 should read Section 6.7 before doing anything else. 1.1.1. The Cross-Chain Binding Did Not Bind Section 6.2 of -01 specified: cross_chain_hash = SHA3-512( sha256_chain_hash || sha3_512_chain_hash || blake3_chain_hash ) and asserted in Section 6.2 and Section 20.3 that forging it "requires simultaneously breaking SHA-256, SHA3-512, and BLAKE3". It does not. The binding value is the output of SHA3-512 and of nothing else. An adversary with a SHA3-512 collision can produce a second preimage triple yielding the recorded cross_chain_hash, irrespective of the state of the SHA-256 and BLAKE3 chains it purports to commit to. Far from requiring three breaks, the construction reduced the security of the whole composite to that of one member. This mattered more than it might have, because Section 8 of -01 required the orchestrator to anchor the cross-chain binding hash, and Appendix D recommended that OTS receipts cover that value "rather than individual algorithm hashes". The consequence was that the only value committed to a blockchain was a SHA3-512 output. If SHA3-512 fell, nothing anchored would independently attest the SHA-256 or BLAKE3 chain states, and the algorithmic diversity the architecture existed to provide would be unavailable at precisely the moment it was needed. A second, independent flaw is that the three chain hashes were concatenated without length framing. In the CPO format of Appendix F they are hex strings of differing lengths. Distinct field triples therefore produce identical concatenations: a 64/128/64 split and a 60/128/68 split of the same 256-character string are different chain states with the same binding hash. The construction was ambiguous even against an adversary with no cryptanalytic capability at all. Section 6 replaces this in full. Each record now carries three link values computed over one common, fixed-length, domain- separated input, and the value a successor commits to is the concatenation of the three links rather than a hash of them, so that no algorithm is a single point of failure for the entanglement. 1.1.2. Grover Applied to Collision Resistance Section 1 of -01 stated that SHA-256 "is vulnerable to Grover's algorithm which reduces its effective security from 256 bits to approximately 128 bits", and Section 5.1 stated that Grover "reduces SHA-256's effective collision resistance from 256 bits to approximately 128 bits". Section 5.3 then reported "Classical security: 256-bit effective strength (SHA-256)". These are wrong in two compounding ways. SHA-256's collision resistance is approximately 128 bits classically, by the birthday bound; it was never 256. The 256-bit figure is preimage resistance. And Grover's algorithm [GROVER] attacks preimages, not collisions: it halves preimage resistance and does not deliver a comparable reduction against collisions, where the best known quantum algorithms offer at most a modest asymptotic gain at prohibitive memory cost and the classical birthday bound remains operative under realistic cost models. Section 5.1 of -01 further claimed that "a quantum adversary cannot apply Grover's algorithm to SHA-3 with the same efficiency as SHA-2". Grover is a generic search algorithm and applies identically to any hash function treated as a black box. SHA3-512's advantage over SHA-256 is its output length, not any resistance to Grover. Section 5 states the corrected position. The correction is not unfavorable: the property that binds a provenance record is collision resistance, and collision resistance is the property quantum computation leaves substantially intact. 1.1.3. Combined Security Claimed as Conjunctive Sections 5.3 and 20.3 of -01 asserted that an adversary "must simultaneously break SHA-256, SHA3-512, AND BLAKE3" and that "no known classical or quantum algorithm achieves this". [JOUX] showed that multicollisions in an iterated hash can be found at cost only modestly above a single collision, with the consequence that the collision resistance of a concatenation is bounded near that of its strongest member rather than their sum. SHA-256 is an iterated Merkle-Damgard construction and is subject to this result directly. Section 5.3 states the corrected claim: the combination provides hedging, not addition. Its collision resistance is approximately that of SHA3-512, and the contribution of the other two functions is insurance against a break confined to one construction. 1.1.4. Merkle Construction Left Unspecified Revision -01 relied on Merkle trees in four places: roll-up anchoring (Section 8), the Agentic Action Log merkle_root (Section 13.2), the streaming inference rolling tree (Section 14.2), and the federated update_root (Section 15.2). It never specified the construction: no leaf or interior domain separation, no rule for odd cardinality, no leaf ordering, and no proof format. Two implementations of -01 could therefore compute different roots over identical data and each be conformant. Worse, a construction without domain separation admits second-preimage attacks in which an interior node is presented as a leaf, and one that duplicates the final node on odd cardinality admits distinct leaf multisets with identical roots. Section 7 specifies the [RFC6962] construction normatively for all four uses. 1.1.5. Digest-Only Disclosure Is Not Selective Disclosure Section 13.4 of -01 stated that because agentic action inputs and outputs are recorded as digests, "a party may prove that a specific action occurred without revealing the content of inputs or outputs". Section 19 made a parallel claim resting on the preimage resistance of SHA3-512. Preimage resistance protects against inverting a digest of a high-entropy input. Action inputs are frequently low-entropy: tool identifiers, short commands, boolean decisions, enumerated branches. An adversary holding the digest enumerates the plausible candidates and hashes them. Preimage resistance is irrelevant to that attack, which is a guessing attack, and the number of guesses is small. Section 14.4 replaces digest-only recording with salted commitments, aligning RSP with the construction used elsewhere in this suite. 1.1.6. Self-Healing Applied to Integrity Violations Section 10.3 of -01 stated that "Agent 11 performs autonomous self-healing repair cycles that detect and flag chain integrity violations". Automated repair is appropriate for availability faults and is never appropriate for integrity violations. A chain integrity violation is either evidence of tampering or evidence that the implementation is defective. In both cases the correct response is to preserve the violation, escalate it, and stop, because an automated process that restores a chain to a consistent state destroys the only evidence that it was ever inconsistent, and it does so in exactly the circumstances an adversary would wish. Section 11.3 prohibits automated repair of integrity violations under any autonomy setting. 1.1.7. Other Corrections Further corrections are listed in Appendix H, including the omitted Code Components paragraph in the Copyright Notice (which -01 required, since it contains CDDL), an incorrect "Independent Submission" stream designation, contradictions between the conformance levels of Section 16 and the CDDL of Appendix A, incomplete media type registration templates, the self-asserted quantum_resilient boolean, an underspecified revocation mechanism, overstated privacy claims for federated learning, and the migration of the implementation endpoints. 1.2. Implementation Status See Section 24. Implementers should note in particular that the corrected chain construction of Section 6 is specified in advance of a conformant implementation, and that the deployed infrastructure described in Section 24 currently implements the CPO 1.0 format that Section 6.1 identifies as defective. Section 6.7 describes migration. 2. Conventions and Terminology 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The symbol || denotes octet string concatenation. uint64be(n) and uint32be(n) denote big-endian fixed-width encodings. lp(s) denotes the length-prefixed encoding of a UTF-8 string s, being uint32be(octet length of s) || UTF-8(s). Hex encoding is lowercase throughout. AAL: Agentic Action Log; a structured record of autonomous agent actions, tool invocations, and decision events. Algorithm Suite: The declared set of hash algorithms in force for a SEP or chain, replacing the quantum_resilient boolean of -01. See Section 4. Anchor, attested: A blockchain timestamp proof that has been upgraded to include a block-level attestation and from which a block height can be read. See Section 9. Anchor, pending: A timestamp proof carrying only a calendar server's undertaking to commit a digest in a future transaction. A pending anchor conveys no proof-of-work. Artifact: Any AI lifecycle asset: dataset, data transform, training configuration, training log, model checkpoint, fine-tuning diff, evaluation artifact, inference record, or agentic action log. Braid: The 128-octet concatenation of a record's three link values in the fixed order SHA-256, SHA3-512, BLAKE3. The braid is the value a successor record commits to. See Section 6.4. Commitment: A salted cryptographic commitment to a value, permitting that value to be disclosed and verified in isolation. See Section 14.4. CPO: Composite Proof Object; the structure carrying a record's chain state. Version 2.0 is defined in Section 6.5; version 1.0, defined in -01, is deprecated by Section 6.7. CRQC: Cryptographically Relevant Quantum Computer. Digest: A cryptographic hash of an artifact under one of the algorithms of the declared Algorithm Suite. FLP: Federated Learning Proof. Link: A per-algorithm chain value binding a record to its predecessor. Each record has one link per algorithm in the suite. See Section 6.3. REM: Reilly EternaMark Protocol [REM02]; the permanence infrastructure used by the reference deployment. Revocation Registry: The append-only, separately resolvable index of revocation statements required by Section 17, without which a verifier cannot determine that a SEP has been revoked. SEP: Sentinel Evidence Package; the container defined by this document. SIP: Streaming Inference Proof. 3. Architecture and Roles Producer: Creates artifacts, computes digests under the declared Algorithm Suite, collects device and environment attestations, signs SEPs, and requests anchoring and identifier registration. Registrar: Provides two sub-services: (a) an Anchoring Orchestrator that submits values to public chains and returns proofs, and (b) an Identifier Registrar that mints persistent identifiers and stores metadata, lineage, and fixity records. Verifier: Recomputes digests, validates signatures, checks anchoring proofs against independent nodes, resolves identifier metadata, verifies the chain construction of Section 6, and checks the Revocation Registry, without trusting Producer or Registrar beyond their published signatures. Storage: WORM or equivalent immutable object storage for SEPs, CPOs, and payloads under retention policy. Content-addressed storage is RECOMMENDED for redundancy. Salts used for commitments (Section 14.4) MUST be stored under access control separate from the records that commit to them. Time: Authenticated time sources [RFC8915] and monotonic counters. Section 22.2 states the limits of what these establish. Revocation Registry: An append-only, independently resolvable index of revocation statements. See Section 17. This role is new in -02; -01 assumed revocations would be discovered by inspecting the chain, which is not a procedure a verifier can execute. RSP does not mandate a specific trust relation among these roles. In many deployments Producer and Registrar are separate entities. Where they are not, Section 22.7 applies. 4. Sentinel Evidence Package (SEP) Data Model An SEP is a self-describing manifest binding digests, metadata, signatures, proofs, and identifiers. Version 1.2 corrects the contradictions between the conformance levels and the CDDL of -01 and replaces the quantum_resilient boolean. Core fields: * version: Protocol version string. MUST be "1.2" for this revision. Verifiers MUST accept "1.1" records and apply the construction of -01 to them, reporting that they were verified under the deprecated construction (Section 6.7). * alg_suite: REQUIRED. Object declaring the algorithms in force: - alg_suite.digest[]: Ordered array of algorithm identifiers, from "sha-256", "sha3-512", "blake3". The order is normative and fixes the order of link values in the braid. - alg_suite.blake3_output_bits: REQUIRED when "blake3" is present. MUST be 256 unless a profile specifies otherwise. BLAKE3 is an extendable-output function and a verifier cannot otherwise know what length to compute. This replaces rem.quantum_resilient, which was a producer self-assertion carrying no verifiable content. A verifier determines the security posture of a record by reading the suite and applying its own judgment, not by reading a boolean in which the producer graded itself. * artifact.type: One of "dataset", "datatransform", "training.config", "training.log", "training.checkpoint", "fine-tune.diff", "evaluation", "inference", "inference.stream", "federated.update", "agentic.action.log", "revocation", or an extension token. * payloads[]: Optional array of { cid, size, mime, chunking }. 'cid' MUST encode algorithm and value. * digests: Object with one member per algorithm in alg_suite.digest, hex-encoded. For chunked payloads, each member is the Merkle root computed per Section 7 under that algorithm, and digests.chunked MUST be true so that a verifier does not attempt a whole-artifact comparison. Revision -01 left this ambiguous by defining digests.root separately while also defining per-algorithm members. * cpo_ref: Reference to the Composite Proof Object. REQUIRED when the SEP participates in a chain. * timestamps: wallclock [RFC3339] and monotonic counter. 'source' SHOULD indicate NTS, Roughtime, or equivalent. See Section 22.2 for what this does and does not establish. * authors[]: Optional list of creators or operators. * attestation: Optional device, firmware, or build attestation claims [RFC9334]. * anchors[]: REQUIRED once anchoring has been requested. Each entry: { class, target, value_anchored, state, receipt_ref, block_height, obtained_at }. 'state' MUST be "pending" or "attested" per Section 9. 'block_height' MUST be present when state is "attested" and MUST be absent otherwise. * ids: Identity sub-object: remid, doi, ipfs_cid, lineage { parent[], siblings[], supersedes[] }, verification_url. Renamed from 'rem' in -01, since none of these fields are specific to the REM infrastructure and the old name implied a dependency that does not exist. Producers emitting "1.2" MUST use 'ids'; verifiers MUST accept 'rem' on "1.1" records. * commitments: Optional. Present when salted commitments are used (Section 14.4). Contains { alg, root, fields[] }. * agentic, federated: Optional sub-objects. See Sections 14 and 16. * class, policies: Optional classification and policy references. * signatures[]: One or more COSE_Sign1 [RFC9052] or CMS [RFC5652] signatures over the manifest canonical form. Certificate chains MUST be included. The CDDL in Appendix A encodes this as a non-empty array; -01's CDDL permitted an empty array while its prose required at least one. The manifest MUST be canonicalized prior to signing using JCS [RFC8785] for JSON or deterministic encoding [RFC8949] for CBOR. The canonicalization used MUST be recorded in the SEP, because a verifier that guesses wrong reports a signature failure indistinguishable from tampering. 5. Multi-Algorithm Hash Architecture This section replaces Section 5 of -01, which was titled "Quantum-Resistant Triple-Hash Architecture". The retitling is deliberate: the architecture's value is algorithmic diversification, and describing it primarily as a quantum measure both overstated the quantum threat to hashing and understated the cryptanalytic case for diversity. 5.1. Which Property Binds a Provenance Record A provenance record asserts that a specific artifact existed in a specific form at a specific time. The attack that defeats this is not preimage recovery; the artifact is generally already known to the adversary. The attack is collision. The adversary prepares two artifacts with the same digest, anchors one, and later presents the other, which in practice requires a chosen-prefix collision since both must be meaningful artifacts. The practical breaks of MD5 and SHA-1 followed exactly this path. Throughout this document, the security of a digest or link is stated in terms of collision resistance. Where preimage resistance is the relevant property, it is named explicitly, and Section 21.3 identifies the one place in RSP where it genuinely is. 5.2. Corrected Security Figures This table replaces the figures in Sections 5.1, 5.3, and 20.3 of -01. Values are approximate security levels in bits. +-----------+--------+--------------+-------------+------------+ | Algorithm | Output | Collision | Preimage | Preimage | | | (bits) | (classical | (classical) | (Grover) | | | | and quantum) | | | +-----------+--------+--------------+-------------+------------+ | SHA-256 | 256 | 128 | 256 | 128 | | SHA3-512 | 512 | 256 | 512 | 256 | | BLAKE3 | 256 | 128 | 256 | 128 | +-----------+--------+--------------+-------------+------------+ Collision resistance occupies one column because quantum computation does not meaningfully reduce it. Grover's algorithm halves preimage resistance. Quantum collision algorithms achieve an asymptotic improvement only at comparable quantum memory cost, and under cost models that account for memory access the classical birthday bound remains operative. The consequences for RSP: * SHA-256's binding strength for provenance purposes is 128 bits and is not reduced by a CRQC. Revision -01's framing of SHA-256 as quantum-vulnerable for this application was incorrect. * SHA3-512 contributes 256-bit collision resistance. This is a real and substantial improvement, and it is an improvement in the classical setting as much as the quantum one. * BLAKE3 contributes 128-bit collision resistance and a third structural family. BLAKE3 is an extendable-output function whose 256-bit default is a truncation. Implementations MUST declare the output length in alg_suite.blake3_output_bits (Section 4). BLAKE3 is not standardized by NIST, the IETF, or ISO; deployments in regulated environments SHOULD NOT rely on it as a sole digest. 5.3. Hedging, Not Addition Revision -01 implied that three algorithms compose conjunctively. [JOUX] showed that 2^k-way multicollisions in an iterated hash can be constructed at cost approximately k times a single collision, so that a collision in H1(x) || H2(x) can be found at cost bounded near that of attacking the stronger function alone. SHA-256 is iterated and directly subject to this. SHA3-512's sponge and BLAKE3's tree mode are not iterated in the same sense and the result does not apply to them in its original form; no equivalent published result against either is known to the author. This document therefore claims: * The collision resistance of the declared suite is approximately that of its strongest member, currently 256 bits from SHA3-512. * The contribution of the other members is hedging: if a cryptanalytic advance reduces one function below a usable level, records remain bound under the remaining functions and a verifier can determine which still hold by checking them separately. * Additive or multiplicative strength is NOT claimed, and implementations, conformance statements, and product material derived from this specification MUST NOT claim it. 5.4. Corrected Post-Quantum Statement The following replaces the quantum claims of -01 Sections 1, 5.1, 5.3, and 20.3, and SHOULD be used in preference to them wherever those claims have been repeated. RSP records are bound by collision resistance. Under the default suite this is approximately 256 bits, furnished by SHA3-512. Grover's algorithm does not reduce this figure. RSP record integrity rests on hashing rather than on public-key operations and therefore does not depend on any post-quantum key-establishment or signature scheme. Signatures over SEPs are a separate matter. COSE and CMS signatures use public-key algorithms that ARE broken by a CRQC. A record whose integrity survives quantum adversaries may nonetheless have an unverifiable signature. Deployments with long horizons SHOULD plan post-quantum migration of signature material, and MAY dual-sign with ML-DSA [FIPS204] alongside a classical algorithm. The second paragraph identifies a gap -01 did not address at all. Revision -01 devoted Section 20.3 to quantum threats against hashing, where the threat is modest, while requiring COSE and CMS signatures throughout without noting that those are the component a CRQC actually breaks. 5.5. Digest Computation For each artifact and each algorithm A in alg_suite.digest, the Producer MUST compute: digest_A = A( artifact_octets ) over the whole artifact where it is unchunked, or the Merkle root per Section 7 under A where it is chunked, with digests.chunked set accordingly. The three digests are computed over identical input. No domain separation is applied at this level and none is required, since the values are labelled by algorithm in the SEP and are never interchangeable. Domain separation IS required in the chain construction, where values of different kinds are hashed under the same function, and Section 6 specifies it there. 6. Chain Construction and Composite Proof Objects 6.1. The Defect in -01 Section 1.1.1 states the defect. In summary: the binding value of -01 was a SHA3-512 output over an unframed concatenation of variable-length hex strings, so it neither required multiple breaks nor unambiguously identified the chain states it committed to, and it was the only value the protocol required to be anchored. The construction below fixes all three problems: fixed-length framing removes ambiguity, a common hashed input under every algorithm provides entanglement, and a concatenated braid means no algorithm is a single point of failure. 6.2. Context Commitment and Record Commitment Section 6.1 of -01 specified the chain hash input as "the previous chain hash, the current artifact digest, record ID, REMID, and creation timestamp" with no serialization. Three of those are variable-length strings, concatenated without delimiters. The context commitment fixes their encoding: H_ctx = SHA3-512( 0x00 || lp(record_id) || lp(remid) || lp(created_at) ) where lp(s) is uint32be(length) || UTF-8(s). Length prefixing means no two distinct field triples can produce the same octet string. SHA3-512 is used because H_ctx is the only variable-length input in the construction and therefore the only place a metadata encoding collision could substitute one record's context for another's; it is given the strongest available function. Where an implementation does not use REMIDs, lp("") is used in that position. The field MUST NOT be omitted, since omission would change the input length and break interoperability. The record commitment is: M = 0x01 || uint64be(seq) || digest_sha256 || digest_sha3_512 || digest_blake3 || H_ctx M is a fixed 201-octet value: one octet of domain separation, eight of sequence number, 32 + 64 + 32 of digests, and 64 of context commitment. Fixed length is deliberate. A variable-length input hashed under three functions exposes the weakest mode in the set to length-extension and ambiguity attacks; a fixed-length input forecloses them structurally rather than by argument. Where the declared suite omits an algorithm, its digest field is replaced by the appropriate number of zero octets and the omission is recorded in the CPO. The length of M does not vary. 6.3. Link Construction and Entanglement Let braid_prev be the 128-octet braid of the predecessor record (Section 6.4), or 128 octets of 0x00 for the genesis record of a chain. The link values are: L_sha256 = SHA-256 ( 0x02 || braid_prev || M ) L_sha3 = SHA3-512( 0x02 || braid_prev || M ) L_blake3 = BLAKE3 ( 0x02 || braid_prev || M ) All three are computed over the identical 330-octet input. This is the entanglement, and it is what -01 lacked: because braid_prev contains the predecessor's links under all three algorithms, every link commits transitively to every earlier link under every algorithm. An adversary who breaks one function cannot construct a self-consistent alternative history that a verifier checking a different function would accept. Revision -01's chains were, in its own words, "independent". That is precisely the weakness: three independent chains fall one at a time. The prefixes 0x00, 0x01, and 0x02 partition the three hashing contexts so that a context commitment, a record commitment, and a link value cannot be confused even where output lengths coincide. 6.4. The Braid braid = L_sha256 || L_sha3 || L_blake3 which is 32 + 64 + 32 = 128 octets, in the order given by alg_suite.digest. The braid is a concatenation and MUST NOT be replaced by a hash of the three links. Hashing them under any single function would reinstate exactly the defect of -01 Section 6.2: that function would become the single point of failure for the entanglement, and a break in it would permit substitution of a braid whose components differ from those recorded. The cost of concatenation is 128 octets per record. The chain head is the braid of the highest-numbered record. Publishing the head publishes all three chain states at once. 6.5. Composite Proof Object, Version 2.0 A CPO 2.0 carries a record's chain state: { "cpo_version": "2.0", "chain_id": "", "seq": , "record_id": "", "created_at": "", "alg_suite": { "digest": ["sha-256","sha3-512","blake3"], "blake3_output_bits": 256 }, "h_ctx": "", "digests": { "sha-256": "", "sha3-512": "", "blake3": "" }, "prev_braid": "", "links": { "sha-256": "", "sha3-512": "", "blake3": "" }, "braid": "", "anchors": [ { "class": "...", "value_anchored": "braid", "state": "attested", "block_height": } ], "signatures": [ ... ] } The "cross_chain_hash" field of CPO 1.0 is removed and MUST NOT appear in a CPO 2.0. Implementations MUST NOT compute it, and verifiers encountering it in a document claiming version 2.0 MUST reject the document rather than ignore the field, since its presence indicates the producer has mixed constructions. CPOs MUST be signed by the Producer and MAY be countersigned by the Registrar. 6.6. What Is Anchored The value anchored is the braid, not a hash of it and not a single derived value. Because the braid is 128 octets and anchoring services commonly accept a single digest, implementations MAY anchor H_anchor = SHA-256(0x03 || braid) as the submitted value, PROVIDED that: (1) The full braid is published alongside the anchor receipt, so that any verifier can recompute H_anchor and confirm it. (2) The CPO records both the braid and H_anchor. (3) Implementations do not describe H_anchor as the chain state. It is a submission handle for an anchoring service, and the chain state is the braid. This is an honest accommodation rather than a security property, and Section 9.4 explains why it costs nothing: the outermost binding of any OpenTimestamps anchor is SHA-256 in any case, because that is the function the calendar aggregation uses. Revision -01 did not acknowledge this and consequently described an anchor of a SHA3-512 value as though the anchoring itself carried SHA3-512 strength. It does not. What SHA3-512 protects is the link, and the link is protected whether or not the submission handle is a SHA-256 value, because the braid it commits to is published. 6.7. Migration from CPO 1.0 Implementations of -01 MUST NOT recompute historical chain values under the new construction. Recomputation would destroy whatever evidentiary value the original records have and would not be reproducible by a verifier holding only published anchors. Migration procedure: (1) Continue to publish existing CPO 1.0 records unchanged. (2) At a declared sequence number, begin issuing CPO 2.0 records. The first CPO 2.0 record is the genesis of a new chain with prev_braid of 128 zero octets, and its metadata MUST include a legacy_ref recording the chain_id, final seq, and final cross_chain_hash of the CPO 1.0 sequence it continues. (3) Anchor the first CPO 2.0 record under class A within its anchor window. (4) A verifier presented with a range spanning the migration MUST verify the pre-migration segment under the -01 construction, MUST report that segment as verified under a deprecated construction whose binding depends on SHA3-512 alone, and MUST NOT report the range as uniformly verified. Implementers should understand what step (4) means in practice. Records issued under -01 carry the assurance -01 actually provided, which is less than -01 claimed. Nothing in this revision can retroactively strengthen them, and a verifier that silently smooths over the difference misrepresents them. 7. Merkle Tree Construction This section is new in -02 and applies wherever this document refers to a Merkle root or path: roll-up anchoring (Section 9.5), the AAL merkle_root (Section 14.2), the streaming inference tree (Section 15.2), the federated update_root (Section 16.2), and chunked artifact digests (Section 5.5). Revision -01 used all five without specifying any of them. 7.1. Leaf Ordering Leaves MUST be ordered by the tuple (sequence or index, then identifier), ascending, comparing identifiers as octet strings. The ordering MUST be reproducible by a verifier from the published record alone. Ordering by digest MUST NOT be used, as it destroys the temporal sequence that the streaming and agentic extensions depend on and makes concatenation of windows non-monotone. 7.2. Tree Definition For an algorithm A with hash function H, over an ordered leaf digest list D[n], the Merkle Tree Hash is defined as in [RFC6962] Section 2.1: MTH({}) = H() MTH({d_1}) = H( 0x00 || d_1 ) For n > 1, with k the largest power of two strictly less than n: MTH(D[n]) = H( 0x01 || MTH(D[0:k]) || MTH(D[k:n]) ) No leaf is ever duplicated. Trees of any cardinality including zero and one are well defined. The 0x00 and 0x01 prefixes prevent second-preimage attacks in which an interior node is presented as a leaf. Implementations MUST NOT duplicate the final digest on odd cardinality. That construction, which appears in some blockchain implementations, permits distinct leaf multisets to yield identical roots. 7.3. Proofs Inclusion proofs MUST be generated per [RFC6962] Section 2.1.1 and MUST be stored or derivable alongside the anchored root. Where an implementation maintains a continuous append-only log, consistency proofs per [RFC6962] Section 2.1.2 MUST be supported. A verifier auditing a long span SHOULD use the bulk subtree proof construction of [BSP01], which verifies a contiguous range by descent over full subtrees rather than one inclusion proof per leaf. For an agentic session of many thousands of actions the difference is material. 7.4. Per-Algorithm Trees Where a suite declares multiple algorithms and a Merkle root is required, a separate tree MUST be computed under each algorithm over the same ordered leaf list, and each root recorded separately. A single tree under one algorithm, with the resulting root presented as covering a multi-algorithm record, reproduces the defect of Section 6.1 at a different layer. 8. Serialization and Media Types RSP SEPs MAY be emitted as JSON [RFC8259] or CBOR [RFC8949]. This document defines four media types, registered in Section 23: * application/rsp-ep+json * application/rsp-ep+cbor * application/rsp-cpo+json * application/rsp-cpo+cbor The structured suffixes follow [RFC6839]. The charset parameter listed for the JSON types in -01 is removed: [RFC8259] requires UTF-8 for interchanged JSON and a charset parameter is therefore meaningless and potentially misleading. 9. Anchoring and Proofs 9.1. Requirements Producers submit the braid, or the submission handle of Section 6.6, to the Anchoring Orchestrator. The orchestrator MUST anchor to at least one public append-only chain and SHOULD anchor to two operated under different consensus systems. Proofs MUST be exportable and independently checkable without trusting the orchestrator. 9.2. Pending and Attested States This subsection is new in -02. A blockchain timestamp proof exists in one of two states, and RSP requires that they never be conflated. Pending. The proof carries a calendar server's undertaking to include the value in a future commitment. It carries no proof-of-work, establishes no block, and would resolve to nothing if the calendar discarded its aggregation state. Pending proofs are available within seconds. Attested. The proof has been upgraded after the commitment transaction confirms, and includes a path to a block header and a block height. It is verifiable by any party holding block headers with no trust in the calendar operator or the producer. Every anchors[] entry MUST carry state, and MUST carry block_height when and only when state is "attested". An implementation MUST NOT present a SEP as anchored, timestamped, or blockchain-backed while its only anchor is pending; the correct description is that anchoring has been submitted. A verifier MUST report pending anchors as pending and MUST NOT count them toward ots_ok. The distinction is the difference between an assertion backed by proof-of-work and an assertion backed by a server staying up. 9.3. Anchor Latency and Coverage Implementations MUST track time from submission to attestation per record, MUST expose it, and SHOULD alert when a proof remains pending beyond a configured threshold. Section 20 lists this as required telemetry. 9.4. What the Anchoring Function Actually Is OpenTimestamps calendars aggregate submissions into Merkle trees under SHA-256 and commit the root to Bitcoin. Consequently the outermost cryptographic binding of any OTS anchor is SHA-256, whatever value is submitted. Submitting a SHA3-512 output does not confer SHA3-512 strength on the anchoring operation; it places a 64-octet string into a SHA-256 tree. Revision -01 did not state this, and its Section 8 and Appendix D consequently implied that anchoring the SHA3-512 cross-chain hash made the anchor itself quantum-resilient. It did not and could not. The correct reading: the anchor establishes existence-by-time with SHA-256 collision resistance, which is 128 bits and is not reduced by Grover. The stronger functions protect the link and record structure, not the anchoring aggregation. Implementations requiring anchoring under a stronger function must use an anchoring system that aggregates under one, and the author is not aware of a widely deployed service that does. 9.5. Roll-Up Anchoring Operators SHOULD periodically compute a Merkle tree per Section 7 over new record braids and anchor the root, reducing per-record anchoring cost. Roll-up trees MUST be computed under each algorithm in the suite per Section 7.4. 9.6. Re-Anchoring Re-anchoring historical roots under newer algorithms is RECOMMENDED for longevity. Re-anchoring MUST be additive: the original anchor and receipt are retained, and the re-anchor is recorded as an additional anchors[] entry. A re-anchor performed after the original algorithm is credibly weakened carries no more assurance than that algorithm, and implementations SHOULD treat the first credible published weakening rather than formal deprecation as the trigger. 10. Persistent Identifier Registration After anchoring, the Registrar mints a persistent identifier and stores a metadata record containing at least: title or short label, creators, creation time, fixity digests under each algorithm in the suite, the braid, lineage links, content identifier, and policy URIs. Identifiers for restricted material MAY be internal Handles resolvable on private networks; unrestricted artifacts SHOULD use public DOIs. An identifier SHOULD be minted for each material evolution that changes fixity. Prior identifiers MUST NOT be deleted; metadata MAY indicate "superseded-by". Metadata SHOULD include: the REMID where one is assigned, the digest under each algorithm, the braid, and the alg_suite. The cross_chain field of -01 is removed and the quantum_resilient boolean is not carried; see Section 4. 11. REM Protocol Integration 11.1. Overview Where RSP operates over REM [REM02], each SEP may receive a REMID, a DOI, a content identifier, a blockchain timestamp proof, and a verification page. RSP does not require REM. Revision -01's Section 10 and its use of a 'rem' object in the data model implied a coupling that does not exist; Section 4 renames the object to 'ids' accordingly. 11.2. Integration Requirements Where RSP operates over REM: * ids.remid MUST be populated with the assigned REMID. * The CPO MUST be submitted for chain integrity verification. * ids.verification_url MUST be included where a verification page is generated. * The alg_suite MUST be recorded; the quantum_resilient boolean required by -01 Section 10.2 is not carried. REMID prefixes are 32 bits and are not a cryptographic binding. Implementations MUST NOT treat REMID equality as artifact equality and MUST compare full digests on resolution. 11.3. Chain Integrity Monitoring and the Prohibition on Repair This subsection replaces Section 10.3 of -01. The REM infrastructure monitors chain integrity across submitted artifacts. Revision -01 described an agent performing "autonomous self-healing repair cycles" over chain integrity violations. That behavior is prohibited by this revision. An implementation MUST NOT automatically repair, reconcile, recompute, or otherwise resolve a detected chain integrity violation. On detection it MUST: (1) Preserve the inconsistent state exactly as found, including the conflicting values. (2) Record a violation report as a signed record, anchored like any other. (3) Escalate to a human operator. (4) Continue to report affected records as failing verification until a human disposition is recorded. The reasoning is short. A chain integrity violation means either the chain was tampered with or the implementation is defective. Automated repair produces a consistent chain in both cases, and a consistent chain is indistinguishable from one that was never violated. The repair therefore destroys the only evidence that anything happened, and it does so precisely when an adversary would most want it destroyed. Self-healing is appropriate for availability faults and is never appropriate for integrity faults. Automated remediation of availability faults, such as re-pinning dropped content or resubmitting a failed anchor, remains permitted and SHOULD be recorded. 12. Protocol Operations Concrete APIs are out of scope. 12.1 SEAL Inputs: unsigned manifest draft, digests under the declared suite, optional attestation, optional extensions. Action: Canonicalize, compute H_ctx and M, compute links and braid, sign, return signed SEP and CPO 2.0. 12.2 ANCHOR Inputs: braid, or submission handle per Section 6.6. Action: Anchor to one or more chains; return proof references; record state as "pending"; on upgrade, update state to "attested" and record block height. 12.3 REGISTER Inputs: metadata including fixity, lineage, content identifier. Action: Mint identifier; bind identifier, SEP, CPO, and proofs; return identifier. 12.4 VERIFY Inputs: identifier or SEP URI, plus payload if accessible. Action: Execute Section 13; emit Verification Report. 12.5 REVOKE Inputs: SEP identifier, revocation reason, authorizing identity. Action: Emit a signed revocation record, publish it to the Revocation Registry (Section 17), and include it in the chain. The original SEP MUST NOT be deleted or modified. 13. Verification Algorithm Given an identifier or SEP: 1. Resolve the identifier to retrieve metadata including fixity, lineage, content identifier, and pointers to SEP and CPO. 2. Fetch SEP and CPO. Read alg_suite. Where blake3 is present, read blake3_output_bits; if absent on a "1.2" record, fail with ERR_SUITE_UNDECLARED rather than assuming 256. 3. Where the payload is accessible, recompute the digest under each algorithm in the suite and compare. Where digests.chunked is true, recompute per Section 7. 4. Recompute H_ctx from record_id, remid, and created_at using the length-prefixed encoding of Section 6.2, and compare. 5. Reconstruct M and, using prev_braid from the CPO, recompute all three link values. Compare each. A verifier MUST recompute all links in the declared suite unless explicitly restricted by its operator, and MUST report which it computed. 6. Recompute the braid as the concatenation of the links and compare to the recorded braid. 7. Walk the chain across the range of interest, confirming that seq values are consecutive and that each record's prev_braid equals its predecessor's braid. 8. Validate signatures [RFC9052] [RFC5652], certificate validity, and revocation of the signing certificates. 9. Validate time per Section 22.2: confirm wallclock plausibility and monotonic continuity, and treat the attested anchor block time as the only externally verifiable bound. 10. Validate anchoring proofs independently against public chain data. Report pending anchors as pending (Section 9.2). 11. Resolve the content identifier and confirm retrievability. 12. Query the Revocation Registry (Section 17) for the SEP identifier and for every identifier in its lineage. 13. Where the range spans a construction migration, apply Section 6.7 step (4). 14. Emit a Verification Report containing at minimum: per-algorithm digest results, per-algorithm link results, chain_ok, braid_ok, sig_ok, attestation_ok, anchor results with state and block height per anchor, time_ok, identifier_ok, content_ok, revocation_status, algorithms_checked, construction_version, and an overall verdict. The report SHOULD itself be signed. A report that states an overall verdict without stating which algorithms were checked and under which construction is non-conformant. The entire value of a multi-algorithm design lies in which functions were actually exercised, and a boolean verdict discards it. 14. Agentic AI Provenance Extensions 14.1. Motivation Agentic systems execute multi-step workflows autonomously. Each action represents a provenance event. Agentic provenance requires a structured log preserving causality, timing, and agent identity. 14.2. Agentic Action Log (AAL) An AAL is a SEP with artifact.type "agentic.action.log". The agentic sub-object MUST contain: * session_id, agent_id, model_id, action_count. * merkle_roots: Object with one Merkle root per algorithm in the suite, computed per Sections 7.2 and 7.4 over the ordered action record digests. Revision -01 specified a single merkle_root under SHA3-512, which reintroduced single-algorithm dependence inside a multi-algorithm protocol. * actions[]: Ordered array of action records. Each action record MUST contain: seq (monotonically increasing), timestamp, action_type, tool_id where applicable, parent_seq, and the commitments of Section 14.4 in place of the bare input_digest and output_digest of -01. 14.3. AAL Anchoring The Merkle roots MUST be anchored via ANCHOR. For long-running sessions, intermediate roots MAY be anchored at intervals to bound the recovery window. Where intermediate roots are anchored, the log MUST be treated as an append-only log and consistency between successive roots MUST be provable per Section 7.3; otherwise an operator can silently rewrite actions between anchors. 14.4. Commitments and Selective Disclosure This subsection replaces Section 13.4 of -01. For each disclosable field f of an action record with canonical value v: salt_f = 32 octets from a CSPRNG c_f = SHA3-512( 0x04 || salt_f || lp(field_path) || lp(v) ) Commitments are ordered by field path and formed into a Merkle root per Section 7 under each algorithm in the suite. The action record carries the commitment root; salts and values are held in the Evidence Store under separate access control and MUST NOT be published with the record. Disclosure of a single field reveals its value, its salt, and an inclusion proof, permitting verification against the anchored root without revealing other fields. Salts MUST be unique per field per record and MUST NOT be derived from the field value or record content, since such derivation would let a holder of the commitment confirm a guessed value. The limitation must be stated. Commitment protects against undetected alteration and against guessing by a party who does not hold the salt. It does not protect against a salt holder guessing a low-entropy value. The claim in -01 that digests alone provided selective disclosure was unsound because action inputs are routinely low-entropy: an adversary holding an unsalted digest of a tool name or a boolean decision enumerates the candidates and hashes them, and preimage resistance is irrelevant to that attack. 15. Streaming Inference Provenance 15.1. Motivation Real-time systems produce inference outputs as unbounded streams. Standard SEP structures assume bounded artifacts. 15.2. Streaming Inference Proof (SIP) A SIP is a SEP with artifact.type "inference.stream". The stream is chunked into windows; the default window is the lesser of 1000 tokens or 30 seconds. The window policy MUST be recorded, since a verifier cannot otherwise reproduce the leaf boundaries. For each window the Producer MUST compute the digest under each algorithm in the suite, append it as a leaf in append order per Section 7.1, and record the window's stream position. The tree MUST be constructed per Section 7.2 under each algorithm. Revision -01 specified "a rolling Merkle tree" with SHA3-512 window digests and no construction; two implementations could produce different roots over identical streams. At stream termination the final roots are anchored and a SEP is issued referencing the window digests. Verifiers MAY verify any individual window by checking its inclusion proof against the anchored root without retrieving the stream. 15.3. Real-Time Monitoring For safety-critical inference, producers SHOULD maintain a live anchor feed submitting intermediate roots at intervals, bounding the maximum provenance gap on unexpected termination. Consistency between successive intermediate roots MUST be provable per Section 7.3. Implementers should note that anchor latency, not submission latency, bounds the guarantee. An intermediate root submitted every ten seconds but attested hours later provides a ten-second ordering granularity and an hours-long window during which the only evidence is a pending anchor. Section 9.2 applies. 16. Federated Learning Provenance 16.1. Motivation Federated learning trains models across clients without centralizing raw data. Provenance must record the integrity of updates and the aggregation operation. 16.2. Federated Learning Proof (FLP) An FLP is a SEP with artifact.type "federated.update" containing a federated sub-object with: round_id, aggregation_id, participant_count, update_roots (one per algorithm, per Section 7.4), global_model_id, privacy_mechanism, and privacy_parameters. privacy_parameters is new in -02 and MUST be present when privacy_mechanism denotes a differential privacy mechanism, carrying at minimum epsilon and delta. Recording the name of a mechanism without its parameters records nothing: "dp_gaussian" with an unbounded epsilon is not privacy, and -01 permitted exactly that. 16.3. Corrected Privacy Claim Revision -01 stated that because client identities are not recorded, "the update_root provides aggregate integrity without revealing per-client contributions". This overstates the property in three ways, and implementers relying on it may believe they have privacy guarantees they do not have. First, omitting identity from a record is not anonymization. Where inclusion proofs are served, the individual update digests are disclosed by construction, and a party holding a candidate update confirms it by hashing. Client updates are not high-entropy secrets from the aggregation server's perspective, because the server received them. Second, the record's privacy properties are inherited from the federated learning scheme, not from RSP. Model updates are subject to gradient inversion and membership inference. RSP records integrity over whatever the scheme produces and adds no privacy of its own. Third, participant_count is itself disclosive in small cohorts, and the combination of round_id, participant_count, and timing across rounds can support participation inference. Accordingly: * Individual client update digests MUST be committed with salts per Section 14.4 where any inclusion proof may be served. * privacy_mechanism "none" MUST NOT be accompanied by any claim of privacy preservation in the SEP or its metadata. * Implementations MUST NOT represent RSP as providing privacy for federated learning. RSP provides verifiable integrity over a process whose privacy is established elsewhere. 17. Revocation This section is new in -02. Revision -01 defined a REVOKE operation appending a revocation fact to the chain, and a verification step directing verifiers to "check revocation status against the chain record". That is not an executable procedure: a revocation is issued after the SEP it revokes, so nothing in the SEP points to it, and a verifier would have to scan the entire forward chain to discover one. A verifier lacking the full forward chain would report a revoked SEP as valid. 17.1. Revocation Registry Implementations MUST operate a Revocation Registry: an append-only, independently resolvable index keyed by SEP identifier, returning any revocation statements for that identifier. The registry MUST be resolvable without possession of the chain, MUST be served over an authenticated channel, MUST return a signed response including a signed "no revocation found" for identifiers with no entry, and MUST have its own state committed into the chain at intervals so that suppression of an entry is detectable. A signed negative response is required because an unsigned or absent response is indistinguishable from a suppressed one, which is the failure mode the registry exists to prevent. 17.2. Revocation Statement A revocation statement is a SEP with artifact.type "revocation" whose metadata carries: revoked_identifier, reason, authorizing identity, effective time, and whether the revocation is retroactive to issuance or effective from a stated time. It is signed, chained, and anchored like any other record. 17.3. Verification A verifier MUST query the registry for the SEP under verification and for every identifier in its lineage, since revocation of a parent artifact bears on the validity of derived ones. A verifier unable to reach the registry MUST report revocation_status as "unknown" and MUST NOT report an overall verdict of VERIFIED. 17.4. Limits Revocation depends on the producer choosing to revoke. A producer who knows a record is wrong and issues no revocation creates no inconsistency, and no mechanism in this document detects that. Revocation provides an auditable channel for a producer acting in good faith and a dated record of when they acted; it does not compel honesty. 18. Conformance Framework 18.1. Conformance Levels RSP-Basic: * SEP version 1.2 with alg_suite.digest containing at least "sha-256". * Single-chain anchoring with pending and attested states tracked per Section 9.2. * Identifier registration. * SEAL, ANCHOR, REGISTER, VERIFY, REVOKE operations. * Revocation Registry per Section 17. * Merkle construction per Section 7 wherever trees are used. RSP-Multi: * All RSP-Basic requirements. * alg_suite.digest containing "sha-256", "sha3-512", and "blake3", with blake3_output_bits declared. * CPO 2.0 generation and verification per Section 6. * Braid anchoring per Section 6.6. * Per-algorithm Merkle trees per Section 7.4. RSP-Full: * All RSP-Multi requirements. * Persistent identifier and content-addressed storage integration. * Agentic Action Log support with commitments (Section 14). * Streaming inference (Section 15) or federated learning (Section 16) provenance. * Multi-chain anchoring across at least two independent consensus systems. * Chain integrity monitoring with the repair prohibition of Section 11.3. The level named RSP-Quantum in -01 is renamed RSP-Multi. The original name asserted a security posture the level does not deliver, for the reasons in Sections 5.2 and 5.4, and conformance level names should describe what is implemented rather than what it is hoped to withstand. 18.2. Consistency with the Data Model Revision -01's RSP-Basic permitted SHA-256 alone while its CDDL (Appendix A) marked sha3_512 and blake3 as required members of digests, so no RSP-Basic implementation could emit a conformant SEP. In this revision the CDDL of Appendix A encodes digests as a map keyed by declared algorithm and enforces consistency with alg_suite, so the levels and the schema agree. 18.3. Conformance Testing Implementations claiming a level MUST pass Section 13 for all applicable artifact types and MUST reproduce the test vectors in Appendix I. An implementation that cannot reproduce the genesis link values in Appendix I has a canonicalization, framing, or domain-separation error that will otherwise propagate silently through every record it issues. 19. Error Handling ERR_PARSE malformed SEP, CPO, or encoding ERR_DIGEST_MISMATCH recomputed digest differs (per alg) ERR_CTX_MISMATCH recomputed H_ctx differs ERR_LINK_MISMATCH recomputed link differs (per alg) ERR_BRAID_MISMATCH braid differs from concatenated links ERR_CHAIN_DISCONTINUITY seq gap or prev_braid mismatch ERR_SUITE_UNDECLARED alg_suite absent or incomplete ERR_CONSTRUCTION_MIXED CPO 2.0 carrying cross_chain_hash ERR_SIG_INVALID signature or certificate chain invalid ERR_TIME_INVALID unauthenticated or non-monotonic time ERR_ANCHOR_PENDING anchor exists but is not attested ERR_PROOF_INVALID proof not verifiable on stated chain ERR_ID_RESOLVE identifier metadata unavailable ERR_CONTENT_RESOLVE content identifier not resolvable ERR_REVOCATION_UNKNOWN Revocation Registry unreachable ERR_REVOKED SEP has been revoked ERR_POLICY_DENIED access denied by policy ERR_INTEGRITY_VIOLATION chain integrity violation detected ERR_BRAID_MISMATCH, ERR_CHAIN_DISCONTINUITY, ERR_REVOKED, ERR_CONSTRUCTION_MIXED, and ERR_INTEGRITY_VIOLATION MUST surface as prominent verification failures and MUST NOT be silently ignored. ERR_ANCHOR_PENDING and ERR_REVOCATION_UNKNOWN MUST prevent an overall verdict of VERIFIED. ERR_INTEGRITY_VIOLATION MUST NOT trigger automated repair (Section 11.3). 20. Manageability and Telemetry Deployments SHOULD monitor: * Anchor submission-to-attestation latency, per chain. * Proportion of records whose anchors remain pending beyond threshold. * Algorithm suite coverage across issued records. * Verification pass rate and dominant failure reasons. * Chain integrity findings and their human disposition status. * Key health: expiration, revocation events. * Time source health. * Content pin health: replication factor and retrieval latency. * Revocation Registry availability and signed-response rate. For agentic deployments, additionally: * Action count per session and anchor latency for AAL roots. * Streaming window gap rate. * Proportion of action records using commitments rather than bare digests. 21. Privacy Considerations 21.1. General SEPs record integrity metadata; payloads MAY be withheld. Where privacy is required, field-level commitments (Section 14.4) SHOULD be used while keeping roots and proofs public. Identifier metadata for sensitive artifacts SHOULD minimize personally identifiable information. 21.2. Agentic and Federated Records For agentic logs, action fields are recorded as salted commitments (Section 14.4). Raw content MUST NOT be embedded unless authorized by policy. For federated learning, Section 16.3 applies. RSP does not provide privacy for federated learning; it provides integrity over a process whose privacy properties are established by the scheme in use. 21.3. Anchored Values and Inference Blockchain anchoring publishes values to a public ledger. Producers MUST ensure that anchored values do not reveal sensitive information. Revision -01 stated that "pre-image resistance of SHA3-512 provides strong protection against reverse-engineering payload content from anchored digests". This is the one place in RSP where preimage resistance is the relevant property, so the invocation is not misplaced, but the conclusion is too strong. Preimage resistance protects a high-entropy payload. It provides no protection where the payload is drawn from a small or guessable set, since the adversary hashes the candidates rather than inverting the digest. Where an anchored value commits to low-entropy content, the value MUST be salted before anchoring. The braid of Section 6.4 is not affected, since it commits to digests of artifacts and to H_ctx rather than to content directly. 21.4. Correlation Persistent identifiers, REMIDs, and lineage links are designed to be correlatable, which is their purpose and also a privacy property. A published lineage discloses the relationship between artifacts and, by inference, the structure of a training pipeline or an organization's model development. Producers SHOULD consider whether lineage should be public, and MAY publish lineage as commitments with selective disclosure to auditors. 22. Security Considerations 22.1. Key Compromise Private keys used for COSE and CMS signatures MUST be protected in HSMs or equivalent. Short-lived certificates and revocation checking are RECOMMENDED. Compromised keys MUST NOT trigger data deletion; append signed revocation facts and supersede with new signatures. Immutability of prior records is a fundamental property of RSP. Key revocation MUST NOT invalidate the chain. Records signed before a declared compromise time remain valid links; the chain continues under the successor key with no gap in seq, and the transition is recorded as a chained record. 22.2. Time Producers MUST use authenticated time [RFC8915] and monotonic counters. Multiple independent sources are RECOMMENDED. Large backward jumps MUST be flagged. The limit must be stated plainly, because -01 did not. Authenticated time authenticates the time source; it does not authenticate the producer. A producer who wishes to backdate a record can write any wallclock value into it and sign it. NTS prevents an attacker from deceiving an honest producer; it does nothing against a dishonest one. The only externally verifiable temporal bound in RSP is the attested anchor: the record existed no later than the attested block. It is not a lower bound, and it is not proof of authorship. Verifiers SHOULD treat producer wallclock as a claim and the attested block time as evidence. 22.3. Quantum Threat Model RSP-Multi and RSP-Full are designed against the following: * Grover against digest preimages. Relevant only where preimage resistance matters (Section 21.3). Mitigated by SHA3-512's 512-bit output. * Collision search. The binding property. Not meaningfully accelerated by quantum computation (Section 5.2). Suite collision resistance is approximately 256 bits. * Structural cryptanalysis confined to one hash family. Mitigated by the entangled construction of Section 6.3, which keeps records verifiable under the remaining functions. * Quantum attack on signatures. NOT mitigated. COSE and CMS signatures use public-key algorithms broken by a CRQC. See Section 5.4. This is the actual quantum exposure of an RSP deployment and -01 did not address it. The claim in -01 that forging the composite "requires simultaneously breaking SHA-256, SHA3-512, and BLAKE3" is withdrawn; see Sections 1.1.1 and 5.3. 22.4. Proof Stability Anchoring across independent consensus systems reduces correlation risk. Re-anchoring per Section 9.6 is RECOMMENDED. Confirmation depth SHOULD be respected before treating an anchor as final. 22.5. Replay and Substitution Signatures bind to digests and policy context. Identifiers provide stable identity to detect substitution. Monotonic counters and the chain's seq continuity prevent action replay in agentic deployments: a replayed record cannot occupy a sequence position already committed by a successor's prev_braid. 22.6. Construction Downgrade A verifier that accepts CPO 1.0 for convenience while reporting the same verdict it gives CPO 2.0 creates a downgrade path: a producer can issue under the weaker construction and receive the stronger report. Verifiers MUST report construction_version and MUST NOT present the two as equivalent (Sections 6.7 and 13). 22.7. Combined Producer and Registrar Where one party operates as Producer, Registrar, and verification endpoint, a verifier obtains no independence from that party's published signatures and infrastructure other than through externally anchored values and independently retrievable content. A verifier with an interest adverse to that party SHOULD rely only on: recomputation of digests from independently retrieved payloads, recomputation of links and braid from published values, and anchor verification against independently obtained chain data. Those three require no cooperation and establish what RSP actually proves. 22.8. Integrity Faults Must Not Be Repaired Section 11.3 prohibits automated repair of chain integrity violations. This is a security requirement. An automated repairer with write access to chain state is a high-value target, and the conditions that trigger it are the conditions an adversary can most readily manufacture. Security considerations follow [RFC3552] guidance. 23. IANA Considerations IANA is requested to register four media types in the Standards Tree. Revision -01's templates omitted required fields of the [RFC6838] template; complete templates follow. 23.1. application/rsp-ep+json Type name: application Subtype name: rsp-ep+json Required parameters: N/A Optional parameters: N/A Encoding considerations: binary; JSON is UTF-8 encoded per [RFC8259] Security considerations: See Section 22 of this document. Interoperability considerations: See Sections 4 and 8. Canonicalization per [RFC8785] is required before signing. Published specification: this document Applications that use this media type: AI provenance and audit systems implementing RSP Fragment identifier considerations: as for application/json Additional information: Deprecated alias names: N/A Magic number(s): N/A File extension(s): .rsp-ep.json Macintosh file type code(s): N/A Person and email address to contact for further information: L.J. Reilly Intended usage: COMMON Restrictions on usage: none Author: L.J. Reilly Change controller: IETF 23.2. application/rsp-ep+cbor As Section 23.1, with: Subtype name: rsp-ep+cbor Encoding considerations: binary; CBOR per [RFC8949] Interoperability considerations: deterministic encoding per [RFC8949] Section 4.2 is required before signing Fragment identifier considerations: as for application/cbor File extension(s): .rsp-ep.cbor 23.3. application/rsp-cpo+json As Section 23.1, with: Subtype name: rsp-cpo+json Applications that use this media type: systems producing or verifying RSP Composite Proof Objects File extension(s): .rsp-cpo.json 23.4. application/rsp-cpo+cbor As Section 23.2, with: Subtype name: rsp-cpo+cbor File extension(s): .rsp-cpo.cbor The charset parameter listed in -01 for the JSON types is not requested; [RFC8259] requires UTF-8. 24. Implementation Status Note to RFC Editor: Please remove this section before publication. This section is provided per [RFC7942]. 24.1. Reference Deployment Organization: REM Technologies & Consulting, LLC Description: Live deployment of the REM Protocol infrastructure providing REMID assignment, multi-algorithm digests, content pinning, blockchain timestamp anchoring, and verification page generation. URL: https://remweb4.org/ Coverage: Anchoring substrate. Implements CPO 1.0. License: Proprietary. Contact: lawrencejohnreilly@gmail.com The endpoints cited in -01 under the hostname rem-protocol-agent-production.up.railway.app have migrated and should not be assumed to resolve. 24.2. Conformance of the Reference Deployment Implementers are cautioned that the reference deployment implements the CPO 1.0 construction that Section 6.1 identifies as defective. It does not yet implement CPO 2.0, the Revocation Registry of Section 17, the commitments of Section 14.4, or the per-algorithm Merkle trees of Section 7.4. It therefore does not currently meet RSP-Multi as defined in this revision. Stating this is unwelcome and necessary. A specification whose implementation status section implies conformance that does not exist misleads exactly the readers most likely to rely on it. 24.3. Reference Records Records issued through the reference deployment include: * REMID:2026.0328/e39dd6db, DOI 10.5281/zenodo.19299622, anchored 2026-03-28. * DOI 10.5281/zenodo.19192612, anchored 2026-03-23. Revision -01 listed this record's REMID as "zenodo/19192612", which is not a REMID in the format defined by [REM02]; the record has an identifier but -01 recorded the wrong field. The anchor state of these records at the time -01 was published was not recorded. Under Section 9.2 of this revision it MUST be, and implementers reproducing these examples SHOULD confirm attestation state and block height before relying on them. 24.4. Planned Work Reference implementations of CPO 2.0 generation and verification, the Section 7 Merkle construction, and the Section 17 Revocation Registry are planned. The test vectors in Appendix I are computed from the specification in this document and provide a target for that work. 25. References 25.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, . [RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type Structured Syntax Suffixes", RFC 6839, DOI 10.17487/RFC6839, January 2013, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL)", RFC 8610, DOI 10.17487/RFC8610, June 2019, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . [RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. Sundblad, "Network Time Security for the Network Time Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . [RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE): Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053, August 2022, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . [FIPS180] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-4, DOI 10.6028/NIST.FIPS.180-4, August 2015. [FIPS202] National Institute of Standards and Technology, "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions", FIPS PUB 202, DOI 10.6028/NIST.FIPS.202, August 2015. [BLAKE3] O'Connor, J., Aumasson, J-P., Neves, S., and Z. Wilcox-O'Hearn, "BLAKE3: one function, fast everywhere", January 2020. 25.2. Informative References [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, . [RFC4998] Gondrom, T., Brandner, R., and U. Pordesch, "Evidence Record Syntax (ERS)", RFC 4998, DOI 10.17487/RFC4998, August 2007, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, December 2021, . [FIPS204] National Institute of Standards and Technology, "Module-Lattice-Based Digital Signature Standard", FIPS PUB 204, DOI 10.6028/NIST.FIPS.204, August 2024. [JOUX] Joux, A., "Multicollisions in Iterated Hash Functions. Application to Cascaded Constructions", Advances in Cryptology - CRYPTO 2004, LNCS 3152, pp. 306-316, 2004, DOI 10.1007/978-3-540-28628-8_19. [GROVER] Grover, L.K., "A fast quantum mechanical algorithm for database search", Proceedings of the 28th Annual ACM Symposium on Theory of Computing, pp. 212-219, 1996, DOI 10.1145/237814.237866. [SCITT] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", Work in Progress, Internet-Draft, draft-ietf-scitt-architecture, . [C2PA] Coalition for Content Provenance and Authenticity, "C2PA Specification", 2023. [OTS] Todd, P., "OpenTimestamps: Scalable, Trust-Minimized, Distributed Timestamping with Bitcoin", 2016, . [ROUGHTIME] Malhotra, A., Langley, A., and W. Ladd, "Roughtime", Work in Progress, Internet-Draft, draft-ietf-ntp-roughtime. [DATACITE] DataCite, "DataCite Metadata Schema Documentation", Version 4.5, 2024, . [RSP00] Reilly, L.J., "Reilly Sentinel Protocol (RSP)", Work in Progress, Internet-Draft, draft-reilly-sentinel-protocol-00, September 2025. [RSP01] Reilly, L.J., "Reilly Sentinel Protocol (RSP)", Work in Progress, Internet-Draft, draft-reilly-sentinel-protocol-01, March 2026. [REM02] Reilly, L.J., "Reilly EternaMark (REM) Protocol", Work in Progress, Internet-Draft, draft-reilly-rem-protocol-02, 2026, . [TFC01] Reilly, L.J., "The Triple-Fingerprint Permanence Chain and the First Attested Triple-Fingerprint Record Under the REM Protocol", Work in Progress, Internet-Draft, draft-reilly-rem-triple-fingerprint-01, 2026. [RRP02] Reilly, L.J., "Reilly Resilience Protocol (RRP)", Work in Progress, Internet-Draft, draft-reilly-resilience-protocol-02, 2026. [CTS01] Reilly, L.J., "Cognitive Trust Stack (CTS)", Work in Progress, Internet-Draft, draft-reilly-cts-01, 2026. [CBPI00] Reilly, L.J., "Cognitive Behavioral Provenance and Integrity (CBPI) for Autonomous AI Agents", Work in Progress, Internet-Draft, draft-reilly-cbpi-00, 2026. [AIGOV00] Reilly, L.J., "Verifiable AI Governance and Data Privacy Records", Work in Progress, Internet-Draft, draft-reilly-aigov-00, 2026. [BSP01] Reilly, L.J., "Bulk Subtree Consistency Proofs for Merkle Tree Certificates", Work in Progress, Internet-Draft, draft-reilly-plants-bulk-subtree-proofs-01, 2026. Appendix A. CDDL for CBOR SEP (v1.2) sep = { version: "1.2", alg_suite: alg_suite, artifact: { type: tstr }, ? payloads: [* payload], digests: digests, ? cpo_ref: tstr, timestamps: { wallclock: tstr, ; RFC 3339 ? monotonic: uint, ? source: tstr }, canonicalization: tstr, ; "jcs" or "cbor-det" ? authors: [* { name: tstr, ? id: tstr, ? orcid: tstr }], ? attestation: any, ? anchors: [* anchor], ids: { ? remid: tstr, ? doi: tstr, ? ipfs_cid: tstr, ? verification_url: tstr, ? lineage: { ? parent: [* tstr], ? siblings: [* tstr], ? supersedes: [* tstr] } }, ? commitments: { alg: tstr, root: tstr, fields: [+ tstr] }, ? agentic: agentic, ? federated: federated, ? class: any, ? policies: any, signatures: [+ any] ; at least one } alg_suite = { digest: [+ tstr], ; "sha-256","sha3-512","blake3" ? blake3_output_bits: uint ; required if blake3 present } ; keys MUST match alg_suite.digest exactly digests = { * tstr => tstr, ? chunked: bool } anchor = { class: tstr, target: tstr, value_anchored: tstr, ; "braid" or "handle" state: "pending" / "attested", ? receipt_ref: tstr, ? block_height: uint, ; present iff state="attested" ? obtained_at: tstr } agentic = { session_id: tstr, agent_id: tstr, model_id: tstr, action_count: uint, merkle_roots: { * tstr => tstr }, ? actions: [* action_record] } action_record = { seq: uint, timestamp: tstr, action_type: tstr, commitment_root: tstr, ? tool_id: tstr, ? parent_seq: uint, ? attestation_ref: tstr } federated = { round_id: tstr, aggregation_id: tstr, participant_count: uint, update_roots: { * tstr => tstr }, global_model_id: tstr, privacy_mechanism: tstr, ? privacy_parameters: { * tstr => any } } payload = { cid: tstr, size: uint, ? mime: tstr, ? chunking: tstr } Appendix B. Example JSON SEP (Non-normative) { "version": "1.2", "alg_suite": { "digest": ["sha-256", "sha3-512", "blake3"], "blake3_output_bits": 256 }, "artifact": {"type": "training.checkpoint"}, "digests": { "sha-256": "<64 hex>", "sha3-512": "<128 hex>", "blake3": "<64 hex>", "chunked": false }, "cpo_ref": "urn:rsp:cpo:/", "canonicalization": "jcs", "timestamps": {"wallclock": "2026-08-24T00:00:00Z", "source": "nts"}, "anchors": [ {"class": "bitcoin-ots", "target": "bitcoin", "value_anchored": "handle", "state": "attested", "block_height": 0, "obtained_at": "2026-08-24T06:00:00Z"} ], "ids": { "remid": "REMID:2026.0824/3f2a9c14", "doi": "10.5281/zenodo.example", "ipfs_cid": "bafkrei...", "lineage": {} }, "signatures": [{"type": "COSE_Sign1", "value": "..."}] } Appendix C. Verification Report (Non-normative) { "construction_version": "2.0", "algorithms_checked": ["sha-256", "sha3-512", "blake3"], "digest_ok": {"sha-256": true, "sha3-512": true, "blake3": true}, "ctx_ok": true, "link_ok": {"sha-256": true, "sha3-512": true, "blake3": true}, "braid_ok": true, "chain_ok": true, "sig_ok": true, "attestation_ok": true, "anchors": [{"class": "bitcoin-ots", "state": "attested", "block_height": 0, "verified": true}], "time_ok": true, "identifier_ok": true, "content_ok": true, "revocation_status": "not_revoked", "overall": "VERIFIED", "verified_at": "2026-08-24T12:00:00Z" } Appendix D. Anchoring Notes (Non-normative) Timestamp receipts include commitment operations and attestations enabling independent reconstruction of inclusion in a public chain. Under this revision the anchored value is the braid or its submission handle (Section 6.6), not a single derived binding hash. Section 9.4 explains why submitting a longer digest does not confer that digest's strength on the anchoring aggregation. Appendix E. Persistent Identifier Metadata Mapping (Non-normative) title: "Example AI Training Checkpoint" creators: [{"name": "..."}] created: "2026-08-24T00:00:00Z" alg_suite: ["sha-256", "sha3-512", "blake3"] fixity: sha-256: "<64 hex>" sha3-512: "<128 hex>" blake3: "<64 hex>" braid: "<256 hex>" rem_id: "REMID:2026.0824/3f2a9c14" ipfs_cid: "bafkrei..." Appendix F. CPO 2.0 Format See Section 6.5 for the normative structure. The invariants a verifier MUST check: * h_ctx equals SHA3-512(0x00 || lp(record_id) || lp(remid) || lp(created_at)). * M is 201 octets as constructed in Section 6.2. * Each link equals its algorithm applied to 0x02 || prev_braid || M. * braid equals the ordered concatenation of the links. * prev_braid equals the predecessor's braid, or 128 zero octets at seq 0. * No cross_chain_hash field is present. Appendix G. Agentic Action Log Example (Non-normative) { "version": "1.2", "alg_suite": {"digest": ["sha-256","sha3-512","blake3"], "blake3_output_bits": 256}, "artifact": {"type": "agentic.action.log"}, "agentic": { "session_id": "sess-20260824-001", "agent_id": "example-agent-v1.0", "model_id": "", "action_count": 13, "merkle_roots": { "sha-256": "<64 hex>", "sha3-512": "<128 hex>", "blake3": "<64 hex>" }, "actions": [ { "seq": 1, "timestamp": "2026-08-24T21:06:00Z", "action_type": "inference", "commitment_root": "<128 hex>", "tool_id": "example:rewrite", "parent_seq": null } ] } } Note that input and output values do not appear. They are committed with salts per Section 14.4 and disclosed selectively. Appendix H. Change Log Changes from draft-reilly-sentinel-protocol-01 to -02: H.1 Cross-chain binding replaced (Sections 1.1.1, 6). The SHA3-512-only binding hash over an unframed concatenation is removed. Replaced by entangled links over a fixed-length framed input and a concatenated braid. CPO version 2.0; cross_chain_hash removed and prohibited. H.2 Security figures corrected (Sections 1.1.2, 5.2). Grover no longer applied to collision resistance. SHA-256 collision resistance stated as 128 bits. The claim that Grover applies less efficiently to SHA-3 is withdrawn. H.3 Combined security claim corrected (Sections 1.1.3, 5.3) following [JOUX]. Hedging rather than addition, with an explicit prohibition on additive claims. H.4 Merkle construction specified (Sections 1.1.4, 7) per [RFC6962], normatively, for all five uses that -01 left unspecified. Per-algorithm trees required. H.5 Salted commitments replace digest-only disclosure (Sections 1.1.5, 14.4). H.6 Automated repair of integrity violations prohibited (Sections 1.1.6, 11.3, 22.8). H.7 Revocation Registry added (Section 17). Revision -01's direction to check revocation "against the chain record" was not an executable procedure. H.8 Pending and attested anchor states distinguished (Section 9.2), with block height required for attested anchors and pending anchors barred from a VERIFIED verdict. H.9 Section 9.4 added, stating that OTS aggregation is SHA-256 regardless of the submitted value, correcting the implication in -01 that anchoring a SHA3-512 value made the anchor quantum-resilient. H.10 alg_suite replaces the quantum_resilient boolean (Section 4). BLAKE3 output length must be declared. H.11 The 'rem' object is renamed 'ids' (Sections 4, 11.1), since none of its fields are REM-specific. H.12 Federated learning privacy claims corrected (Section 16.3). privacy_parameters required for DP mechanisms. H.13 Time claims corrected (Section 22.2): NTS authenticates the source, not the producer; only the attested anchor is an externally verifiable bound. H.14 Quantum exposure of signatures addressed (Sections 5.4, 22.3), which -01 omitted entirely while devoting a section to quantum threats against hashing. H.15 Conformance levels reconciled with the CDDL (Section 18.2). RSP-Quantum renamed RSP-Multi. Appendix A CDDL corrected: signatures is now a non-empty array; digests is keyed by declared algorithm. H.16 Media type templates completed per [RFC6838] (Section 23). charset parameter removed from the JSON types. H.17 Verification algorithm expanded (Section 13) to thirteen checks plus report requirements, including algorithms_checked and construction_version. H.18 Error codes added (Section 19) for the new failure modes. H.19 Copyright Notice now includes the Code Components paragraph, which -01 omitted despite containing CDDL. Stream designation corrected from "Independent Submission". H.20 Implementation status corrected (Section 24), including that the reference deployment does not currently meet RSP-Multi, the endpoint migration, and the malformed REMID recorded in -01 Section 22.2. H.21 References updated: [REM02], [CTS01], [RRP02] replace earlier revisions; [RFC6962], [RFC6838], [RFC3552], [RFC4998], [RFC9162], [FIPS180], [FIPS202], [FIPS204], [JOUX], [GROVER], [BSP01], [TFC01], [CBPI00], [AIGOV00] added; [SCITT] and [ROUGHTIME] cited as drafts rather than as a charter and an incomplete entry. H.22 Appendix I added with chain test vectors. Appendix I. Chain Test Vectors These vectors are computed from the construction of Section 6 and are reproducible by any implementer. They use placeholder digests so that the vectors exercise the framing and domain separation rather than any particular artifact. Inputs: seq = 0 digest sha-256 = aa repeated 32 times digest sha3-512= bb repeated 64 times digest blake3 = cc repeated 32 times record_id = 3f2a9c14-7e50-4b8d-9a61-0d5e2c884b17 remid = REMID:2026.0824/3f2a9c14 created_at = 2026-08-24T00:00:00Z prev_braid = 128 octets of 0x00 H_ctx = SHA3-512(0x00 || lp(record_id) || lp(remid) || lp(created_at)), 64 octets: e6dd40d546b287239230ea843c1fb0f7d49b4cb47497b6ac2185df0470e1 50d57dd228c689f8c8864915eefe43fb07813128682706af425f32229e31 877facad M = 0x01 || uint64be(0) || digests || H_ctx, 201 octets. Link input = 0x02 || prev_braid || M, 330 octets. L_sha256, 32 octets: b6484f304c732c58e6d38e3a4bcb906f295290def841350eff35915e6e86 a6e2 L_sha3, 64 octets: 0d9afb4490e57631eb063d64300f87ce7a7fae38de1aa6f9cb52abee6ebd 30d8f452a6bf87aeef6873292dd8eff36aa29178864f46f1f9851241068a 2fbc79a5 L_blake3, 32 octets at 256-bit output: 44afab491cb1305628926de3c9c1602caa373ff6e59e16416df2c049aab6 2d7a braid = L_sha256 || L_sha3 || L_blake3, 128 octets. An implementation that cannot reproduce all three link values has a framing, encoding, or domain-separation error. The most common causes are omitting the 4-octet length prefixes in lp(), omitting a domain separation octet, and encoding the sequence number at a width other than eight octets. Acknowledgments The author acknowledges the work of the IETF SCITT working group, the OpenTimestamps community, the Certificate Transparency authors whose Merkle construction this revision adopts, and the DataCite consortium. The defects corrected in this revision were the author's own. Author's Address Lawrence John Reilly Jr. REM Technologies & Consulting, LLC Email: lawrencejohnreilly@gmail.com IETF Datatracker: https://datatracker.ietf.org/person/lawrencejohnreilly@gmail.com Live System: https://remweb4.org/