Reilly Sentinel Protocol (RSP): Blockchain-Anchored Integrity for AI Datasets, Training, Fine-Tuning, and Inference Provenance
draft-reilly-sentinel-protocol-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Lawrence John Reilly Jr | ||
| Last updated | 2026-08-24 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-reilly-sentinel-protocol-02
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": "<stable chain identifier>",
"seq": <uint>,
"record_id": "<uuid>",
"created_at": "<RFC3339 UTC>",
"alg_suite": { "digest": ["sha-256","sha3-512","blake3"],
"blake3_output_bits": 256 },
"h_ctx": "<hex, 64 octets>",
"digests": { "sha-256": "<hex>", "sha3-512": "<hex>",
"blake3": "<hex>" },
"prev_braid": "<hex, 128 octets>",
"links": { "sha-256": "<hex>", "sha3-512": "<hex>",
"blake3": "<hex>" },
"braid": "<hex, 128 octets>",
"anchors": [ { "class": "...", "value_anchored": "braid",
"state": "attested", "block_height": <uint> } ],
"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 <lawrencejohnreilly@gmail.com>
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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339,
DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)",
STD 70, RFC 5652, DOI 10.17487/RFC5652,
September 2009,
<https://www.rfc-editor.org/info/rfc5652>.
[RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type
Structured Syntax Suffixes", RFC 6839,
DOI 10.17487/RFC6839, January 2013,
<https://www.rfc-editor.org/info/rfc6839>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962,
June 2013,
<https://www.rfc-editor.org/info/rfc6962>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
RFC 2119 Key Words", BCP 14, RFC 8174,
DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON)
Data Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise
Data Definition Language (CDDL)", RFC 8610,
DOI 10.17487/RFC8610, June 2019,
<https://www.rfc-editor.org/info/rfc8610>.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785,
DOI 10.17487/RFC8785, June 2020,
<https://www.rfc-editor.org/info/rfc8785>.
[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,
<https://www.rfc-editor.org/info/rfc8915>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption
(COSE): Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/info/rfc9052>.
[RFC9053] Schaad, J., "CBOR Object Signing and Encryption
(COSE): Initial Algorithms", RFC 9053,
DOI 10.17487/RFC9053, August 2022,
<https://www.rfc-editor.org/info/rfc9053>.
[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,
<https://www.rfc-editor.org/info/rfc9334>.
[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,
<https://www.rfc-editor.org/info/rfc3552>.
[RFC4998] Gondrom, T., Brandner, R., and U. Pordesch, "Evidence
Record Syntax (ERS)", RFC 4998,
DOI 10.17487/RFC4998, August 2007,
<https://www.rfc-editor.org/info/rfc4998>.
[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,
<https://www.rfc-editor.org/info/rfc7942>.
[RFC9162] Laurie, B., Messeri, E., and R. Stradling,
"Certificate Transparency Version 2.0", RFC 9162,
DOI 10.17487/RFC9162, December 2021,
<https://www.rfc-editor.org/info/rfc9162>.
[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,
<https://datatracker.ietf.org/doc/
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,
<https://opentimestamps.org>.
[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, <https://schema.datacite.org>.
[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,
<https://datatracker.ietf.org/doc/
draft-reilly-rem-protocol/>.
[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:<chain_id>/<seq>",
"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": "<model identifier>",
"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/