Reilly Government Integrity Protocol (RGIP): Multi-Layer, Quantum-Resilient Framework for Permanent and Tamper-Evident Public Records
draft-reilly-government-integrity-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-09-04 | ||
| 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-government-integrity-02
Network Working Group L.J. Reilly
Internet-Draft REM Technologies & Consulting, LLC
Intended status: Informational 4 September 2026
Expires: 8 March 2027
Reilly Government Integrity Protocol (RGIP): Multi-Layer,
Quantum-Resilient Framework for Permanent and Tamper-Evident Public
Records
draft-reilly-government-integrity-02
Abstract
The Reilly Government Integrity Protocol (RGIP) defines a
standards-aligned method for producing permanent, independently
verifiable public records by combining multi-algorithm content
hashing, public timestamp anchoring, archival deposit under a
persistent identifier, decentralized storage, and web archiving into
a single pipeline.
This revision corrects defects in
draft-reilly-government-integrity-01 that would have prevented
independent verification or overstated the guarantees the protocol
provides. It replaces the -01 SHA3-512-only Cross-Chain Hash, which
made a single algorithm the sole binding of three otherwise
independent chains, with an entangled link-and-braid construction in
which each chain consumes the prior state of all three. It defines a
canonical, domain-separated, length-delimited encoding for every
hashed input, removing the concatenation ambiguity present in -01.
It separates the signed Evidence Receipt Core from the mutable anchor
envelope, resolving the -01 condition in which confirming an anchor
invalidated the signature over the record it described. It adds
Chain Checkpoint anchoring, without which the -01 claim that record
sequence is provable did not hold, since -01 anchored only artifact
digests and never the chain itself. It replaces raw digests of
low-entropy government records with salted field commitments, adds
explicit pending and attested anchor states, adds a Revocation
Registry and Hash Migration Bridging Records, replaces the
quantum_resilient boolean with a declared algorithm suite, prohibits
automated repair of chain integrity violations, and narrows the -01
post-quantum claims to what the constructions support. It also
documents the function of RGIP records and of this specification as
prior art records under 35 U.S.C. 102(a)(1), consistent with the
treatment in version -02 of the REM Protocol specification.
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
Reilly Expires 8 March 2027 [Page 1]
Internet-Draft Reilly Government Integrity Protocol September 2026
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 8 March 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Changes in This Revision . . . . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Protocol Goals and Non-Goals . . . . . . . . . . . . . . . . . 8
4. High-Level Overview . . . . . . . . . . . . . . . . . . . . . 9
5. Government Use Cases . . . . . . . . . . . . . . . . . . . . 10
5.1. Legislative and Regulatory Records . . . . . . . . . . 10
5.2. Procurement and Contracting . . . . . . . . . . . . . 10
5.3. Financial and Budget Records . . . . . . . . . . . . . 11
5.4. Judicial Records . . . . . . . . . . . . . . . . . . . 11
5.5. Intelligence and National Security Records . . . . . . 11
5.6. Election Administration . . . . . . . . . . . . . . . 12
5.7. Constraints Common to All Use Cases . . . . . . . . . 12
6. Canonical Encoding and Domain Separation . . . . . . . . . . 13
7. Entangled Triple-Hash Chain Architecture . . . . . . . . . . 14
7.1. Algorithm Suite . . . . . . . . . . . . . . . . . . . 14
7.2. Artifact Fingerprint . . . . . . . . . . . . . . . . . 14
7.3. Link Construction . . . . . . . . . . . . . . . . . . 15
7.4. Braid Construction . . . . . . . . . . . . . . . . . . 15
Reilly Expires 8 March 2027 [Page 2]
Internet-Draft Reilly Government Integrity Protocol September 2026
7.5. Genesis Block . . . . . . . . . . . . . . . . . . . . 16
7.6. Chain Integrity Verification . . . . . . . . . . . . . 16
7.7. Security Properties and Limits . . . . . . . . . . . . 17
8. REMID: Content-Derived Artifact Identifier . . . . . . . . . 17
8.1. Format and Derivation . . . . . . . . . . . . . . . . 18
8.2. Collision Handling . . . . . . . . . . . . . . . . . . 18
8.3. Properties and Limits . . . . . . . . . . . . . . . . 18
8.4. REMID Resolver . . . . . . . . . . . . . . . . . . . . 19
9. Field Commitments and Selective Disclosure . . . . . . . . . 19
10. Evidence Receipt (ER) Data Model . . . . . . . . . . . . . . 20
10.1. ER Core (Signed) . . . . . . . . . . . . . . . . . . 20
10.2. ER Envelope (Mutable) . . . . . . . . . . . . . . . . 21
10.3. Field Notes . . . . . . . . . . . . . . . . . . . . . 23
10.4. Version and Compatibility . . . . . . . . . . . . . . 23
11. Permanence Layer Stack . . . . . . . . . . . . . . . . . . . 23
11.1. Anchor States . . . . . . . . . . . . . . . . . . . . 23
11.2. Timestamp Anchoring via OpenTimestamps . . . . . . . 24
11.3. Chain Checkpoint Anchoring . . . . . . . . . . . . . 24
11.4. Decentralized Storage via IPFS . . . . . . . . . . . 25
11.5. Archival Deposit and DOI Issuance . . . . . . . . . . 25
11.6. Web Archival . . . . . . . . . . . . . . . . . . . . 26
12. Step-by-Step Implementation (Normative) . . . . . . . . . . 26
13. Verification Procedure (Normative) . . . . . . . . . . . . . 28
14. Amendment, Supersession, and Revocation . . . . . . . . . . 29
14.1. Amendment Records . . . . . . . . . . . . . . . . . . 29
14.2. Revocation Registry . . . . . . . . . . . . . . . . . 29
14.3. Retention and Disposition . . . . . . . . . . . . . . 30
15. Hash Migration Bridging Records . . . . . . . . . . . . . . 30
16. Autonomous Agent Architecture . . . . . . . . . . . . . . . 31
16.1. Agent Roles . . . . . . . . . . . . . . . . . . . . . 31
16.2. Blast Radius and Oversight . . . . . . . . . . . . . 32
16.3. Prohibited Automated Actions . . . . . . . . . . . . 33
17. Operational Considerations . . . . . . . . . . . . . . . . . 33
18. Security Considerations . . . . . . . . . . . . . . . . . . 34
19. Post-Quantum Considerations . . . . . . . . . . . . . . . . 35
20. Privacy Considerations . . . . . . . . . . . . . . . . . . . 37
21. Prior Art Record Function . . . . . . . . . . . . . . . . . 37
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . 38
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
23.1. Normative References . . . . . . . . . . . . . . . . 38
23.2. Informative References . . . . . . . . . . . . . . . 40
Appendix A. Changes from draft-reilly-government-integrity-01 . 41
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 44
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction
Public institutions produce records whose integrity is foundational
Reilly Expires 8 March 2027 [Page 3]
Internet-Draft Reilly Government Integrity Protocol September 2026
to democratic governance, legal accountability, and public trust.
Legislative acts, regulatory filings, judicial decisions, agency
rulemakings, procurement records, budget authorizations, and
intelligence assessments all depend on an unbroken chain of custody
from the moment of creation. When that chain is interrupted, whether
by accident, negligence, or deliberate suppression, the record loses
its evidentiary value and public accountability fails.
Existing mechanisms for establishing record permanence are
structurally insufficient. Institutional custody concentrates
control in the entity whose conduct the record is meant to document.
Paper archives are subject to physical destruction. Certified copies
depend on the integrity of the certifying authority. Digital records
stored in government-controlled systems are alterable by the same
administrators who produce them. None of these mechanisms provides
independently verifiable proof that a record existed at a specific
moment and has not been modified since.
RGIP addresses this structural gap by anchoring government records to
infrastructure that no single institution controls. A public
timestamping layer provides an observation of existence that cannot
be revised without recomputing the underlying consensus.
Content-addressed storage provides retrievability independent of any
hosting provider. Archival deposit under a persistent identifier
provides a citable reference maintained by an institution distinct
from the record's originator. Web archival provides an additional
independent crawl. Together these layers ensure that no single point
of failure, and no single institutional actor, can silently suppress
or alter a record that has been processed through RGIP.
RGIP does not mandate a legal framework, evidentiary standard, or
regulatory standing for anchored records. It provides cryptographic
infrastructure on which such frameworks may rely. Whether a record
produced under RGIP is admissible, authoritative, or dispositive in
any proceeding is determined by the applicable forum and not by this
specification.
1.1. Changes in This Revision
Revision -00 [RGIP00] established a single-hash pipeline. Revision
-01 introduced a triple-hash chain, the REMID, a four-layer
permanence stack, and an autonomous agent architecture. Several of
its constructions did not deliver the properties claimed for them.
This revision corrects them.
1. Binding of the three chains. In -01, the three chains were bound
solely by a SHA3-512 Cross-Chain Hash computed over their
outputs. An adversary able to forge SHA3-512 could forge the
Reilly Expires 8 March 2027 [Page 4]
Internet-Draft Reilly Government Integrity Protocol September 2026
binding, and the three chains were otherwise mutually
independent, so the construction did not require defeating all
three algorithms as -01 claimed. Section 7 replaces it with an
entangled link-and-braid construction in which every chain
consumes the prior Braid, and the Braid is computed under all
three algorithms rather than one.
2. Hashed-input ambiguity. Revision -01 concatenated
variable-length text fields with no separator, length prefix, or
domain tag, so distinct field assignments could produce identical
preimages. Section 6 defines a canonical, domain-separated,
length-delimited encoding that every hashed input MUST use.
3. Signature and anchor circularity. In -01 the signature covered
the whole Evidence Receipt, including permanence fields that
change when a pending anchor is later confirmed. Updating
permanence.bitcoin.status from "pending" to "confirmed"
invalidated the signature over the record it described.
Section 10 separates a signed, immutable ER Core from a mutable
ER Envelope carrying anchor and archival state.
4. Unanchored chain. Revision -01 submitted only the artifact
SHA-256 digest to OpenTimestamps. Nothing external committed to
chain state, so an operator could rebuild the entire chain in a
different order and every artifact timestamp would still verify.
The -01 assertion that procurement record sequence "cannot be
forged" did not follow. Section 11.3 adds Chain Checkpoint
anchoring, and Section 5.7 states the ordering guarantee in terms
of what Checkpoints actually establish.
5. Missing verification inputs. The -01 chain hashes consumed
record_id, but record_id was not a field of the -01 Evidence
Receipt, so a third party could not recompute the chain hashes
from a published ER. Section 10.1 makes record_id a required ER
Core field and requires that the OTS proof bytes needed by
verification be carried or referenced by the ER.
6. Low-entropy artifact exposure. Government records frequently
have low entropy: ballot definitions drawn from a known set,
voter records over known name and address spaces, form-based
filings. Publishing a raw digest of such an artifact lets an
adversary confirm its content by enumeration. Section 9
introduces salted Field Commitments, and Section 20 prohibits
anchoring raw digests of low-entropy or access-controlled
artifacts.
7. REMID self-contradiction. Revision -01 declared the REMID
deterministic and simultaneously directed implementations to
Reilly Expires 8 March 2027 [Page 5]
Internet-Draft Reilly Government Integrity Protocol September 2026
append additional hash characters on collision, which makes it
non-deterministic and unreproducible by a Verifier. Section 8.2
defines a deterministic collision rule. Section 8.3 restates the
collision bound, which -01 gave as a per-pair probability where a
birthday bound applies.
8. Overstated post-quantum claims. Revision -01 asserted a quantum
speedup exploiting the Merkle-Damgard structure of SHA-2, which
is not a known result, and garbled the security levels of BLAKE3.
Section 19 states the classical and quantum levels each algorithm
supports and identifies what remains unaddressed, notably the
signature algorithm.
9. Self-asserted properties. The -01 chain object carried a
quantum_resilient boolean, which a Verifier cannot check and
which conveys the Producer's opinion rather than a fact about the
record. It is replaced by an alg_suite identifier naming the
algorithms actually used.
10. Governance of automated action. The -01 agent architecture let a
self-heal agent act on any degraded layer without constraint,
including, on its face, chain integrity findings. Section 16
classifies agent actions by blast radius and prohibits automated
remediation of chain integrity violations.
This revision also adds a Revocation Registry (Section 14.2), Hash
Migration Bridging Records (Section 15), retention and disposition
guidance for records subject to statutory schedules (Section 14.3),
and a prior art record section (Section 21). Internal
cross-references, which were misnumbered throughout -01, and several
passages duplicated by editing error, have been corrected.
1.2. Requirements Language
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.
2. Terminology
Artifact: The public record content being made permanent (e.g.,
PDF, text, JSON, image, or document bundle).
Fingerprint: The ordered triple of digests (SHA-256, SHA3-512,
BLAKE3-256) of an Artifact's canonical byte stream.
Reilly Expires 8 March 2027 [Page 6]
Internet-Draft Reilly Government Integrity Protocol September 2026
Link: The per-algorithm chain value at a block, computed
over the prior Braid and the current block inputs
(Section 7.3).
Braid: The ordered triple of digests committing to all three
Links at a block, computed under all three algorithms
(Section 7.4). The Braid replaces the -01 Cross-Chain
Hash.
Block: A single entry in an RGIP chain, corresponding to one
Artifact submission, amendment, revocation, or
bridging record.
Genesis Block: The first block of an RGIP chain, whose prior Braid is
the all-zeros Braid of Section 7.5.
Chain Head: The Braid of the highest-indexed block in a chain.
Checkpoint: A commitment to a Chain Head submitted to the
timestamp layer, establishing that the chain held that
state no later than an observed time (Section 11.3).
REMID: Reilly EternaMark Identifier. A content-derived
persistent identifier for an Artifact, in the
namespace REMID:YYYY.MMDD/<hash8> (Section 8).
ER: Evidence Receipt. The record object defined in
Section 10, consisting of an ER Core and an ER
Envelope.
ER Core: The immutable, signed portion of an ER.
ER Envelope: The mutable portion of an ER carrying anchor and
archival state. Not covered by the Core signature.
Field Commitment:
A salted digest over a single field value, published
in place of the value where the value is sensitive or
low-entropy (Section 9).
Anchor: The submission of a digest to a public timestamping
service, and its subsequent attestation.
Pending Anchor:
An anchor submitted to a calendar or aggregator but
not yet committed to a public consensus record. A
pending anchor is a receipt of submission, not
evidence of time (Section 11.1).
Reilly Expires 8 March 2027 [Page 7]
Internet-Draft Reilly Government Integrity Protocol September 2026
Attested Anchor:
An anchor whose proof resolves to a committed public
consensus record, establishing an upper bound on the
time at which the digest existed.
CID: Content Identifier per IPFS content addressing
[IPFS-SPEC].
DOI: Digital Object Identifier resolving to an archival
landing page for the Artifact.
OTS Proof: An OpenTimestamps [OTS] proof linking a digest to a
Bitcoin block header via a Merkle path.
ni URI: A content-hash URI per [RFC6920].
Producer: The entity operating an RGIP pipeline and issuing ERs.
Verifier: Any party checking an ER against the Artifact and the
permanence layers. A Verifier is assumed to trust
neither the Producer nor the record's originating
agency.
3. Protocol Goals and Non-Goals
Goals
* Binding each Artifact to a fingerprint under three structurally
independent hash functions.
* Chaining Artifacts in a sequence such that retrospective
alteration is detectable by any Verifier holding a later
Checkpoint.
* Anchoring both individual Artifacts and periodic Chain Heads to a
public timestamping layer controlled by no participant in the
record's subject matter.
* Distributing Artifacts and their metadata across independent
permanence layers, such that loss of any one layer does not
destroy verifiability.
* Permitting verification of a record without disclosing sensitive
or statutorily protected field values.
* Supporting continuous automated verification while keeping
integrity findings under human authority.
Reilly Expires 8 March 2027 [Page 8]
Internet-Draft Reilly Government Integrity Protocol September 2026
Non-Goals
* Mandating a specific timestamping service beyond naming Bitcoin
OpenTimestamps as the RECOMMENDED anchor.
* Defining new cryptographic primitives.
* Determining the legal, evidentiary, or regulatory standing of
records.
* Prescribing access control policy for Artifact content.
* Preventing destruction or non-production of a record. RGIP makes
alteration and backdating detectable; it does not make a record
available to a party the custodian refuses to serve, beyond the
copies distributed to the permanence layers at processing time.
* Establishing that a record is accurate, lawful, or complete. RGIP
establishes what was recorded and when, not whether what was
recorded was true.
4. High-Level Overview
A Producer processes an Artifact through the following pipeline:
(1) Determine the Artifact's canonical byte stream and compute its
Fingerprint under SHA-256, SHA3-512, and BLAKE3-256.
(2) Derive a REMID from the SHA-256 digest and the UTC submission
date (Section 8).
(3) Assemble the block inputs and encode them canonically per
Section 6.
(4) Compute the three Links over the prior Braid and the block
inputs, then compute the new Braid (Section 7).
(5) Where field values are sensitive or low-entropy, compute salted
Field Commitments and publish those in place of the values
(Section 9).
(6) Assemble and sign the ER Core.
(7) Submit the ER Core digest to the timestamp layer, obtaining a
pending anchor (Section 11.2).
(8) Pin the Artifact and ER to content-addressed storage, deposit
the Artifact for archival under a persistent identifier, and
Reilly Expires 8 March 2027 [Page 9]
Internet-Draft Reilly Government Integrity Protocol September 2026
submit the resolver URL for web archival. Record the results
in the ER Envelope.
(9) Publish the ER.
(10) On a defined cadence, submit a Checkpoint over the Chain Head
to the timestamp layer (Section 11.3).
(11) Monitor for anchor attestation and update the Envelope from
pending to attested when a proof resolves.
Verifiers retrieve the ER, recompute the Fingerprint and the chain
values, verify the Core signature, resolve each permanence layer
independently, and evaluate anchors under Section 11.1.
5. Government Use Cases
This section is informative. It illustrates application of RGIP to
government record categories. Section 5.7 states constraints that
apply to all of them and that were absent from -01.
5.1. Legislative and Regulatory Records
A legislative body or regulatory agency publishes a document: bill
text, a final rule, guidance, or a public notice. The agency
processes the document through RGIP at publication, producing an ER
whose Core digest is anchored, whose Artifact is pinned and
deposited, and whose resolver page is crawled.
A later claim that the document's content differs from the published
version is refutable by recomputing the Fingerprint. A later claim
that it was published earlier than it was is refutable by the
attested anchor, which establishes an upper bound on existence time.
An anchor does not establish a lower bound: it does not show that the
document did not exist earlier.
5.2. Procurement and Contracting
Procurement generates records that are frequently disputed:
solicitation language, proposal submissions, evaluation scores, and
award decisions. Each is processed at creation or receipt.
Ordering within the chain is established relative to Checkpoints.
Two blocks separated by an attested Checkpoint are ordered with
respect to that Checkpoint's observed time: the earlier block's
content was fixed before the Checkpoint was anchored. Blocks with no
intervening Checkpoint are ordered only by the Producer's own
assertion, since the Producer could have constructed both at any time
Reilly Expires 8 March 2027 [Page 10]
Internet-Draft Reilly Government Integrity Protocol September 2026
before the next Checkpoint. Agencies SHOULD therefore set the
Checkpoint cadence (Section 11.3) to the granularity at which
ordering disputes are expected to matter. For procurement, a
Checkpoint at each phase boundary is RECOMMENDED.
Audit agencies can verify the full chain without relying on the
contracting agency's internal systems, provided the ERs and the
Checkpoint proofs are published.
5.3. Financial and Budget Records
Appropriations, expenditure authorizations, and audit findings are
anchored at issuance. A retroactive amendment MUST create a new
block under Section 14.1; the original block remains in the chain and
the original Artifact remains retrievable via its REMID, persistent
identifier, and CID. Suppression of the original therefore requires
removing it from every permanence layer, each operated by a distinct
party.
5.4. Judicial Records
Filings, orders, and opinions processed at issuance carry a
tamper-evident record of content. This is relevant where a record is
later sealed, expunged, or amended and the fact and content of the
original is itself material.
Sealing and expungement raise a direct conflict with permanence. A
court order to destroy or seal a record cannot be satisfied by a
system that has published the Artifact to irrevocable public layers.
Deployments handling records subject to sealing MUST anchor Field
Commitments rather than the Artifact itself (Section 9), MUST NOT pin
or deposit the Artifact to public permanence layers, and MUST record
the anchoring mode in the ER Core. Section 14.3 addresses
disposition.
5.5. Intelligence and National Security Records
Assessments, briefings, and supporting evidence may be processed to
establish content at time of production, which is relevant to chain
of custody, inspector general oversight, and declassification review
where original content must be distinguishable from later revisions.
Classified and controlled unclassified material MUST NOT have its
Artifact digest anchored to a public timestamp layer. A digest is a
commitment: an adversary holding a candidate document can confirm it
by recomputation, and the anchor also discloses that a document
existed at a given time, which is itself frequently sensitive.
Deployments in this context MUST use salted commitments (Section 9),
Reilly Expires 8 March 2027 [Page 11]
Internet-Draft Reilly Government Integrity Protocol September 2026
MUST hold salts within the accreditation boundary, and SHOULD
consider whether the timing pattern of anchors is itself a
disclosure. Anchoring to a private or community-of-interest
timestamp service is a supported profile under Section 17 and
forfeits the independence property that public anchoring provides.
5.6. Election Administration
Ballot definitions, aggregate canvass reports, and configuration
state may be processed at defined intervals, creating an audit trail
verifiable without reliance on an election administrator's internal
systems.
Voter registration files MUST NOT be processed as raw Artifacts.
They contain personal data, they are low-entropy against known name
and address spaces, and in many jurisdictions their disclosure is
statutorily constrained. Where registration state must be anchored,
Producers MUST anchor a salted commitment over the file (Section 9)
and retain the salt under the same controls as the file.
Cast vote records MUST NOT be anchored in any form that could
associate a ballot with a voter. Where individual cast vote records
are anchored, block ordering MUST be randomized or batched so that
block index does not correspond to order of casting.
5.7. Constraints Common to All Use Cases
The following constraints apply to every case above and qualify
claims made without qualification in -01.
* An attested anchor establishes that a digest existed no later than
the observed time. It does not establish authorship, authority,
accuracy, or that no earlier version existed.
* Chain ordering is provable only relative to Checkpoints
(Section 11.3). Absent Checkpoints, an operator with control of
the datastore can reconstruct the entire chain in any order and
all per-artifact anchors will still verify.
* RGIP detects alteration of records it has processed. It does not
detect the non-creation of a record, the withholding of a record
from processing, or the selective processing of a subset. The
absence of a block is not evidence that no such record existed.
Where completeness matters, a deployment SHOULD publish periodic
completeness attestations enumerating the block range and count
covered, so that gaps are visible.
* Where an agency is both the record's subject and the operator of
Reilly Expires 8 March 2027 [Page 12]
Internet-Draft Reilly Government Integrity Protocol September 2026
the RGIP pipeline, the independence property comes from the
external layers, not from the pipeline. A Verifier SHOULD treat
unanchored, unpinned, or undeposited records from such a
deployment as unverified.
Deployments that present RGIP output to the public SHOULD state these
limits alongside the evidence.
6. Canonical Encoding and Domain Separation
Revision -01 formed hash inputs by concatenating UTF-8 strings with
no delimiter. Because several inputs are variable-length, distinct
assignments could produce the same preimage; for example, a
record_id ending in a digit followed by a timestamp is
indistinguishable from a longer record_id followed by a shorter
timestamp. This section removes that ambiguity and is normative.
Every hash input defined in this document MUST be constructed as:
ENC(label, f_1, f_2, ..., f_n) =
LP(label) || LP(f_1) || LP(f_2) || ... || LP(f_n)
where:
* LP(x) is the length-prefixed encoding of octet string x: an
eight-octet unsigned big-endian length, followed by the octets of
x.
* label is a US-ASCII domain separation tag drawn from the registry
in this section.
* Text fields are encoded as UTF-8 with Unicode Normalization Form C
applied before encoding.
* Digest fields are encoded as raw octets, not as hexadecimal text.
Where a digest is displayed in an ER, it is lowercase hexadecimal;
where it is hashed, it is the underlying octets.
* An absent OPTIONAL field is encoded as LP of the empty string. A
Producer MUST NOT omit the field from the sequence.
Domain separation tags defined by this document:
"RGIP/2/link/sha256" Section 7.3
"RGIP/2/link/sha3-512" Section 7.3
"RGIP/2/link/blake3" Section 7.3
"RGIP/2/braid/sha256" Section 7.4
"RGIP/2/braid/sha3-512" Section 7.4
Reilly Expires 8 March 2027 [Page 13]
Internet-Draft Reilly Government Integrity Protocol September 2026
"RGIP/2/braid/blake3" Section 7.4
"RGIP/2/core" Section 10.1
"RGIP/2/commit" Section 9
"RGIP/2/checkpoint" Section 11.3
"RGIP/2/bridge" Section 15
A digest computed under one tag is not a valid digest under any
other. Implementations MUST NOT reuse a tag for a purpose not
defined here, and a profile defining new constructions MUST allocate
tags under its own prefix.
All Artifact digests are taken over the Artifact's canonical byte
stream. For JSON Artifacts, the canonical byte stream is the JCS
[RFC8785] serialization. For all other media types, it is the exact
octet sequence published, and the Producer MUST NOT normalize,
re-encode, or re-compress it.
7. Entangled Triple-Hash Chain Architecture
RGIP maintains three chain values per block under three structurally
independent hash functions. Unlike -01, in which the chains ran in
parallel and met only at a single SHA3-512 binding value, each chain
in this revision consumes the prior state of all three.
7.1. Algorithm Suite
The algorithm suite REQUIRED by this document is designated
"rgip-2-a" and consists of:
SHA-256 [RFC6234], 32-octet output
SHA3-512 [FIPS202], 64-octet output
BLAKE3-256 [BLAKE3], 32-octet output in the default hash mode
with no key and no context string
Revision -01 did not fix the BLAKE3 output length, although BLAKE3 is
an extendable-output function and its genesis value in -01 implied
32 octets. This revision fixes it at 32 octets.
An ER MUST carry the suite identifier in core.alg_suite. This
replaces the -01 chain.quantum_resilient boolean, which asserted a
property no Verifier could check. A Verifier MUST reject an ER whose
alg_suite it does not implement, rather than attempting partial
verification.
7.2. Artifact Fingerprint
The Fingerprint of an Artifact A is the ordered triple:
Reilly Expires 8 March 2027 [Page 14]
Internet-Draft Reilly Government Integrity Protocol September 2026
FP(A) = ( SHA-256(A), SHA3-512(A), BLAKE3-256(A) )
computed over the canonical byte stream of Section 6. All three
digests MUST be computed; a Producer MUST NOT emit an ER carrying
fewer than three.
7.3. Link Construction
Let B(N-1) = (b256(N-1), b3(N-1), bb3(N-1)) be the prior Braid, and
let the block inputs be:
idx the block index, as an 8-octet unsigned big-endian
integer
rid the record_id (Section 10.1)
remid the REMID
created the RFC 3339 [RFC3339] creation timestamp, UTC
etype the event type
fp256,
fp3,
fpb3 the three Fingerprint digests, or, in commitment mode,
the corresponding Field Commitments (Section 9)
mode the anchoring mode, "artifact" or "commitment"
The three Links at block N are:
L256(N) = SHA-256( ENC("RGIP/2/link/sha256",
b256(N-1), b3(N-1), bb3(N-1),
idx, rid, remid, created, etype,
fp256, fp3, fpb3, mode) )
L3(N) = SHA3-512( ENC("RGIP/2/link/sha3-512",
b256(N-1), b3(N-1), bb3(N-1),
idx, rid, remid, created, etype,
fp256, fp3, fpb3, mode) )
Lb3(N) = BLAKE3-256( ENC("RGIP/2/link/blake3",
b256(N-1), b3(N-1), bb3(N-1),
idx, rid, remid, created, etype,
fp256, fp3, fpb3, mode) )
Each Link consumes all three prior Braid components. Consequently a
forgery under any single algorithm does not yield a consistent chain:
the forged value must reproduce inputs that the other two algorithms
also commit to.
7.4. Braid Construction
The Braid at block N is the ordered triple:
Reilly Expires 8 March 2027 [Page 15]
Internet-Draft Reilly Government Integrity Protocol September 2026
b256(N) = SHA-256( ENC("RGIP/2/braid/sha256",
L256(N), L3(N), Lb3(N)) )
b3(N) = SHA3-512( ENC("RGIP/2/braid/sha3-512",
L256(N), L3(N), Lb3(N)) )
bb3(N) = BLAKE3-256( ENC("RGIP/2/braid/blake3",
L256(N), L3(N), Lb3(N)) )
B(N) = ( b256(N), b3(N), bb3(N) )
The -01 Cross-Chain Hash used SHA3-512 alone as the outer function.
That made SHA3-512 a single point of algorithmic failure for the
binding: an adversary with a SHA3-512 collision could bind an
inconsistent set of chain values. Computing the Braid under all
three algorithms removes that property. A Verifier MUST check all
three Braid components; checking one is not a summary of the others
and MUST NOT be presented as one.
7.5. Genesis Block
For the Genesis Block, B(-1) is the all-zeros Braid:
b256(-1) = 32 octets of 0x00
b3(-1) = 64 octets of 0x00
bb3(-1) = 32 octets of 0x00
A chain MUST have exactly one Genesis Block. Its block index MUST be
0. A Producer operating multiple chains MUST give each a distinct
chain identifier carried in core.chain_id, and MUST NOT interleave
blocks from different chains in one index space.
7.6. Chain Integrity Verification
For each block N under verification, a Verifier MUST:
1. Recompute L256(N), L3(N), and Lb3(N) per Section 7.3 from the
published block inputs and the prior Braid, and compare each to
the stored value.
2. Recompute b256(N), b3(N), and bb3(N) per Section 7.4 from the
recomputed Links, and compare each to the stored value.
3. Confirm that the block's prior Braid fields equal the stored
Braid of block N-1 componentwise.
4. Confirm that the Genesis Block's prior Braid is the all-zeros
Braid of Section 7.5 and that its index is 0.
Reilly Expires 8 March 2027 [Page 16]
Internet-Draft Reilly Government Integrity Protocol September 2026
5. Confirm that block indices are contiguous over the range
verified, with no gaps.
Verification MUST fail if any comparison does not match. Partial
verification, meaning verification of fewer than all six values per
block, MUST NOT be reported as verification. A tool offering a
reduced check MUST label its output as a partial check and MUST name
the values omitted.
Verification of chain integrity alone establishes internal
consistency. It does not establish when the chain was constructed.
That requires Checkpoints (Section 11.3).
7.7. Security Properties and Limits
The construction provides:
* Detection of any modification to a block's inputs, which changes
that block's Links and Braid and every subsequent block's values.
* Resistance to forgery under compromise of any single hash
function, since a consistent chain requires all three Links and
all three Braid components to agree on the same inputs.
It does not provide:
* Proof of ordering absent Checkpoints, as stated in Section 5.7.
* Protection against a Producer who constructs a self-consistent
chain from the start with fabricated timestamps. Only an attested
anchor constrains that.
* Protection against omission. A chain can be internally perfect
and materially incomplete.
Revision -01 claimed the construction "converts three independent
attack problems into one simultaneous multi-algorithm problem". That
claim was not supported by the -01 construction, in which the chains
did not consume one another. It is supported by the construction in
this section, with the qualification that the security of the
ensemble is bounded by the strongest of the three functions, not by
their sum: the ensemble survives the failure of any two, but no
composition of hash functions exceeds the security of its strongest
member against an adversary who has broken none of them.
8. REMID: Content-Derived Artifact Identifier
The REMID is a persistent identifier derived from Artifact content
Reilly Expires 8 March 2027 [Page 17]
Internet-Draft Reilly Government Integrity Protocol September 2026
and submission date. It does not depend on a registrar, certificate
authority, or naming authority. Revision -01 described it as
"self-sovereign"; this revision uses "content-derived", which states
the property without implying a governance claim.
8.1. Format and Derivation
REMID:YYYY.MMDD/<sha256_prefix8>[.<disambiguator>]
where YYYY, MM, and DD are the UTC year, month, and day of
submission, and sha256_prefix8 is the first eight lowercase
hexadecimal characters, that is the first four octets, of the
Artifact's SHA-256 digest. In commitment mode (Section 9), the
prefix is taken from the salted commitment rather than from the
Artifact digest, so that the REMID does not leak a searchable
fragment of the Artifact digest.
Example:
REMID:2026.0904/3e48edc8
8.2. Collision Handling
Revision -01 directed implementations encountering a collision to
"append additional hash characters", without specifying how many or
how a Verifier would know. That rule made the REMID
non-reproducible. This revision replaces it.
If, within a single chain and a single UTC date, a newly derived
REMID equals an already-issued REMID whose Artifact digest differs,
the Producer MUST append a disambiguator: a decimal integer,
beginning at 1, incremented for each further collision on that
prefix and date. The base form, with no disambiguator, is always the
first issuance.
A Verifier re-deriving a REMID computes the base form and MUST accept
an ER whose subject.remid is the base form or the base form with a
disambiguator. The disambiguator is not derivable from content, so a
Verifier MUST NOT treat its value as evidence of anything beyond
issuance order within that date, and MUST resolve identity by the
full Fingerprint, never by REMID alone.
8.3. Properties and Limits
* Deterministic to the base form. The base REMID for a given
Artifact submitted on a given UTC date is reproducible by any
party holding the Artifact.
Reilly Expires 8 March 2027 [Page 18]
Internet-Draft Reilly Government Integrity Protocol September 2026
* Content-derived. The embedded prefix permits fast matching
against the full digest but is not itself an identity check.
* Collision bound. The prefix is 32 bits. Revision -01 stated the
collision probability as "approximately 1 in 2^32", which is the
per-pair figure. The applicable bound over n Artifacts sharing a
date is the birthday bound: the probability of at least one
collision is approximately n^2 / 2^33, giving roughly even odds
near n = 77,000 and a one-in-a-thousand chance near n = 2,900.
Deployments processing high daily volumes will encounter
collisions as a matter of course and MUST implement Section 8.2
rather than treating collisions as exceptional.
* Not an authority. A REMID is valid if and only if its prefix
matches the corresponding digest. No party assigns or revokes
REMIDs, and a REMID carries no assertion about the record's
status; revocation is handled in Section 14.2.
8.4. REMID Resolver
Producers SHOULD publish a resolver endpoint at a stable URL mapping
a REMID to the corresponding ER and Artifact metadata. The resolver
SHOULD return JSON conforming to Section 10. A resolver is a
convenience, not a trust anchor: a Verifier MUST NOT accept resolver
output in place of independent verification of the permanence layers.
9. Field Commitments and Selective Disclosure
Many government records cannot be published in full but must still be
anchored. Revision -01 anchored the raw Artifact digest in all
cases, which is unsafe for low-entropy content: an adversary with a
candidate document, or with the ability to enumerate a small
candidate space, confirms content by recomputing the digest.
A Field Commitment over value v is:
C(v) = SHA-256( ENC("RGIP/2/commit", salt, field_name, v) )
where salt is at least 16 octets from a cryptographically secure
random source, generated per value and never reused across values or
records.
Rules:
* A Producer operating in commitment mode MUST set core.mode to
"commitment" and MUST populate the Fingerprint positions with
commitments over the corresponding digests, using the same
encoding.
Reilly Expires 8 March 2027 [Page 19]
Internet-Draft Reilly Government Integrity Protocol September 2026
* Salts MUST NOT be published with the ER. They are disclosed only
to a party authorized to verify the underlying value.
* A Producer MUST retain salts for at least the retention period of
the record. Loss of a salt renders the corresponding commitment
permanently unverifiable, and Section 14.3 treats deliberate salt
destruction as a disposition mechanism.
* Selective disclosure of a field is performed by supplying the
value and its salt, which the recipient checks against the
published commitment. Disclosure of one field MUST NOT reveal any
other field, which the per-value salt ensures.
* A Verifier presented with an ER in commitment mode can verify
chain integrity, signature, and anchors in full, and can verify
content only for fields disclosed to it. Verification output MUST
state which fields were verified against values and which were
verified only as commitments.
10. Evidence Receipt (ER) Data Model
An ER is a UTF-8 JSON object [RFC8259] with two top-level members:
"core" and "envelope". The Core is immutable and signed. The
Envelope carries state that changes after issuance and is not covered
by the Core signature.
This split resolves a defect in -01, where permanence.bitcoin.status
moved from "pending" to "confirmed" inside the object the signature
covered, so that a correctly operated pipeline invalidated its own
signatures as a matter of routine.
10.1. ER Core (Signed)
{
"er_version": "3",
"alg_suite": "rgip-2-a",
"chain_id": string,
"record_id": string, // REQUIRED; UUID v4 [RFC9562]
"mode": string, // "artifact" | "commitment"
"subject": {
"title": string, // OMITTED in commitment mode
"originator": string, // issuing body
"remid": string,
"artifact_uri": string OPTIONAL
},
"content": {
"media_type": string,
"byte_length": integer OPTIONAL, // omit in commitment mode
Reilly Expires 8 March 2027 [Page 20]
Internet-Draft Reilly Government Integrity Protocol September 2026
"sha256": string, // hex, or commitment in that mode
"sha3_512": string,
"blake3_256": string,
"ni": string OPTIONAL // ni URI [RFC6920]
},
"chain": {
"block_index": integer,
"link_sha256": string,
"link_sha3_512": string,
"link_blake3_256": string,
"braid_sha256": string,
"braid_sha3_512": string,
"braid_blake3_256": string,
"prev_braid_sha256": string,
"prev_braid_sha3_512": string,
"prev_braid_blake3_256": string
},
"event": {
"event_type": string, // "publish" | "amend" | "revoke" |
// "bridge" | "checkpoint"
"created": string, // RFC 3339 [RFC3339], UTC
"supersedes": string OPTIONAL // REMID of prior record
},
"disclosure": {
"committed_fields": array OPTIONAL // field names in commitment
},
"sign": {
"alg": string, // COSE algorithm [RFC9053]
"kid": string, // key identifier
"cose_sign1": string // base64url COSE_Sign1 [RFC9052]
}
}
The Core digest is:
core_digest = SHA-256(
ENC("RGIP/2/core", JCS(core_without_sign)) )
where core_without_sign is the Core object with the "sign" member
removed, serialized per JCS [RFC8785]. The COSE_Sign1 signature is
computed over core_without_sign in its JCS serialization. The
core_digest is the value submitted to the timestamp layer.
10.2. ER Envelope (Mutable)
{
"core_digest": string, // binds Envelope to Core
"anchors": [
Reilly Expires 8 March 2027 [Page 21]
Internet-Draft Reilly Government Integrity Protocol September 2026
{
"layer": "ots",
"state": string, // "pending" | "attested"
"digest": string, // the anchored value
"submitted_at": string, // RFC 3339
"calendars": array,
"proof": string OPTIONAL, // base64 OTS proof bytes
"proof_uri": string OPTIONAL,
"observed_height": integer OPTIONAL,
"observed_time": string OPTIONAL
}
],
"ipfs": {
"state": string,
"cid": string OPTIONAL,
"gateways": array OPTIONAL
},
"archival": {
"state": string,
"doi": string OPTIONAL,
"record_url": string OPTIONAL,
"repository": string OPTIONAL
},
"web_archive": {
"state": string,
"snapshots": array OPTIONAL
},
"checkpoints": array OPTIONAL, // Checkpoint refs, Section 11.3
"envelope_updated": string // RFC 3339
}
The Envelope MUST carry core_digest. A Verifier MUST recompute the
Core digest and confirm it matches before relying on any Envelope
field. An Envelope whose core_digest does not match its Core is
discarded, not repaired.
Envelope contents are not signed and carry no authority of their own.
Every Envelope claim is verified against the layer it names: an
anchors entry is verified by checking the proof, an ipfs entry by
resolving the CID, an archival entry by resolving the identifier. A
Verifier MUST NOT accept an Envelope assertion it did not check.
Revision -01 required Producers to store raw OTS receipt bytes but
provided no ER field to carry them, while its verification procedure
required a Verifier to parse those bytes. The "proof" and
"proof_uri" members close that gap. At least one of them MUST be
present for any anchor in state "attested".
Reilly Expires 8 March 2027 [Page 22]
Internet-Draft Reilly Government Integrity Protocol September 2026
10.3. Field Notes
* URIs MUST conform to [RFC3986].
* Timestamps MUST be RFC 3339 [RFC3339] with a UTC offset of Z.
* Hexadecimal digest values MUST be lowercase.
* In commitment mode, subject.title, content.byte_length, and
content.ni MUST be omitted, since each leaks Artifact information
that defeats the commitment. Revision -01 had no commitment mode
and therefore no such rule.
* Signatures MUST use COSE_Sign1 [RFC9052], a CBOR [RFC8949]
structure. Ed25519 [RFC8032] is RECOMMENDED for current
deployments. Section 19 addresses migration.
* The -01 security.binding_hash field is removed. It was a
SHA-256 over three values already covered by the chain
construction and added no detection capability that Section 7.6
does not provide.
10.4. Version and Compatibility
The er_version is "3". Revision -00 issued version "1" and -01
issued version "2". The Core and Envelope split, the entangled
chain values, and the mode field are not backward compatible with
version "2": a version 2 ER cannot be verified under this document,
and a version 3 ER cannot be verified under -01.
A Producer migrating an existing chain MUST NOT recompute historical
blocks under the new construction, which would destroy the
correspondence between those blocks and their existing anchors.
Instead the Producer MUST issue a Hash Migration Bridging Record
(Section 15) at the transition, carrying the last -01 Cross-Chain
Hash as an input to the first Braid computed under this document.
11. Permanence Layer Stack
11.1. Anchor States
Every anchor is in one of two states.
pending: The digest has been submitted to a calendar or aggregator
and a receipt has been returned. A pending anchor
evidences submission only. It does not establish that the
digest existed at any particular time, because no public
consensus record has committed to it. Revision -01 used
Reilly Expires 8 March 2027 [Page 23]
Internet-Draft Reilly Government Integrity Protocol September 2026
the same "pending" label but described the result as a
timestamp throughout, which overstates it.
attested: The proof resolves through an aggregation path to a
committed public consensus record whose observed time
bounds the digest's existence.
A Producer MUST NOT present a pending anchor as evidence of time in
any user-facing output, report, or API response. A Verifier MUST
treat an anchor in state "pending" as absent for the purpose of
Section 13.
11.2. Timestamp Anchoring via OpenTimestamps
The core_digest of the ER Core MUST be submitted to one or more
OpenTimestamps [OTS] calendar servers. Submission to at least three
independent calendars is RECOMMENDED, so that the loss or
discontinuation of one operator does not leave the record without a
path to attestation.
Revision -01 anchored the Artifact SHA-256 digest. This revision
anchors the Core digest, which commits to the Artifact digests, the
chain values, the REMID, and the event metadata together. Anchoring
the Artifact digest alone left the surrounding record unanchored,
including the timestamp the record asserted for itself. A Producer
MAY additionally anchor the Artifact digest where a bare content
timestamp is independently useful, except where Section 20 prohibits
it.
Calendar servers aggregate submissions into a Merkle tree and commit
the root to a Bitcoin transaction. Once a block confirms the
commitment, the proof is upgraded to include the full path from the
submitted digest to the block header. The Producer MUST then parse
the observed height and time, set the anchor state to "attested", and
update the Envelope. The Core is not modified.
Merkle inclusion proofs used by RGIP-defined constructions, as
distinct from those internal to the OTS layer, MUST use the
construction of [RFC9162], including its distinct leaf and interior
node prefixes, and MUST NOT duplicate a leaf to balance a tree.
11.3. Chain Checkpoint Anchoring
This section is new in -02 and supplies the property -01 asserted but
did not construct.
A Checkpoint commits to a Chain Head:
Reilly Expires 8 March 2027 [Page 24]
Internet-Draft Reilly Government Integrity Protocol September 2026
checkpoint_digest = SHA-256( ENC("RGIP/2/checkpoint",
chain_id, idx, b256(idx), b3(idx), bb3(idx), created) )
where idx is the index of the highest block covered.
A Producer MUST submit Checkpoints to the timestamp layer on a
published cadence, and MUST publish each Checkpoint together with its
proof and the block index it covers. A cadence no longer than 24
hours is RECOMMENDED for general deployments. Deployments where
ordering is contested, such as procurement or election
administration, SHOULD checkpoint at every phase boundary in addition
to the periodic cadence.
What a Checkpoint establishes: every block at or below the covered
index held the content it now holds no later than the Checkpoint's
observed time. A Producer cannot subsequently insert, remove, or
reorder any block in that range without producing a Chain Head that
fails to match the anchored Checkpoint.
What it does not establish: anything about blocks added after the
Checkpoint, which remain reorderable until the next one. The
ordering guarantee is therefore granular to the cadence, and a
deployment's cadence is itself a material disclosure. Producers MUST
publish their cadence.
Verifiers evaluating an ordering claim MUST identify the first
attested Checkpoint covering the block in question and MUST state the
ordering conclusion relative to that Checkpoint's observed time
rather than to the block's asserted created value.
11.4. Decentralized Storage via IPFS
The Artifact and its ER SHOULD be pinned to IPFS [IPFS-SPEC],
yielding a CID that is a self-describing multihash [MULTIHASH]. The
CID is recorded in the Envelope, with at least one resolving gateway.
Pinning is not permanence. A CID resolves only while at least one
node serves the content, so a Producer MUST verify pin liveness on a
published schedule and MUST treat a lapsed pin as a degraded layer
under Section 16. A Producer MUST NOT pin Artifacts in commitment
mode, or any Artifact excluded by Section 20.
11.5. Archival Deposit and DOI Issuance
Artifacts SHOULD be deposited with a repository that issues a
persistent identifier and commits to long-term preservation. Zenodo,
operated by CERN, is RECOMMENDED for openly publishable records on
the basis of its preservation commitment and its independence from
Reilly Expires 8 March 2027 [Page 25]
Internet-Draft Reilly Government Integrity Protocol September 2026
the depositing agency. Agencies subject to a statutory records
schedule SHOULD additionally deposit with the archival authority of
record for their jurisdiction; such deposit is complementary to, not
a substitute for, deposit with an independent repository, since the
archival authority may be within the same governmental structure as
the record's subject.
The identifier and record URL are recorded in the Envelope.
Producers MUST use current repository URL forms and MUST NOT emit
legacy path forms in published records.
11.6. Web Archival
The REMID resolver URL SHOULD be submitted for web archival, which
creates an independent crawl of the public-facing record page.
Snapshot URLs are recorded in the Envelope. Web archival covers the
resolver page, not the Artifact bytes, and MUST NOT be counted as an
Artifact copy for the purposes of Section 13.
12. Step-by-Step Implementation (Normative)
Step 1: Prepare the Artifact
1. Determine the canonical byte stream per Section 6.
2. Compute the Fingerprint under SHA-256, SHA3-512, and
BLAKE3-256.
3. Determine the anchoring mode. If the Artifact is
access-controlled, low-entropy, or otherwise within
Section 20's prohibition, the mode is "commitment"; otherwise
"artifact".
4. In commitment mode, generate a fresh salt per value and compute
Field Commitments per Section 9. Retain salts under the
controls applicable to the Artifact.
Step 2: Assign a REMID
5. Determine the UTC submission date.
6. Derive the base REMID per Section 8.1, applying Section 8.2 if
the base form is already issued for that date on that chain.
Step 3: Compute Chain Values
7. Retrieve the prior Braid. For the Genesis Block, use the
all-zeros Braid of Section 7.5.
Reilly Expires 8 March 2027 [Page 26]
Internet-Draft Reilly Government Integrity Protocol September 2026
8. Generate a record_id. UUID v4 [RFC9562] is RECOMMENDED.
9. Record the creation timestamp in RFC 3339 [RFC3339] UTC.
10. Encode the block inputs per Section 6 and compute L256, L3, and
Lb3 per Section 7.3.
11. Compute the Braid components per Section 7.4.
Step 4: Build and Sign the Core
12. Populate the ER Core per Section 10.1.
13. Serialize the Core without its "sign" member per JCS [RFC8785]
and compute the core_digest.
14. Create a COSE_Sign1 [RFC9052] over that serialization and place
it, with its algorithm and key identifier, in "sign".
Step 5: Anchor
15. Submit the core_digest to at least three OTS calendars. Record
the submission time, calendars, and receipt in the Envelope with
state "pending".
Step 6: Distribute
16. Unless prohibited by Section 20, pin the Artifact and ER to
IPFS and record the CID and gateways.
17. Unless prohibited by Section 20, deposit the Artifact for
archival and record the identifier and record URL.
18. Submit the REMID resolver URL for web archival and record the
snapshots.
Step 7: Publish
19. Publish the ER. The archival landing page and the resolver
SHOULD link each other.
Step 8: Attest
20. Poll for proof upgrades. On upgrade, parse the observed height
and time, set the anchor state to "attested", attach the proof
bytes or a proof URI, and update envelope_updated. The Core is
never modified.
Reilly Expires 8 March 2027 [Page 27]
Internet-Draft Reilly Government Integrity Protocol September 2026
Step 9: Checkpoint
21. On the published cadence, and at any phase boundary the
deployment defines, compute the checkpoint_digest per
Section 11.3, submit it, and publish the Checkpoint with its
covered block index. Track it to attestation as in Step 8.
13. Verification Procedure (Normative)
A Verifier MUST perform the following.
1. Retrieve the ER. Confirm er_version is "3" and alg_suite is
implemented. If not, stop and report the ER as unverifiable
under this document rather than attempting a reduced check.
2. Recompute the Core digest per Section 10.1 and confirm the
Envelope's core_digest matches.
3. Verify the COSE_Sign1 signature over the JCS serialization of
the Core without "sign", using a key obtained through a channel
independent of the ER.
4. If mode is "artifact": recompute the Fingerprint of the
retrieved Artifact and confirm all three digests match
content.sha256, content.sha3_512, and content.blake3_256. If
mode is "commitment": confirm the Fingerprint positions are
well-formed commitments and verify only those fields for which
a value and salt have been disclosed.
5. Recompute the Links and Braid per Section 7.6 and confirm all
six values, and confirm linkage to the prior block.
6. Re-derive the base REMID and confirm subject.remid is the base
form or a disambiguated form of it per Section 8.2.
7. For each anchor: parse the proof, confirm the path connects the
stated digest to a block header, confirm that header is present
in the public chain at the stated height, and confirm the
anchored digest equals the core_digest. An anchor in state
"pending" is treated as absent.
8. Identify the earliest attested Checkpoint covering this block
index. Confirm the Checkpoint's committed Chain Head matches
the Braid recomputed for that index. Record its observed time
as the bound on the block's construction.
9. Resolve the CID through a gateway not operated by the Producer
and confirm the returned bytes reproduce the Fingerprint.
Reilly Expires 8 March 2027 [Page 28]
Internet-Draft Reilly Government Integrity Protocol September 2026
10. Resolve the archival identifier and confirm the landing page
serves the same Artifact.
11. Confirm the REMID is not listed in the Revocation Registry
(Section 14.2), and if it is, report the revocation with the
record rather than suppressing either.
12. Confirm all timestamps are well-formed RFC 3339 UTC and that
event.created is not later than the earliest attested anchor's
observed time. A created value later than its own attestation
is a contradiction and MUST fail verification.
Reporting
A Verifier MUST report per-check results rather than a single
boolean. A record is reported as verified only if steps 2 through 8
pass. Steps 9 and 10 establish retrievability; their failure
downgrades the report to "verified, not retrievable" rather than
failing it, since a valid record can outlive a hosting layer.
Revision -01 stated that a record "MAY be considered unverified if
fewer than two layers return consistent results", which left the
threshold to the Verifier and permitted a record with no attested
anchor to be reported as verified. That guidance is withdrawn. A
record with no attested anchor MUST NOT be reported as timestamped
under any threshold.
14. Amendment, Supersession, and Revocation
14.1. Amendment Records
An amendment MUST create a new Artifact, a new REMID, and a new
block, with event_type "amend" and event.supersedes set to the REMID
of the record amended. The original block is never modified or
removed. Revision -01 placed the prior REMID in
subject.artifact_uri, conflating a supersession relationship with a
retrieval location; event.supersedes replaces that use.
A resolver serving a superseded REMID MUST serve the original record
and MUST indicate the supersession, rather than redirecting to the
amendment. Silently serving the amendment in place of the original
defeats the purpose of anchoring the original.
14.2. Revocation Registry
Records are withdrawn, corrected under seal, or issued in error.
Revision -01 had no mechanism for this, so the only way to signal a
withdrawal was to alter or remove the record, which the chain
Reilly Expires 8 March 2027 [Page 29]
Internet-Draft Reilly Government Integrity Protocol September 2026
forbids.
A Producer MUST maintain a Revocation Registry: an append-only,
chained series of blocks with event_type "revoke", each naming the
REMID revoked, a reason code, and the effective time. Revocation
blocks are anchored and checkpointed like any other.
Revocation removes nothing. The revoked record remains in the chain
and remains retrievable. Revocation asserts that the issuing body no
longer stands behind the record, which is itself a record. A
Verifier MUST surface a revocation alongside the record and MUST NOT
treat revocation as a verification failure.
14.3. Retention and Disposition
Government records are frequently subject to statutory retention
schedules that require disposition at a defined time. A protocol
built on irrevocable public layers is in tension with any such
requirement, and -01 did not address it.
Deployments subject to a disposition requirement MUST operate in
commitment mode for the affected record categories and MUST NOT
distribute the Artifact to public permanence layers. At disposition,
the Producer destroys the Artifact and the associated salts under its
normal procedure. The chain retains the block, the commitments, and
the anchors, so the fact and timing of the record's existence survive
disposition while its content does not.
This property is called erasure-compatible permanence and is
consistent with the treatment in [I-D.reilly-aigov]. Producers MUST
record disposition as a "revoke" block with a reason code indicating
scheduled disposition, so that the gap is documented rather than
silent.
Where a legal obligation requires removal of content already
distributed to public layers, a Producer MUST document that the
obligation cannot be fully satisfied for those layers, MUST request
removal where a layer offers a mechanism, and MUST NOT represent
removal as complete. Deployments SHOULD avoid this situation by
classifying record categories before processing rather than after.
15. Hash Migration Bridging Records
Hash functions are eventually deprecated. A chain that depends on a
deprecated function cannot be recomputed under a replacement without
destroying the correspondence between its blocks and its existing
anchors.
Reilly Expires 8 March 2027 [Page 30]
Internet-Draft Reilly Government Integrity Protocol September 2026
A Bridging Record is a block with event_type "bridge" that binds a
chain's state under an outgoing algorithm suite to its state under an
incoming suite:
bridge_digest = SHA-256( ENC("RGIP/2/bridge",
chain_id, idx, old_suite, new_suite,
old_head_values, new_head_values, created) )
where old_head_values is the ordered concatenation of the Chain Head
components under the outgoing suite, and new_head_values the same
under the incoming suite, both computed over the same block.
Rules:
* A Producer MUST NOT recompute historical blocks under a new suite.
* A Bridging Record MUST be anchored and checkpointed under both
suites where both remain operable.
* A Verifier reaching a Bridging Record while walking backward
switches to the outgoing suite for all earlier blocks and MUST
report the suite under which each range was verified.
* Deprecation of a suite does not invalidate blocks anchored under
it before deprecation. A Verifier MUST report such blocks as
verified under a deprecated suite rather than as failures.
The same construction applies to the migration from the -01
Cross-Chain Hash to the Braid of Section 7.4, treating the last -01
Cross-Chain Hash as old_head_values.
16. Autonomous Agent Architecture
RGIP deployments SHOULD run continuous verification agents.
Revision -01 defined agents numbered 1 through 5, 5.5, 6, 7, 11, 13,
and 14, a numbering that reflected an implementation's history rather
than a specification. This revision names roles instead.
16.1. Agent Roles
Fingerprint Agent:
Computes the Fingerprint for each incoming Artifact. MUST produce
all three digests before any downstream role runs.
Identifier Agent:
Derives the REMID and applies the collision rule of Section 8.2.
Chain Agent:
Reilly Expires 8 March 2027 [Page 31]
Internet-Draft Reilly Government Integrity Protocol September 2026
Encodes block inputs per Section 6, computes the Links and Braid,
and appends the block.
Signing Agent:
Serializes and signs the Core. MUST have access to signing keys
that no other role has.
Anchor Agent:
Submits Core digests to the timestamp layer and records pending
state.
Checkpoint Agent:
Computes and submits Checkpoints on the published cadence
(Section 11.3). MUST run independently of the Anchor Agent so
that a failure in per-record anchoring does not silently stop
checkpointing.
Distribution Agent:
Performs IPFS pinning, archival deposit, and web archival
submission, subject to the mode and to Section 20.
Attestation Agent:
Polls for proof upgrades and promotes anchors from pending to
attested. A polling interval no longer than 15 minutes is
RECOMMENDED.
Persistence Agent:
Stores ERs with integrity-checked reads.
Sentinel Agent:
Recomputes all six chain values for stored blocks per
Section 7.6, verifies Envelope claims against their layers, and
raises findings. MUST NOT modify records.
Remediator Agent:
Acts on findings within the limits of Section 16.2 and 16.3.
Agents MUST run as independent processes or tasks with crash
isolation, MUST handle asynchronous cancellation without leaving a
block partially appended, and MUST NOT allow the failure of one role
to suppress the findings of another.
16.2. Blast Radius and Oversight
Every automated action is classified:
BR0 Read-only. Verification, polling, reporting. Permitted in
all modes.
Reilly Expires 8 March 2027 [Page 32]
Internet-Draft Reilly Government Integrity Protocol September 2026
BR1 Idempotent repair of a distribution layer: re-pinning a
lapsed CID, resubmitting a web archival request,
resubmitting a digest whose calendar submission was lost.
Permitted in autonomous mode.
BR2 Actions that create a new block: bridging records,
supersession records. Permitted in supervised mode with
recorded human approval.
BR3 Actions that alter, delete, or reconstruct stored blocks,
alter Envelope anchor state without a resolved proof, alter
the Revocation Registry, or touch signing keys or salts.
MUST NOT be automated in any mode.
A deployment MUST declare its oversight mode and MUST record the mode
in effect for each remediation taken. A Remediator MUST apply
once-per-episode semantics: a finding that recurs after remediation
escalates to human review rather than looping. Revision -01's
self-heal agent had no such constraint and, as specified, would
re-execute indefinitely against a persistent fault.
16.3. Prohibited Automated Actions
Automated remediation of a chain integrity finding is prohibited.
If the Sentinel Agent reports that a recomputed Link or Braid does
not match its stored value, the only permitted automated response is
to record the finding, halt appends to that chain, and escalate.
The reason is that a chain integrity violation has exactly two
causes: storage corruption or tampering. These are
indistinguishable to the agent, and the repair appropriate to the
first destroys the evidence of the second. In a system whose purpose
is to detect alteration of government records, an agent that
automatically restores chain consistency is an agent that
automatically conceals tampering.
Likewise prohibited without human authorization: promoting an anchor
to attested without a resolved proof, issuing a revocation,
destroying salts, and recomputing historical blocks.
17. Operational Considerations
Key Management:
Signing keys SHOULD be held in hardware meeting FIPS 140-3 Level 2
or higher for production government deployments. Keys SHOULD be
rotated on a published schedule. Public keys and rotation history
MUST be published through a channel independent of the ER
distribution path, since a Verifier that obtains the key from the
Reilly Expires 8 March 2027 [Page 33]
Internet-Draft Reilly Government Integrity Protocol September 2026
same party that supplied the signature verifies nothing about
authorship.
Chain Continuity:
A Producer MUST maintain an unbroken chain from Genesis. If the
datastore is lost, chain state MAY be reconstructed by ordering
persisted ERs by block index and recomputing values, but the
reconstruction MUST be verified against the most recent attested
Checkpoint before appends resume, and the reconstruction event
MUST be recorded. Reconstruction that does not reproduce the
checkpointed Chain Head is a chain integrity finding under
Section 16.3, not a recoverable condition.
Multiple Formats:
If the same content is distributed in several formats, each format
SHOULD receive its own block, since each has a distinct
Fingerprint. The relationship between them SHOULD be expressed
through event.supersedes or a profile-defined member, not by
sharing a REMID.
Calendar Redundancy:
At least three independent calendars SHOULD be used per
submission. Loss of one operator leaves proofs from the others
independently valid.
Profiles:
A profile MAY restrict permanence layers, mandate specific COSE
algorithms, define PKI discovery, or substitute a private
timestamp service such as a Time-Stamp Protocol authority
[RFC3161]. A profile that substitutes a private timestamp
service MUST state plainly that it forfeits the independence
property, since the anchor is then controlled by a party within
the same trust boundary as the record's custodian.
Interoperability with the Suite:
RGIP shares its permanence methodology with
[I-D.reilly-rem-protocol] and its evidence chaining approach with
[I-D.reilly-banking-integrity]. A deployment operating more than
one MAY share the timestamp and archival layers but MUST maintain
separate chain identifiers and index spaces.
18. Security Considerations
Chain Integrity:
Integrity rests on collision resistance across the suite. A
collision in one function does not yield a consistent chain, since
each Link consumes the prior Braid under all three and the Braid
is computed under all three (Section 7.4). Compromise of all
Reilly Expires 8 March 2027 [Page 34]
Internet-Draft Reilly Government Integrity Protocol September 2026
three is required to forge a chain that verifies.
The Producer as Adversary:
The threat model that motivates RGIP includes an operator who is
also the record's subject. Against that adversary the chain and
the signature provide nothing on their own, since the adversary
controls both. Only the external layers constrain such an
operator, and only through Checkpoints for ordering and attested
anchors for time. Deployments SHOULD be evaluated on their
Checkpoint cadence and layer independence, not on the presence of
a chain.
Anchor Semantics:
An attested anchor bounds existence from above. It cannot bound
it from below, cannot establish authorship, and cannot establish
that the anchored record is the only version. Presenting an
anchor as proof that a record is authentic overstates it.
Key Compromise:
Compromise of a signing key permits fraudulent Cores but does not
permit alteration of existing anchors or Checkpoints. Producers
MUST publish revocation metadata for compromised keys, and
Verifiers MUST check that a signature's kid was valid at the
block's attested time rather than at verification time.
Replay and Substitution:
Verifiers SHOULD retrieve Artifacts over authenticated TLS
[RFC8446] and compare media type and length where available. The
REMID binds identifier to content, and the Core binds content to
chain position, limiting substitution.
Denial of Service:
Producers SHOULD rate-limit submissions per source to prevent
chain flooding, and MUST NOT drop blocks silently when a rate
limit engages, since a silent drop is indistinguishable from
suppression.
Salt Handling:
In commitment mode, salts are the entire confidentiality boundary.
Salt disclosure reveals the committed values; salt loss makes them
permanently unverifiable. Salts MUST be stored separately from
the ERs they protect.
19. Post-Quantum Considerations
Revision -01 made claims this section corrects.
SHA3-512:
Reilly Expires 8 March 2027 [Page 35]
Internet-Draft Reilly Government Integrity Protocol September 2026
Provides approximately 256-bit preimage resistance against Grover
search [GROVER] and approximately 256-bit classical collision
resistance.
Revision -01 stated that SHA3-512 "is not weakened by quantum
speedups that exploit SHA-2's Merkle-Damgard structure". No such
quantum speedup is known; the structural distinction between
Keccak [KECCAK] and Merkle-Damgard is relevant to length-extension
behavior, which is a classical property, not a quantum one. The
case for including SHA3-512 is algorithm diversity, not immunity
to a quantum attack that has not been demonstrated.
SHA-256:
Provides approximately 128-bit preimage resistance under Grover
and 128-bit classical collision resistance. Its inclusion is
required for compatibility with the Bitcoin-based timestamp layer
and is not a post-quantum measure.
BLAKE3-256:
Provides 128-bit classical collision resistance and approximately
128-bit preimage resistance under Grover. Revision -01 described
it as providing "128-bit classical security (256-bit output
truncated by Grover's algorithm to approximately 128-bit quantum
resistance)", which conflates collision and preimage resistance
and misstates both.
Collision search:
Quantum collision search offers limited practical advantage over
classical birthday search once memory and hardware costs are
accounted for. Deployments SHOULD NOT assume quantum adversaries
halve collision resistance across the board.
The unaddressed exposure:
The hash layer is the more robust part of this design. The
signature is not. Ed25519 [RFC8032] is broken by a
cryptographically relevant quantum computer, and a break would let
an adversary forge Cores for any period in which the corresponding
key was valid. Attested anchors and Checkpoints limit the damage,
because a forged Core cannot acquire a pre-existing anchor, but
the signature layer, not the hash layer, is where migration is
urgent. Producers SHOULD plan migration to a standardized
post-quantum signature algorithm as standardization completes
[NIST-PQC] and SHOULD use the alg_suite and Bridging Record
mechanisms to record the transition. Revision -01
described post-quantum resilience as a property of the protocol;
it is more accurately a property of the hash layer only.
Migration:
COSE [RFC9052] supports algorithm agility, so signature migration
Reilly Expires 8 March 2027 [Page 36]
Internet-Draft Reilly Government Integrity Protocol September 2026
does not require restructuring the ER. Hash suite migration
follows Section 15.
20. Privacy Considerations
Anchors and CIDs are public and permanent. Nothing submitted to
those layers can be recalled.
Producers MUST NOT anchor a raw digest of an Artifact that is
access-controlled, classified, contains personal data, or is drawn
from a candidate space small enough to enumerate. A digest is a
commitment, and against low-entropy content a commitment is
equivalent to disclosure for any adversary who can guess and check.
Revision -01 stated that a SHA-256 digest "does not by itself reveal
Artifact content", which holds only for high-entropy content and was
the basis on which -01 recommended anchoring voter rolls and
intelligence assessments directly. Those recommendations are
withdrawn.
For such Artifacts, Producers MUST operate in commitment mode
(Section 9), MUST NOT pin or deposit the Artifact, and MUST hold
salts under the controls applicable to the underlying content.
ERs SHOULD carry the minimum metadata needed for identification and
attribution. In commitment mode, subject.title and content length
are omitted for the reason given in Section 10.3: a title frequently
discloses more than the digest it accompanies.
Metadata that survives commitment mode is still disclosure. The
existence of a block, its time, its originator, and its cadence are
visible even when content is not. For sensitive programs, the
pattern of anchoring may reveal operational tempo. Section 5.5
applies.
Personal data in publicly deposited government records is governed by
the applicable disclosure regime. Where a subject has a statutory
right to erasure, Section 14.3 applies, and the deployment MUST have
classified the record before processing rather than seeking removal
afterward.
21. Prior Art Record Function
This section is informative and is not legal advice.
A record produced under RGIP in "artifact" mode, deposited openly and
anchored to a public timestamp layer, functions as a prior art record
under 35 U.S.C. 102(a)(1) [USC-35-102]. Three elements combine:
public accessibility is supplied by open archival deposit under a
Reilly Expires 8 March 2027 [Page 37]
Internet-Draft Reilly Government Integrity Protocol September 2026
persistent identifier and by content-addressed distribution; date
corroboration is supplied by the attested anchor, observed by a party
with no interest in the record; and content binding is supplied by
the Fingerprint, which ties the corroborated date to an exact byte
sequence rather than to a description.
A record in "commitment" mode does not function as prior art with
respect to its content, since the content is not publicly accessible.
It establishes only that a commitment existed at a bounded time, and
the content can be disclosed later to a specific party under
Section 9. This distinction parallels the Full and Partial REM
Record distinction in [I-D.reilly-rem-protocol] version -02.
This specification is itself such a record. It is published as an
Internet-Draft, deposited for archival, and anchored under the
methodology it describes, and it is intended to serve as a defensive
publication of the constructions it defines.
Whether any particular record qualifies as prior art, and what weight
it carries, is determined by the applicable forum under the
applicable law. This document specifies a record format and does not
determine that outcome.
22. IANA Considerations
This document has no IANA actions.
Should a future revision seek registration of the "REMID" URI scheme
or of the domain separation tags of Section 6, those actions will be
specified in that revision.
23. References
23.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
Reilly Expires 8 March 2027 [Page 38]
Internet-Draft Reilly Government Integrity Protocol September 2026
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.
[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
Keranen, A., and P. Hallam-Baker, "Naming Things with
Hashes", RFC 6920, April 2013,
<https://www.rfc-editor.org/info/rfc6920>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, 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, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785, June 2020,
<https://www.rfc-editor.org/info/rfc8785>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052, August 2022,
<https://www.rfc-editor.org/info/rfc9052>.
[RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Initial Algorithms", RFC 9053, August 2022,
<https://www.rfc-editor.org/info/rfc9053>.
[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate
Transparency Version 2.0", RFC 9162, December 2021,
<https://www.rfc-editor.org/info/rfc9162>.
[RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique
IDentifiers (UUIDs)", RFC 9562, May 2024,
<https://www.rfc-editor.org/info/rfc9562>.
[FIPS202] National Institute of Standards and Technology, "SHA-3
Standard: Permutation-Based Hash and Extendable-Output
Functions", FIPS PUB 202, August 2015,
Reilly Expires 8 March 2027 [Page 39]
Internet-Draft Reilly Government Integrity Protocol September 2026
<https://doi.org/10.6028/NIST.FIPS.202>.
[BLAKE3] O'Connor, J., Aumasson, J.-P., Neves, S., and
Z. Wilcox-O'Hearn, "BLAKE3: One Function, Fast
Everywhere", 2020,
<https://github.com/BLAKE3-team/BLAKE3-specs>.
23.2. Informative References
[RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
"Internet X.509 Public Key Infrastructure Time-Stamp
Protocol (TSP)", RFC 3161, August 2001,
<https://www.rfc-editor.org/info/rfc3161>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[OTS] Todd, P., "OpenTimestamps: Scalable, Trust-Minimized,
Distributed Timestamping with Bitcoin", 2016,
<https://opentimestamps.org>.
[IPFS-SPEC]
Protocol Labs, "IPFS: Content Addressed, Versioned, P2P
File System", 2014, <https://ipfs.tech>.
[MULTIHASH]
Protocol Labs, "Multihash: Self-Describing Hash
Functions", 2015, <https://multiformats.io/multihash/>.
[NIST-PQC] National Institute of Standards and Technology,
"Post-Quantum Cryptography Standardization", 2024,
<https://csrc.nist.gov/projects/
post-quantum-cryptography>.
[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.
[KECCAK] Bertoni, G., Daemen, J., Peeters, M., and G. Van Assche,
"The Keccak reference, version 3.0", 2011,
<https://keccak.team>.
[USC-35-102]
United States Code, "Title 35, Section 102: Conditions for
patentability; novelty", 2011.
[I-D.reilly-rem-protocol]
Reilly Expires 8 March 2027 [Page 40]
Internet-Draft Reilly Government Integrity Protocol September 2026
Reilly, L. J., "Reilly EternaMark (REM) Protocol -
Dual-Layer Digital Permanence Using DOI Archiving and
Blockchain Timestamping", Work in Progress, Internet-
Draft, draft-reilly-rem-protocol-02, 2026.
[I-D.reilly-banking-integrity]
Reilly, L. J., "Reilly Banking Integrity Protocol (RBIP)",
Work in Progress, Internet-Draft,
draft-reilly-banking-integrity-02, 2026.
[I-D.reilly-aigov]
Reilly, L. J., "Verifiable AI Governance and Data Privacy
Records", Work in Progress, Internet-Draft,
draft-reilly-aigov-00, 2026.
[RGIP00] Reilly, L. J., "Reilly Government Integrity Protocol
(RGIP)", DOI 10.5281/zenodo.17114518, September 2025.
Appendix A. Changes from draft-reilly-government-integrity-01
Corrections to constructions
* The SHA3-512-only Cross-Chain Hash is replaced by the entangled
link-and-braid construction of Section 7. Each Link now consumes
all three components of the prior Braid, and the Braid is computed
under all three algorithms rather than SHA3-512 alone. The -01
construction made SHA3-512 the sole binding of three otherwise
independent chains and therefore did not deliver the
"all three simultaneously" property it claimed.
* Section 6 defines a canonical, domain-separated, length-delimited
encoding for all hashed inputs. Revision -01 concatenated
variable-length UTF-8 fields without delimiters, permitting
distinct field assignments to produce identical preimages.
* BLAKE3 output length is fixed at 32 octets in the default hash
mode. Revision -01 left it unspecified for an extendable-output
function.
* Section 10 splits the ER into a signed Core and a mutable
Envelope. In -01 the signature covered permanence fields that
change on anchor confirmation, so routine operation invalidated
the signature over the record.
* The anchored value is now the Core digest rather than the bare
Artifact digest, so that chain position, REMID, and asserted time
are covered by the anchor.
Reilly Expires 8 March 2027 [Page 41]
Internet-Draft Reilly Government Integrity Protocol September 2026
* record_id is a required ER Core field. It was consumed by the -01
chain hashes but absent from the -01 ER, making third-party
recomputation impossible.
* Envelope members "proof" and "proof_uri" carry the OTS proof bytes
that -01 required Producers to store and Verifiers to parse but
provided no field for.
* Merkle inclusion proofs in RGIP-defined constructions are
specified under [RFC9162], which obsoletes the RFC 6962
construction cited by -01.
* security.binding_hash is removed as redundant with Section 7.6.
* chain.quantum_resilient is replaced by core.alg_suite, since a
Verifier can check the latter and cannot check the former.
* Section 8.2 replaces the -01 collision rule, which directed
implementations to append hash characters and thereby contradicted
the determinism the same section asserted.
* Section 8.3 restates the REMID collision bound as a birthday
bound. Revision -01 gave the per-pair figure of 1 in 2^32.
New material
* Section 11.3, Chain Checkpoint anchoring. Revision -01 anchored
only artifact digests, so nothing external committed to chain
state and the -01 claim that record sequence could not be forged
did not hold.
* Section 9, salted Field Commitments and selective disclosure,
together with commitment mode throughout.
* Section 14.2, the Revocation Registry, and Section 14.1's use of
event.supersedes in place of the -01 overloading of
subject.artifact_uri.
* Section 14.3, retention and disposition, addressing statutory
records schedules and erasure-compatible permanence.
* Section 15, Hash Migration Bridging Records, including the bridge
from the -01 Cross-Chain Hash to the Braid.
* Section 16.2 and 16.3, blast radius classification and the
prohibition on automated remediation of chain integrity findings.
The -01 self-heal agent was unconstrained and would have been
permitted to overwrite evidence of tampering.
Reilly Expires 8 March 2027 [Page 42]
Internet-Draft Reilly Government Integrity Protocol September 2026
* Section 5.7, constraints common to all use cases, and
Section 21, the prior art record function under 35 U.S.C.
102(a)(1).
Withdrawn or narrowed claims
* The -01 recommendation to process voter registration files and
intelligence assessments with raw digest anchoring is withdrawn
(Sections 5.5, 5.6, 20). A digest of low-entropy content is
equivalent to disclosure against an adversary who can enumerate.
* The -01 assertion of a quantum speedup exploiting SHA-2's
Merkle-Damgard structure is withdrawn; no such result is known
(Section 19).
* The -01 characterization of BLAKE3's security levels is corrected;
it conflated collision and preimage resistance.
* Post-quantum resilience is scoped to the hash layer, with the
signature layer identified as the unaddressed exposure.
* The -01 verification guidance permitting a record to be considered
verified on a two-of-N layer threshold is withdrawn. A record
with no attested anchor is not timestamped under any threshold
(Section 13).
* "Self-sovereign" is replaced by "content-derived" in describing
the REMID.
Editorial
* Internal cross-references corrected throughout. Revision -01
referred to Sections 5.1 through 5.3 for chain hash definitions
located in 6.1 through 6.3, to Section 6 for the REMID located in
Section 7, to Section 7 for the ER model located in Section 8, and
to Sections 8.3 and 8.4 for permanence subsections located in 9.3
and 9.4. The -01 change log carried the same errors.
* Duplicated passages in the -01 Section 9.1, Section 15, the
MULTIHASH reference, and the -01 change log are removed.
* The Introduction's repeated statement of the anchoring premise is
consolidated.
* Agent roles are named rather than numbered, removing the -01
sequence 1, 2, 3, 4, 5, 5.5, 6, 7, 11, 13, 14.
* er_version is incremented from "2" to "3".
Reilly Expires 8 March 2027 [Page 43]
Internet-Draft Reilly Government Integrity Protocol September 2026
Acknowledgments
The author thanks the IETF community for review and discussion.
Author's Address
Lawrence J. Reilly
REM Technologies & Consulting, LLC
United States of America
Email: lreilly250@gmail.com
Reilly Expires 8 March 2027 [Page 44]