Reilly Resilience Protocol (RRP): Tamper-Evident Proof of System Resilience
draft-reilly-resilience-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-resilience-protocol-02
Network Working Group L.J. Reilly
Internet-Draft REM Technologies & Consulting, LLC
Intended status: Informational
Expires: February 25, 2027 August 24, 2026
Reilly Resilience Protocol (RRP): Tamper-Evident Proof of
System Resilience
draft-reilly-resilience-protocol-02
Abstract
The Reilly Resilience Protocol (RRP) standardizes a verifiable
method to prove that IT systems, cloud infrastructures, and AI
pipelines are continuously exercised and resilient. RRP transforms
resilience claims into cryptographically signed, tamper-evident
evidence persisted in immutable storage and batched into a daily
Merkle root that is publicly time-anchored. The protocol outputs
an executive Resilience Scorecard backed by independently
verifiable cryptographic receipts. RRP composes with the Reilly
EternaMark (REM) protocol to ensure dual-layer digital permanence
using both DOI archival and blockchain timestamping.
This document supersedes draft-reilly-resilience-protocol-01. It
corrects the Merkle tree construction of -01, which duplicated the
final leaf of an odd-cardinality set and incorrectly attributed
that construction to RFC 9162. It further addresses the principal
structural gap of -01, namely that the protocol proved the
integrity of the evidence that was produced but could not prove
that any particular evidence was ever required to exist. This
revision adds the Evidence Continuity Chain, the Control Coverage
Attestation, field-level commitments with selective disclosure,
governed autonomous remediation with blast-radius classes, hash
and signature migration for long retention horizons, a coverage
factor and weight renormalization rule in the scoring algorithm,
and an implementation status section describing running code.
The foundational whitepaper underpinning this work (Reilly
Resilience Protocol Whitepaper v2) is permanently archived at:
DOI: 10.5281/zenodo.17100703
https://zenodo.org/records/17100703
That document was blockchain timestamped and DOI archived on
September 11, 2025, at the time of its upload to Zenodo, providing
cryptographic attestation of its existence and integrity as of that
date. The initial IETF submission (draft-reilly-resilience-
protocol-00) was recorded in the IETF Datatracker on September 27,
2025.
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 February 25, 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. Problem Addressed by This Revision . . . . . . . . . . . 5
1.2. Implementation Status . . . . . . . . . . . . . . . . . 6
2. Conventions Used in This Document . . . . . . . . . . . . . 7
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Protocol Principles . . . . . . . . . . . . . . . . . . . . 11
5. Architecture Overview . . . . . . . . . . . . . . . . . . . 13
5.1. Roles and Responsibilities . . . . . . . . . . . . . . 13
5.2. Data Flow . . . . . . . . . . . . . . . . . . . . . . . 16
6. Evidence Schema . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Evidence Record Structure . . . . . . . . . . . . . . . 17
6.2. Control Result Codes . . . . . . . . . . . . . . . . . 20
6.3. Canonical Serialization . . . . . . . . . . . . . . . . 21
6.4. Field Commitments and Selective Disclosure . . . . . . 22
6.5. Version Compatibility . . . . . . . . . . . . . . . . . 25
7. Cryptographic Operations . . . . . . . . . . . . . . . . . 25
7.1. Evidence Signing . . . . . . . . . . . . . . . . . . . 25
7.2. Merkle Tree Construction . . . . . . . . . . . . . . . 26
7.3. Anchoring . . . . . . . . . . . . . . . . . . . . . . . 29
7.4. Evidence Continuity Chain . . . . . . . . . . . . . . . 31
7.5. Hash and Signature Migration . . . . . . . . . . . . . 34
8. Key Management . . . . . . . . . . . . . . . . . . . . . . 36
9. Operational Procedures . . . . . . . . . . . . . . . . . . 38
9.1. Control Definition and the Control Register . . . . . . 38
9.2. Evidence Collection . . . . . . . . . . . . . . . . . . 41
9.3. Signing and Storage . . . . . . . . . . . . . . . . . . 42
9.4. Aggregation and Anchoring . . . . . . . . . . . . . . . 43
9.5. Control Coverage Attestation . . . . . . . . . . . . . 45
9.6. Scorecard Publication . . . . . . . . . . . . . . . . . 47
9.7. Independent Verification . . . . . . . . . . . . . . . 48
9.8. Autonomous Remediation and Human Oversight . . . . . . 50
10. Resilience Scorecard Specification . . . . . . . . . . . . 54
10.1. Pillars, Weights, and Renormalization . . . . . . . . . 54
10.2. Scoring Algorithm . . . . . . . . . . . . . . . . . . . 56
10.3. Score Decay . . . . . . . . . . . . . . . . . . . . . . 58
10.4. Band Assignment and Hysteresis . . . . . . . . . . . . . 59
11. Compliance Mapping . . . . . . . . . . . . . . . . . . . . 60
12. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 63
12.1. Adversary Classes . . . . . . . . . . . . . . . . . . . 63
12.2. Attack Scenarios and Mitigations . . . . . . . . . . . 64
13. Security Considerations . . . . . . . . . . . . . . . . . . 69
14. Relationship to Other Protocols in the Suite . . . . . . . 74
15. Implementation Guidance . . . . . . . . . . . . . . . . . . 77
16. Prior Art and Defensive Publication . . . . . . . . . . . . 80
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . 81
18. References . . . . . . . . . . . . . . . . . . . . . . . . 83
18.1. Normative References . . . . . . . . . . . . . . . . . 83
18.2. Informative References . . . . . . . . . . . . . . . . 85
Appendix A. Changes from -01 . . . . . . . . . . . . . . . . . 89
Appendix B. Worked Continuity Verification Example . . . . . . 93
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 95
1. Introduction
Organizations routinely assert claims of "high availability,"
"recoverability," and "regulatory compliance," yet significant
service outages, failed backup restores, configuration drift, and
silent AI model degradation continue to occur with alarming
frequency. Traditional monitoring logs and dashboard indicators are
vulnerable to post-hoc modification, incomplete capture, or absence
of objective time-validity proofs. A log that shows 99.9% uptime
provides no cryptographic guarantee that the log itself was not
modified after the fact.
RRP closes this trust gap by producing daily, tamper-evident proof
that critical resilience controls executed successfully. The
protocol mandates that all evidence be cryptographically signed,
persisted in Write-Once-Read-Many (WORM) or equivalent immutable
storage, and anchored for independent time attestation.
The protocol is designed for three primary audiences:
1. Operators: DevOps, SRE, and security teams who run and
automate the actual resilience checks, sign evidence, and
maintain the evidence store.
2. Executives: CISOs, CIOs, and board-level stakeholders who
consume the Resilience Scorecard and need assurance without
burdening themselves with cryptographic details.
3. Auditors and Regulators: Independent third parties who need
to re-derive and verify every resilience claim without
trusting any single vendor or organizational assertion.
RRP is intentionally designed to be composable with existing
monitoring systems, CI/CD pipelines, and cloud-native tooling.
Implementers are expected to wrap existing check outputs to produce
canonical RRP evidence records rather than replace their monitoring
stacks wholesale.
The whitepaper from which this protocol is derived, "The Reilly
Resilience Protocol (RRP): A Tamper-Evident, Blockchain-Anchored
Framework for Proving IT, Cloud, and AI System Resilience" (Reilly
Resilience Protocol Whitepaper v2), is permanently archived under:
DOI: 10.5281/zenodo.17100703
https://zenodo.org/records/17100703
The whitepaper was blockchain timestamped and DOI archived on
September 11, 2025, the date of its upload to Zenodo. This
blockchain attestation cryptographically proves the document's
existence and integrity as of that date and constitutes timestamped
prior art for all protocol concepts described herein. See
Section 16 for the treatment of RRP evidence as prior art records
under 35 U.S.C. 102(a)(1) [USC-35-102], consistent with
[DRAFT-REM-02].
1.1. Problem Addressed by This Revision
Revisions -00 and -01 established that an evidence record, once
produced and signed, cannot be altered without detection. That
property is necessary but not sufficient. An assurance system that
proves only the integrity of the records it holds is defeated by an
adversary who arranges for damaging records never to be created,
or who removes an entire aggregation window rather than a record
within one.
Concretely, -01 admitted the following:
Silent omission:
A Control that never executed produced no evidence record.
Nothing in -01 required an implementation to state, in signed
and anchored form, which Controls were supposed to run. A
Scorecard could therefore report a perfect score over the two
Controls that ran while eight others were quietly disabled.
Section 10.3 of -01 mitigated this only for Controls already
known to the Scorecard Generator, which is precisely the set
an adversary would edit.
Whole-window deletion:
Each aggregation window in -01 produced an independent Merkle
root with no cryptographic linkage to the preceding window.
Removing a bad day removed all trace of that day. Nothing in
the surviving anchors was inconsistent with the deletion.
Empty-window silence:
Section 7.2, step (2) of -01 directed that no anchor be
produced when a window contained zero records, and required
only a local log entry. The absence of an anchor was therefore
indistinguishable from the suppression of one.
Unusable privacy posture:
Section 13.4 of -01 required that evidence records exclude PII
and that sensitive artifacts be encrypted, but offered no
mechanism by which a specific field could be disclosed to an
auditor while the remainder stayed confidential. In practice
this pushes implementers toward publishing more than they
should, or toward withholding records entirely.
Ungoverned self-healing:
-01 was silent on automated remediation. Deployed resilience
systems increasingly remediate autonomously, and an unbounded
remediator can both cause harm and mask the very failures the
protocol exists to record.
Merkle construction defect:
Section 7.2, step (3) of -01 duplicated the final digest when
the leaf count was odd, and cited [RFC9162] as the basis.
[RFC9162] and [RFC6962] do not duplicate; they promote the odd
node. Duplication admits distinct leaf sets that produce
identical roots, the malleability class exploited in
CVE-2012-2459 against Bitcoin's tree, and it breaks the
append-only structure that consistency proofs depend on.
This revision closes each of the above. The central design
commitment added in -02 is that an RRP deployment MUST make its
own expectations verifiable: the set of Controls that were
required to run is itself signed, anchored, and chained, so that
the absence of evidence becomes evidence of absence.
1.2. Implementation Status
This section is to be removed before publication as an RFC, in
accordance with the guidance of [RFC7942].
The mechanisms in this revision were developed against running
deployments rather than on paper. At the time of writing:
o A continuity-chained, agent-driven measurement instrument
operates a nine-agent pipeline performing live DNS, HTTPS, and
digest checks against a constellation of eight production
endpoints and eight external permanence anchors, with
hash-linked epoch records, an operator decision queue, and an
autonomous versus human-oversight mode toggle. The anchor
layer distinguishes live, dynamic, and immutable expectations
and forces immutability violations to human review even when
the instrument is in autonomous mode. This deployment is the
direct source of the Anchor Expectation semantics in
Section 7.3 and the Coverage Attestation in Section 9.5.
o A separate rotation-based instrument has committed and
chain-verified more than 2,200 epochs, and a second has
exceeded 22,000 epochs. Operating experience with the second
instrument produced the hysteresis requirement in
Section 10.4 and the remediation circuit breaker in
Section 9.8: an early build entered a state in which a
sentinel agent re-executed the same remediation on every
epoch without ever clearing the underlying condition, which
is the failure mode those two mechanisms exist to prevent.
o A keyless archival mesh operating alongside blockchain
anchoring supplies the third anchor class described in
Section 7.3.
Implementers are cautioned that these are reference deployments
operated by the author and have not been subject to independent
security review.
2. Conventions Used in This Document
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 notation H(x) denotes SHA-256 [FIPS180-4] applied to the octet
string x, unless a migration under Section 7.5 has replaced the
active hash function. The symbol || denotes octet string
concatenation. Hex encoding is lowercase throughout.
3. Terminology
The following terms are defined for the purposes of this document.
Terms introduced in this revision are marked "(new in -02)".
Aggregate Manifest:
A signed document produced at the close of an aggregation
window enumerating the evidence records included in that
window, the records excluded and why, the resulting Merkle
root, the digest of the corresponding Control Coverage
Attestation, the anchor receipts obtained, and the digest of
the preceding Aggregate Manifest.
Anchor Receipt:
A cryptographic proof returned by an anchoring operation which
ties a specific digest to an externally verifiable position in
time, such as a blockchain transaction identifier and block
height, a DOI registration, or a dated archival capture.
Anchor Expectation: (new in -02)
A declaration of the expected mutability class of an anchoring
target, one of "live", "dynamic", or "immutable". A target
declared immutable that is observed to have changed constitutes
an integrity finding and MUST be escalated to human review
irrespective of Autonomy Mode.
Autonomy Mode: (new in -02)
The operating posture of a Remediator with respect to
automated action, one of OBSERVE, SUPERVISED, or AUTONOMOUS.
See Section 9.8.
Blast Radius Class: (new in -02)
A classification, BR0 through BR3, of the potential scope of
harm of a remediation action. See Section 9.8.
Blockchain Timestamping:
The process of publishing a cryptographic digest or Merkle root
to a public blockchain, thereby establishing that the committed
data existed no later than the block in which the commitment
appears. This is distinct from a claim of authorship; it
is a claim of existence-by-time.
Collector:
A software agent or automated process responsible for executing
a specific resilience control check and emitting a normalized
evidence record conforming to the RRP evidence schema defined
in Section 6.
Commitment Root: (new in -02)
The Merkle root computed over the salted per-field commitments
of an evidence record operating in commitment mode. See
Section 6.4.
Control:
A defined, measurable resilience check with associated SLOs.
Examples include database backup restore verification, TLS
certificate expiry checks, AI model drift scans, and network
partition recovery tests.
Control Coverage Attestation (CCA): (new in -02)
A signed statement, produced once per aggregation window,
enumerating every Control in the Control Register that was
expected to execute in that window, the number of valid
evidence records observed for each, and the resulting coverage
ratio. The CCA is what makes omission detectable. See
Section 9.5.
Control Register: (new in -02)
The authoritative, versioned, signed list of Controls an
implementation asserts it operates, together with each
Control's Pillar assignment, schedule, SLO, and compliance
mappings. Changes to the Control Register are themselves
evidence and MUST be recorded and anchored.
DOI Archival:
The process of registering a document or dataset with a Digital
Object Identifier (DOI) through a recognized DOI registration
agency (such as Zenodo/DataCite), providing a persistent,
resolvable identifier that anchors the artifact in a citeable,
academically recognized registry.
Dual-Layer Digital Permanence:
A term originating in the work of L.J. Reilly (see
[DRAFT-REM-02]) describing the combination of DOI archival and
blockchain timestamping as complementary, independent
permanence mechanisms. Neither layer alone is considered
sufficient; both are required for full permanence assurance.
Empty Window Record: (new in -02)
An Aggregate Manifest produced for an aggregation window in
which no valid evidence records were collected. It carries the
Merkle root of the empty set and a coverage ratio of zero, and
is anchored and chained exactly as a populated manifest is. It
exists so that a silent window and a suppressed window are
distinguishable.
Evidence Continuity Chain: (new in -02)
The hash-linked sequence of Aggregate Manifests in which each
manifest commits to the digest of its predecessor, so that
deletion or reordering of any window invalidates every
subsequent link. See Section 7.4.
Evidence Record:
A structured JSON or CBOR document conforming to the RRP
evidence schema that captures the result of a single control
execution, including metadata, SLO outcome, cryptographic
digest, and collector signature.
Evidence Store:
WORM or functionally equivalent immutable object storage in
which evidence records and associated artifacts are preserved
with configurable retention policies.
Field Commitment: (new in -02)
A salted cryptographic commitment to the canonical value of a
single named field of an evidence record, permitting that
field to be disclosed and verified in isolation. See
Section 6.4.
Merkle Root:
The root digest of a Merkle hash tree constructed per
Section 7.2 over all evidence record digests collected within a
given aggregation period (typically one calendar day in UTC).
Migration Bridging Record: (new in -02)
A signed record that binds a chain segment computed under a
retiring hash or signature algorithm to its recomputation under
a successor algorithm, preserving verifiability of historical
evidence across an algorithm transition. See Section 7.5.
Prior Art Record: (new in -02)
An RRP artifact whose dual-layer anchoring establishes a public,
dated, and independently verifiable disclosure of its contents,
as described in [DRAFT-REM-02] and Section 16.
Remediation Event Record (RER): (new in -02)
A signed evidence record documenting a remediation action: its
trigger, Blast Radius Class, Autonomy Mode at execution time,
the authorizing identity where human authorization was
required, the action taken, and the observed outcome.
Remediator: (new in -02)
A component that proposes or executes corrective action in
response to a control result. See Section 9.8.
REM Protocol:
The Reilly EternaMark Protocol. A complementary protocol that
specifies dual-layer digital permanence for arbitrary documents
and data artifacts using DOI registration and blockchain
timestamping, and, from its -02 revision, their function as
prior art records. See [DRAFT-REM-02].
Resilience Scorecard:
A structured report, consumable in PDF or dashboard form, that
presents weighted pillar scores derived from the window's
evidence records, along with the Merkle root, coverage ratio,
anchor receipt references, continuity chain position, and
independently verifiable evidence URIs.
Selective Disclosure Response: (new in -02)
A response to an auditor or regulator request that reveals a
chosen subset of evidence record fields together with their
salts and commitment inclusion proofs, allowing verification
against the anchored Commitment Root without revealing
undisclosed fields.
SLO (Service Level Objective):
A quantitative target associated with a Control. An SLO defines
the threshold below which a control result is classified as PASS,
WARN, or FAIL.
WORM Storage:
Write-Once-Read-Many storage. Storage in which written objects
cannot be modified or deleted for a configured retention period,
providing tamper-evidence for stored evidence records.
4. Protocol Principles
RRP is founded on six design principles. Principles 4.1 through
4.4 are carried forward unchanged from -01. Principles 4.5 and
4.6 are introduced in this revision.
4.1. Test Restores, Not Backups
Backup existence is not proof of recoverability. Recovery
MUST be demonstrated by executing an actual restore operation
and validating that the restored artifact is consistent with
the original. Merely confirming that a backup job completed
is explicitly insufficient evidence under this protocol.
4.2. Evidence Over Narrative
Every resilience claim MUST map to a signed, immutable evidence
record stored at a resolvable URI. Narrative assertions such
as "our system is highly available" MUST be supported by
verifiable evidence records or they carry no weight under RRP.
4.3. Minimum On-Chain
RRP recognizes that publishing full evidence records to public
blockchains raises cost, latency, throughput, and privacy
concerns. Only the daily Merkle root and the continuity chain
head MUST be anchored on-chain. Full evidence records,
artifacts, and supporting logs MUST remain off-chain in the
Evidence Store. The on-chain commitment is sufficient to
provide time attestation for all off-chain evidence linked
through the Merkle tree.
4.4. Composability
RRP is not a replacement for existing monitoring, observability,
or testing infrastructure. Existing systems SHOULD be wrapped
to produce standardized RRP evidence records. A Collector
MAY be a thin adapter that invokes an existing check and
transforms its output into the RRP evidence schema.
4.5. Absence Is a Claim (new in -02)
An implementation MUST publish what it expected to measure,
not only what it succeeded in measuring. Every aggregation
window MUST produce a Control Coverage Attestation and an
Aggregate Manifest, including windows in which nothing was
collected. A verifier MUST be able to determine, from anchored
artifacts alone and without access to internal systems, that a
Control which should have reported did not. Scores MUST be
reduced in proportion to missing coverage rather than computed
over the surviving subset.
4.6. Governed Autonomy (new in -02)
Automated remediation is permitted and expected, but it MUST
be bounded and recorded. Every remediation action MUST carry
a Blast Radius Class, MUST be executed only under an Autonomy
Mode that permits that class, and MUST produce a Remediation
Event Record. Remediation MUST NOT alter the recorded result
of the control execution that triggered it. A failure that
was automatically repaired remains a failure for the window in
which it occurred. Self-healing systems that erase their own
failure signal are outside this protocol.
5. Architecture Overview
5.1. Roles and Responsibilities
RRP defines the following distinct roles within an implementation.
The Coverage Attestor and Remediator roles are new in -02.
Collector:
MUST execute one or more assigned Controls on a configured
schedule. MUST emit a canonical evidence record per execution.
MUST compute the digest of the evidence record prior
to signing. SHOULD be isolated such that compromise of one
Collector does not compromise others.
Signer:
MUST hold a signing key (Ed25519 [RFC8032] or ECDSA P-256) in
a hardware security module (HSM) or Key Management Service
(KMS). MUST sign the digest of each evidence record
using the associated private key. MUST NOT expose the private
key outside the KMS/HSM boundary. A Collector and Signer MAY
be co-located in a single process if the signing key is
protected by a KMS API call rather than in-process memory.
Evidence Store:
MUST accept signed evidence records and associated artifacts
(e.g., restore validation logs, screenshots, structured
test outputs). MUST enforce WORM semantics or functionally
equivalent immutability for the configured retention period
(RECOMMENDED minimum: 7 years for compliance-relevant
implementations). MUST return a stable, resolvable URI for
each stored record. MUST store field salts, where commitment
mode is in use, under access control separate from the records
themselves (Section 6.4).
Coverage Attestor: (new in -02)
MUST read the Control Register in force for the window, MUST
count valid evidence records observed per Control, and MUST
produce and sign a Control Coverage Attestation per
Section 9.5. The Coverage Attestor MUST use a signing key
distinct from any Collector key and SHOULD be operated under
separation of duties from the Collectors whose output it
counts. Where organizationally feasible, the Coverage
Attestor SHOULD be operated by a different team than the
Aggregator.
Aggregator:
MUST retrieve all evidence records produced within the
aggregation window (default: one UTC calendar day). MUST
validate each collector signature before including the record
in the Merkle tree. Records failing signature validation
MUST be excluded and flagged. MUST construct a Merkle tree
over the validated set and compute the root digest per the
algorithm in Section 7.2. MUST retrieve the Control Coverage
Attestation for the window and MUST refuse to produce a
manifest without one. MUST output a signed Aggregate
Manifest referencing all included record URIs, their digests,
the Merkle root, the CCA digest, and the digest of the
preceding Aggregate Manifest per Section 7.4.
Anchor:
MUST publish the Aggregate Manifest digest to at least one
public blockchain within the Anchor Window. The Anchor Window
opens at 00:00:00 UTC on the day following the aggregation
window and MUST close no later than 23:59:59 UTC of that same
day. MUST retain the anchor receipt returned by the anchoring
service. SHOULD publish to a second independent chain to
mitigate single-chain risk. SHOULD additionally place the
manifest with one or more keyless archival services per
Section 7.3.
Remediator: (new in -02)
MAY propose or execute corrective action in response to a
control result. MUST operate under a declared Autonomy Mode.
MUST classify every candidate action by Blast Radius Class and
MUST NOT execute a class the current Autonomy Mode does not
permit. MUST emit a Remediation Event Record for every
proposal and every execution, including refusals. MUST
enforce the circuit breaker of Section 9.8.4. MUST NOT modify,
suppress, or re-run to overwrite the triggering evidence
record.
Scorecard Generator:
SHOULD compute weighted pillar scores per Section 10 and
produce a human-readable Resilience Scorecard in PDF or
dashboard format. The Scorecard MUST include the Merkle root,
an anchor receipt reference, the aggregation date, the
coverage ratio and any Controls reported as missing, the
manifest sequence number, and any weight renormalization
applied. The Scorecard SHOULD include evidence record URIs for
auditor self-service verification.
Verifier:
Any party wishing to independently verify a resilience claim.
A Verifier MUST be able to re-derive evidence digests from
stored records, validate Collector signatures against published
public keys, verify Merkle inclusion proofs linking individual
records to the published Merkle root, confirm the Merkle
root matches the on-chain anchor, verify the continuity chain
across a range of windows, and confirm the Coverage
Attestation against the Control Register, all without trusting
any organizational assertion.
5.2. Data Flow
The following describes the end-to-end data flow for a single
aggregation cycle. Steps (6), (9), and (10) are new in -02.
(1) Collectors execute Control checks on schedule, per the
Control Register in force for the window.
(2) Each Collector produces an evidence record (Section 6)
and computes its digest. Where commitment mode is in use,
the record's digest covers the Commitment Root rather than
the plaintext field values (Section 6.4).
(3) Each Signer signs the digest; the signature is embedded
in the evidence record's "sig" field.
(4) Signed evidence records are submitted to the Evidence Store,
which returns a stable URI for each record.
(5) A Remediator, if deployed, evaluates results and acts within
its Autonomy Mode, emitting Remediation Event Records. The
triggering records are not modified.
(6) At the close of the aggregation window, the Coverage Attestor
produces and signs the Control Coverage Attestation for the
window against the Control Register.
(7) The Aggregator retrieves all records, validates signatures,
and constructs the Merkle tree.
(8) The Aggregator produces the Aggregate Manifest, binding the
Merkle root, the CCA digest, and the digest of the preceding
manifest, and signs it.
(9) The Anchor publishes the manifest digest to the blockchain(s)
and to the archival anchor set, and retains the receipts.
(10) The Scorecard Generator computes pillar scores, applies the
coverage factor and any weight renormalization, and produces
the Resilience Scorecard.
(11) Auditors use the Scorecard's evidence URIs, Merkle root,
CCA, manifest chain, and anchor receipts to independently
verify any claim, and to detect any claim that should have
been made and was not.
A window in which zero valid records were collected still executes
steps (6) through (11). See Empty Window Record in Section 7.4.
6. Evidence Schema
6.1. Evidence Record Structure
Each evidence record MUST be a valid JSON document [RFC8259]
or CBOR document [RFC8949] conforming to the following schema.
JSON is RECOMMENDED for interoperability; CBOR is OPTIONAL for
constrained environments.
The canonical field names and their semantics are as follows.
Fields marked "(new in -02)" were introduced in this revision and
are OPTIONAL for backward compatibility per Section 6.5.
"rrp_version" (string, REQUIRED)
The RRP version string. For records conforming to this
specification: "1.2".
"record_id" (string, REQUIRED)
A globally unique identifier for this evidence record.
MUST be a UUID [RFC9562] formatted as a lowercase
hyphenated string. UUIDv4 or UUIDv7 MAY be used; UUIDv7
is RECOMMENDED in new implementations for its sortable
time prefix.
"record_type" (string, OPTIONAL, new in -02)
One of "control" (default when absent), "remediation", or
"register-change". Remediation Event Records and Control
Register change records share the evidence envelope so that
they are signed, stored, aggregated, and anchored by the
same machinery.
"control_id" (string, REQUIRED)
A stable, human-readable identifier for the Control
that was executed. RECOMMENDED format: reverse-DNS
prefix followed by a descriptive slug (e.g.,
"com.example.db.restore-verify"). MUST correspond to an
entry in the Control Register version referenced by
"register_version".
"control_version" (string, REQUIRED)
The version string of the Control definition in use,
allowing traceability to a specific control specification
revision.
"register_version" (string, OPTIONAL, new in -02)
The version identifier of the Control Register in force at
execution time. REQUIRED when a Control Coverage
Attestation is produced for the window, which under this
revision is always. Retained as OPTIONAL in the schema
only to permit ingestion of -01 records.
"collector_id" (string, REQUIRED)
The stable identifier for the Collector that produced
this record, corresponding to a published public key.
"ts_start" (string, REQUIRED)
Timestamp in the format of [RFC3339] with UTC offset
(ending in "Z") indicating when the Control execution
began.
"ts_end" (string, REQUIRED)
Timestamp in the format of [RFC3339] with UTC offset
indicating when the Control execution completed.
"result" (string, REQUIRED)
One of: "PASS", "WARN", "FAIL", "ERROR". See
Section 6.2 for semantics.
"slo_target" (object, REQUIRED)
An object describing the SLO threshold. MUST contain:
"metric": the metric name (string),
"operator": one of "lte", "gte", "lt", "gt", "eq",
"value": the threshold value (number or string),
"unit": the unit of measurement (string).
"slo_actual" (object, REQUIRED)
The same structure as "slo_target" with the "value"
field set to the actual measured value.
"artifacts" (array, OPTIONAL)
An array of artifact descriptor objects, each containing:
"uri": resolvable URI to the artifact in the Evidence
Store (string, REQUIRED),
"sha256": hex-encoded digest of the artifact
(string, REQUIRED),
"type": MIME type or descriptor (string, OPTIONAL).
"anchor_expectation" (string, OPTIONAL, new in -02)
For Controls that measure an external target, the declared
mutability class of that target: "live", "dynamic", or
"immutable". See Section 7.3.4. A Control whose target is
declared "immutable" and whose measured digest differs from
the sealed baseline MUST produce result FAIL and MUST be
escalated to human review regardless of Autonomy Mode.
"remediation_ref" (array, OPTIONAL, new in -02)
An array of "record_id" values of Remediation Event Records
triggered by this record. Populating this field MUST NOT
change the "result" field or the record's digest; the
reference is carried in a superseding linkage record, not
by mutating the original. See Section 9.8.5.
"metadata" (object, OPTIONAL)
Arbitrary key-value pairs for implementation-specific
metadata. Values MUST be strings.
"commitments" (object, OPTIONAL, new in -02)
Present when the record operates in commitment mode.
MUST contain:
"alg": the commitment construction identifier, currently
"RRP-SHA256-SALT-v1",
"root": hex-encoded Commitment Root (Section 6.4),
"fields": array of committed field paths in canonical
order.
Field values that are committed MAY be omitted from the
record body. Salts MUST NOT appear in the record.
"digest" (string, REQUIRED)
The hex-encoded digest of the canonical
serialization of this record with the "digest" and
"sig" fields set to empty strings. See Section 6.3.
"sig" (object, REQUIRED)
An object containing:
"alg": the signing algorithm ("Ed25519" or "ES256"),
"kid": key identifier referencing the Signer's
published public key,
"value": base64url-encoded signature over "digest".
An example evidence record (JSON, line-wrapped for readability):
{
"rrp_version": "1.2",
"record_id": "01930f6e-8c2a-7c31-9b44-5f2d1c7a9e03",
"record_type": "control",
"control_id": "com.example.db.restore-verify",
"control_version": "2.0.1",
"register_version": "2026-08-01.4",
"collector_id": "collector-db-prod-us-east-1",
"ts_start": "2026-08-24T00:05:00Z",
"ts_end": "2026-08-24T00:23:41Z",
"result": "PASS",
"slo_target": {
"metric": "restore_duration_minutes",
"operator": "lte",
"value": 30,
"unit": "minutes"
},
"slo_actual": {
"metric": "restore_duration_minutes",
"operator": "lte",
"value": 18,
"unit": "minutes"
},
"artifacts": [
{
"uri": "s3://evidence-store/2026-08-24/restore-log.txt",
"sha256": "a3f1...c9d2",
"type": "text/plain"
}
],
"metadata": { "env": "production", "region": "us-east-1" },
"digest": "4e2a...b7f0",
"sig": {
"alg": "Ed25519",
"kid": "collector-db-prod-us-east-1-key-v3",
"value": "base64url-encoded-signature"
}
}
6.2. Control Result Codes
PASS:
The control executed successfully and the measured SLO actual
value satisfies the SLO target threshold. No action required.
WARN:
The control executed successfully but the measured SLO actual
value approaches (within a configurable margin of) the SLO
target threshold, or a non-critical advisory condition was
detected. Implementers SHOULD define warning margins per
control.
FAIL:
The control executed but the measured SLO actual value did
not satisfy the SLO target threshold. FAIL results MUST
trigger alerting and MUST cap the affected pillar score per
Section 10.2.
ERROR:
The control execution itself failed to complete (e.g., the
Collector encountered an infrastructure error, timeout, or
unexpected exception before producing a valid measurement).
ERROR results MUST be treated as FAIL for scoring purposes.
The distinction is retained for operational root-cause
analysis.
There is deliberately no result code meaning "not applicable" or
"skipped". A Control that an implementation does not intend to
run MUST be removed from the Control Register through a recorded
register change (Section 9.1.3), not suppressed at execution
time. Absence of a record for a registered Control is handled by
the Coverage Attestation, not by a self-reported code.
6.3. Canonical Serialization
To compute the "digest" field, implementers MUST:
(1) Set the "digest" field to the empty string "".
(2) Set the "sig" field to {"alg":"","kid":"","value":""}.
(3) Serialize the record to UTF-8 JSON with keys in
lexicographic (alphabetical) order by Unicode code point at
every level of nesting, no insignificant whitespace, and
no trailing newline. Numbers MUST be serialized per the
I-JSON rules of [RFC7493]; implementations SHOULD avoid
floating-point SLO values entirely and express fractional
thresholds in integer units of finer granularity.
(4) Compute the digest over the resulting UTF-8 byte sequence.
(5) Hex-encode the resulting digest (lowercase).
(6) Set the "digest" field to this hex-encoded value.
(7) Sign the "digest" value per Section 7.1.
Implementers using CBOR MUST apply the deterministic encoding
requirements of [RFC8949] Section 4.2 in place of steps (3)
through (4), and MUST record "cbor-det" in the metadata so that
verifiers select the correct serialization.
6.4. Field Commitments and Selective Disclosure
This section is new in -02. It provides the mechanism that -01
lacked for satisfying an auditor's need for a specific fact
without publishing an entire operational record.
6.4.1. Motivation
Resilience evidence is frequently sensitive in aggregate even
when each field is innocuous. Restore durations disclose
database sizes. Collector identifiers disclose topology.
Regulators and customers, however, typically need one field of
one record: that a restore was tested, or that a certificate was
valid on a date. Commitment mode permits that single fact to be
proven against an anchored root while the remainder stays
confidential.
6.4.2. Constructing Field Commitments
For an evidence record R operating in commitment mode:
(1) Determine the set F of committed field paths. A field path
is the JSON Pointer [RFC6901] of the field within R. The
fields "digest", "sig", and "commitments" MUST NOT be
committed. The fields "record_id", "control_id",
"register_version", "ts_end", and "result" MUST be included
in F, since coverage counting and scoring depend on them.
(2) For each field path p in F with canonical value v (serialized
per Section 6.3 as a standalone JSON value):
salt_p = 32 octets from a cryptographically secure
random number generator
c_p = H( 0x02 || salt_p || len(p) || UTF8(p)
|| len(v) || UTF8(v) )
where len(x) is the length of x in octets encoded as a
4-octet unsigned big-endian integer. The 0x02 domain
separation prefix is distinct from the 0x00 leaf prefix and
0x01 interior prefix used in Section 7.2, so that a field
commitment can never be reinterpreted as a tree node.
(3) Sort the pairs (p, c_p) ascending by p, compared as octet
strings.
(4) Compute the Commitment Root over the ordered list of c_p
values using the Merkle construction of Section 7.2.
(5) Populate "commitments" with the algorithm identifier, the
hex-encoded root, and the ordered list of field paths.
(6) Compute the record "digest" per Section 6.3 over the record
as it will be published, that is, with committed field values
omitted where the implementation chooses to omit them.
Salts MUST be unique per field per record. Salts MUST NOT be
derived from the field value, the record identifier, or any other
record content, since such derivation would permit an adversary
holding the commitment to confirm a guessed value.
6.4.3. Selective Disclosure Response
A Selective Disclosure Response is a JSON document containing:
"record_id", "control_id", "register_version" (strings),
"commitment_root" (string, hex),
"disclosed" (array), each element containing:
"path" (JSON Pointer string),
"value" (the canonical field value),
"salt" (base64url),
"proof" (array of hex sibling digests, ordered from leaf
to root, with a bit vector or explicit index
giving left/right position),
"manifest_ref" (URI of the Aggregate Manifest for the window),
"anchor_ref" (array of anchor receipt references).
A recipient verifies a Selective Disclosure Response by
recomputing c_p from the disclosed value and salt, verifying the
inclusion proof against "commitment_root", confirming that the
record digest appears in the referenced Aggregate Manifest,
confirming the manifest digest against the anchor receipts, and
confirming the manifest's position in the continuity chain per
Section 7.4.
6.4.4. Limitations
Commitment mode does not provide confidentiality against an
adversary who obtains the salts. Salts MUST be stored under
access control separate from the evidence records and MUST NOT be
written into the Evidence Store objects that hold the records
themselves.
Low-entropy fields remain guessable to an adversary who obtains a
salt, and the "result" field has four possible values. The
commitment therefore protects against undetected alteration, not
against inference by a salt holder. Implementers requiring
confidentiality against holders of partial disclosures SHOULD
additionally encrypt artifacts at rest and SHOULD NOT rely on
commitment mode alone.
Selective disclosure of a subset of fields can itself be
misleading. The requirement in Section 6.4.2 step (1) that
"result" always be committed and the requirement in Section 9.5
that coverage be attested over the full register together prevent
an implementation from disclosing only its favorable fields
without the omission being visible.
6.5. Version Compatibility
Records bearing "rrp_version": "1.1" remain valid and verifiable.
A Verifier processing a mixed-version window MUST apply the
Merkle construction of the manifest's own version, not the
record's. An Aggregator producing a manifest under this
specification MUST use the construction of Section 7.2 for all
records in the window regardless of the version of the individual
records, and MUST record "construction": "rfc6962" in the
manifest.
Implementations migrating from -01 MUST NOT recompute or
re-anchor historical roots to the corrected construction.
Historical roots remain valid under the construction in force at
the time of anchoring, which is recorded in the manifest. The
continuity chain (Section 7.4) MAY be initialized at the first
manifest produced under this specification, with
"prev_manifest_digest" set to the genesis value and the pre-
migration history referenced through "legacy_ref".
7. Cryptographic Operations
7.1. Evidence Signing
Collector signing keys MUST be one of the following algorithms:
Ed25519 [RFC8032]:
RECOMMENDED. Produces 64-byte signatures. Key pairs are
64 bytes (private) and 32 bytes (public). Deterministic;
does not require a random number generator at signing time.
ECDSA with P-256 and SHA-256 (ES256):
ACCEPTABLE where Ed25519 is not supported by the KMS.
Implementers SHOULD use deterministic ECDSA [RFC6979] to
mitigate nonce-reuse vulnerabilities.
RSA-PSS with SHA-256 (PS256):
MAY be used in legacy environments where neither Ed25519
nor ECDSA is available. Minimum key size: 3072 bits.
NOT RECOMMENDED for new implementations.
All Signer public keys MUST be published in JWK format [RFC7517]
at a stable, resolvable URI and SHOULD be published in a JWK
Set document alongside the collector identity metadata.
Signed evidence records SHOULD additionally be wrapped in a
COSE_Sign1 structure [RFC9052] when interoperability with
COSE-aware verification toolchains is required. Implementations
targeting a transparency service SHOULD express evidence as
signed statements per the SCITT architecture [I-D.SCITT-ARCH],
which allows RRP evidence to be registered on an existing
transparency service rather than an implementation-specific
store.
Post-quantum signature suites are not mandated by this revision.
Implementations with retention horizons beyond the useful life of
classical signatures SHOULD plan for migration per Section 7.5
and MAY dual-sign with ML-DSA [FIPS204] in addition to a
classical algorithm. Where dual signing is used, the "sig" field
MUST carry the classical signature and an additional "sig_pq"
field of identical structure MUST carry the post-quantum
signature; verifiers that do not recognize "sig_pq" ignore it,
and the field is included in the canonical serialization.
7.2. Merkle Tree Construction
This section replaces Section 7.2 of -01 in full. The
construction in -01 duplicated the final digest when the leaf
count was odd. That is the Bitcoin construction, not the
construction of [RFC6962] and [RFC9162], and it was incorrectly
attributed to the latter. Duplication permits two distinct leaf
multisets to yield the same root, and it prevents a tree from
being extended without recomputation, which forecloses
consistency proofs. Implementations of -01 SHOULD migrate to
the construction below for all new windows and MUST NOT
retroactively alter previously anchored roots.
7.2.1. Leaf Ordering
Let the validated record set for the window be ordered ascending
by the tuple (ts_end, record_id), comparing ts_end as an octet
string in [RFC3339] UTC form and record_id as an octet string.
This ordering is deterministic, reproducible by any verifier
from the manifest alone, and monotone in time, so that
concatenating consecutive windows yields an append-only sequence
over which [RFC9162] consistency proofs are well defined.
The digest-sorted ordering specified in -01 is not carried
forward. Sorting by digest destroys temporal order and makes
the concatenation of windows non-monotone, which is why -01 could
not support consistency proofs across windows.
7.2.2. Tree Definition
Let D[n] = {d_1, ..., d_n} be the ordered list of record digests.
The Merkle Tree Hash MTH is defined recursively as in [RFC6962]
Section 2.1:
MTH({}) = H()
that is, the digest of the empty octet string. For
SHA-256 this is:
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b
7852b855
MTH({d_1}) = H( 0x00 || d_1 )
For n > 1, let k be the largest power of two strictly less
than n. Then:
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 domain
separation prefixes prevent second-preimage attacks in which an
interior node is presented as a leaf.
7.2.3. Inclusion and Consistency Proofs
Inclusion proofs for individual evidence records MUST be
generated per [RFC6962] Section 2.1.1 and stored alongside the
Aggregate Manifest, enabling any Verifier to prove that a
specific evidence record is included in the published Merkle root
without requiring access to all other records.
Implementations MAY maintain a single continuous log across
windows in addition to per-window trees. Where they do,
consistency proofs per [RFC6962] Section 2.1.2 MUST be supported,
and verification of a long range of windows SHOULD use the bulk
subtree proof construction of [DRAFT-BSP-01], which verifies a
contiguous span by descent over full subtrees at landmark
breakpoints rather than by one inclusion proof per record. For
an auditor verifying a seven-year retention period, the
difference is between a proof set linear in the number of records
and one logarithmic in the number of windows.
7.2.4. Test Vectors
Implementers MUST validate against the [RFC6962] reference
vectors. For the avoidance of doubt, given three leaf digests
d_1, d_2, d_3 in the order defined by Section 7.2.1:
k = 2
MTH = H( 0x01 || H( 0x01 || H(0x00||d_1) || H(0x00||d_2) )
|| H(0x00||d_3) )
An implementation that instead computes
H( 0x01 || H( 0x01 || H(0x00||d_1) || H(0x00||d_2) )
|| H( 0x01 || H(0x00||d_3) || H(0x00||d_3) ) )
is implementing -01 and is non-conformant with this revision.
7.3. Anchoring
Anchoring in this revision is organized into three classes. An
implementation MUST use at least one anchor from class A and
SHOULD use at least one from each of classes A, B, and C. The
anchored value is the Aggregate Manifest digest, which transitively
commits to the Merkle root, the Coverage Attestation, and the
entire prior chain. Anchoring only the Merkle root, as in -01,
is no longer sufficient.
7.3.1. Class A: Blockchain Anchors
Bitcoin via OpenTimestamps:
The manifest digest is committed using OpenTimestamps
calendar servers. The returned .ots file constitutes the
anchor receipt and MUST be retained alongside the Aggregate
Manifest. RECOMMENDED for implementations prioritizing
immutability and chain longevity.
Ethereum or EVM-Compatible L2:
The manifest digest MAY be submitted as calldata in a standard
transaction, or via a purpose-built contract. The transaction
hash and block number constitute the anchor receipt.
Implementers SHOULD prefer a Layer 2 network with Ethereum
settlement for cost efficiency.
The Anchor Window is defined as the 24-hour UTC period
immediately following the close of the aggregation window.
Anchoring MUST complete within the Anchor Window. Implementers
SHOULD use two independent chains to mitigate the risk of a
single chain reorganization or availability failure invalidating
the anchor.
The on-chain commitment MUST include only the manifest digest
and a minimal protocol identifier. Full evidence records, PII,
and sensitive operational data MUST NOT be published on-chain.
7.3.2. Class B: Persistent Identifier Anchors
The Aggregate Manifest, or a periodic rollup of manifests,
SHOULD be deposited with a DOI registration agency, producing a
citable, dated, resolvable identifier. This is the archival half
of Dual-Layer Digital Permanence per [DRAFT-REM-02]. A monthly
or quarterly rollup deposit is RECOMMENDED in preference to daily
deposits, which impose an unnecessary registration burden.
7.3.3. Class C: Keyless Archival Anchors
Keyless archival services provide independent, third-party dated
custody without requiring an account, key, or fee, and remain
available when an organization's own infrastructure does not.
Implementations SHOULD submit the public manifest URI to two or
more of the following classes of service: general web archives
supporting the Memento framework [RFC7089], national or regional
web archives, source code archives, and open crawl corpora.
Class C anchors are weaker than class A: capture timing is not
under the implementation's control and coverage is best effort.
They MUST NOT be used as the sole anchor for a window. Their
value is corroborative, in that an adversary who compromises both
the organization and its blockchain anchoring path must still
contend with independently held dated copies.
7.3.4. Anchor Expectations for Measured Targets
Where a Control measures an external target rather than an
internal system, the Control Register MUST declare the target's
Anchor Expectation:
live:
The target is expected to be reachable and to return a
success status. Content is expected to change. Only
reachability and status are evaluated.
dynamic:
The target is expected to be reachable and its content is
expected to change within declared bounds, for example a
status endpoint whose schema is stable. Schema conformance
is evaluated; content equality is not.
immutable:
The target's content is expected never to change. A sealed
baseline digest is recorded on first successful observation.
Any subsequent divergence from the baseline MUST produce
result FAIL, MUST be escalated to human review, and MUST NOT
be auto-remediated under any Autonomy Mode, including
AUTONOMOUS. An immutable target that changes is either an
upstream integrity failure or a compromise of the
implementation's own baseline, and neither is a condition an
automated remediator should resolve unattended.
Baselines MUST be sealed only on a response that was actually
received and validated. An implementation MUST NOT seal a
baseline from a timeout, an error page, or a redirect to an
unrelated resource, as doing so silently converts an outage into
a permanent false baseline.
7.4. Evidence Continuity Chain
This section is new in -02.
7.4.1. Rationale
Under -01, each window stood alone. An adversary with sufficient
access could delete a window's manifest, evidence, and anchor
receipt, and no surviving artifact would be inconsistent with the
result. The Evidence Continuity Chain makes each window
cryptographically dependent on its predecessor, so that removing
a window invalidates every window after it. To conceal a single
bad day, an adversary must forge the entire remaining history and
must also defeat the external anchors that already committed to
the original chain.
7.4.2. Aggregate Manifest Structure
The Aggregate Manifest MUST be a JSON document with the following
fields. Canonical serialization and digest computation follow
Section 6.3.
"rrp_version" (string, REQUIRED) "1.2"
"manifest_id" (string, REQUIRED) UUID
"chain_id" (string, REQUIRED)
A stable identifier for this continuity chain, allowing
an organization to operate separate chains per
environment or per regulated entity.
"seq" (number, REQUIRED)
Monotonically increasing integer, starting at 0 for the
genesis manifest of the chain. MUST increase by exactly
1 per window with no gaps.
"window_start" (string, REQUIRED) RFC 3339 UTC
"window_end" (string, REQUIRED) RFC 3339 UTC
"prev_manifest_digest" (string, REQUIRED)
Hex digest of the preceding manifest. For seq = 0 this
MUST be 64 zero characters.
"construction" (string, REQUIRED) "rfc6962"
"merkle_root" (string, REQUIRED)
Hex. For an empty window this is MTH({}) per
Section 7.2.2, not an omitted or null value.
"record_count" (number, REQUIRED)
"included" (array, REQUIRED)
Objects of {"uri", "digest"} in the order of
Section 7.2.1. MAY be replaced by a reference to a
separately stored, digest-committed list where window
sizes make inline inclusion impractical; in that case
"included_ref" and "included_digest" MUST be present.
"excluded" (array, REQUIRED)
Objects of {"record_id", "reason"}. MUST be present and
MUST be an empty array rather than omitted when no
records were excluded.
"cca_digest" (string, REQUIRED)
Hex digest of the Control Coverage Attestation for this
window. A manifest without a CCA digest is
non-conformant.
"coverage_ratio" (number, REQUIRED)
Copied from the CCA for convenience. A verifier MUST
confirm it against the CCA rather than trusting it.
"anchors" (array, REQUIRED)
Objects of {"class", "target", "receipt_uri",
"receipt_digest", "obtained_at"}. MAY be empty at
manifest signing time and completed by an addendum
record per Section 7.4.4.
"legacy_ref" (object, OPTIONAL)
Present only on the genesis manifest of a chain that
continues pre-existing history under a different
construction. Contains {"last_legacy_root",
"last_legacy_window_end", "construction"}.
"digest" (string, REQUIRED)
"sig" (object, REQUIRED)
Aggregator signature, structured as in Section 6.1.
7.4.3. Chain Invariants
A conformant chain satisfies all of the following, and a Verifier
MUST check each:
(1) seq values are consecutive integers with no gaps and no
repeats.
(2) For every manifest M with seq > 0, M.prev_manifest_digest
equals the digest of the manifest with seq = M.seq - 1.
(3) window_start of manifest n+1 equals window_end of manifest n.
No time is unaccounted for between consecutive windows.
(4) Every manifest carries a cca_digest that resolves to a
Coverage Attestation whose window matches the manifest's.
(5) Every manifest is anchored in at least one class A anchor
within its Anchor Window, or carries a late-anchor
explanation per Section 12.2 Scenario 5.
A break in any invariant is a finding. It does not by itself
prove misconduct, since operational failure produces breaks too,
but under this protocol the distinction between misconduct and
incompetence is not the Verifier's to make; both MUST be
reported and both MUST reduce the score for the affected windows.
7.4.4. Anchor Addendum
Because anchoring completes after the manifest is signed, an
implementation MAY sign the manifest with an empty "anchors"
array and subsequently publish an Anchor Addendum, a small signed
record containing the manifest digest and the completed anchor
array. The addendum MUST be committed by the next window's
manifest through inclusion in that window's evidence set, so that
an addendum cannot be silently withdrawn.
7.4.5. Empty Window Records
When a window contains zero valid records, the Aggregator MUST
still produce a manifest, with merkle_root = MTH({}),
record_count = 0, and the window's Coverage Attestation showing
zero of the expected Controls observed. This manifest MUST be
anchored and chained normally.
This replaces the behavior of -01 Section 7.2 step (2), under
which no anchor was produced and only a local log entry was
required. A window that produced nothing and a window whose
evidence was destroyed are, under -01, the same observation from
the outside. Under this revision they are not.
7.5. Hash and Signature Migration
This section is new in -02.
RRP retention horizons are long: seven years is the RECOMMENDED
minimum for compliance deployments, and archival deposits under
class B anchors are intended to be permanent. These horizons
exceed the confident lifetime of any particular hash or signature
algorithm. A protocol that does not plan for migration will
eventually hold a large volume of evidence that no longer
verifies.
7.5.1. Migration Bridging Record
To migrate from a retiring algorithm OLD to a successor NEW, the
implementation MUST produce a Migration Bridging Record (MBR)
containing:
"chain_id", "seq_from", "seq_to"
The contiguous chain segment being bridged.
"old_alg", "new_alg"
Algorithm identifiers.
"segment_root_old"
The root, computed under OLD, over the digests of the
manifests in the segment.
"segment_root_new"
The root, computed under NEW, over the same manifests
in the same order.
"manifest_map"
An ordered list of {"seq", "digest_old", "digest_new"}.
"attested_at", "attestor_id"
"sig_old", "sig_new"
The MBR MUST be signed under both the retiring and the
successor signature algorithms.
The MBR MUST itself be anchored under class A using the successor
algorithm, and SHOULD be anchored under the retiring algorithm as
well while that remains available.
7.5.2. Migration Requirements
(1) Migration MUST NOT rewrite historical manifests, records, or
roots. Original artifacts are retained unmodified; the MBR
is additive.
(2) An MBR MUST be produced while the retiring algorithm is still
considered sound. A bridging record signed after the
retiring algorithm is broken carries no more assurance than
the broken algorithm itself. Implementers SHOULD treat the
first credible published weakening of an algorithm, rather
than its formal deprecation, as the trigger to bridge.
(3) The active hash for new windows changes at a declared
manifest sequence number, which MUST be recorded in the
manifest at which the change takes effect.
(4) Verifiers encountering a segment under a retired algorithm
MUST report the verification as conditional on the MBR and
MUST identify the MBR relied upon.
(5) A chain with no MBR covering a retired-algorithm segment is
verifiable only to the strength of the retired algorithm,
and a Verifier MUST say so rather than reporting success.
8. Key Management
Proper key management is essential to the integrity of all RRP
evidence. The following requirements apply. Requirements (8)
through (10) are new in -02.
(1) All Signer private keys MUST be stored in a hardware security
module (HSM) or a cloud KMS with HSM-backed key storage.
(2) Private keys MUST NOT be stored in filesystem files, source
control, container images, or environment variables.
(3) Each Collector MUST have a distinct signing key pair.
Shared keys across Collectors are NOT RECOMMENDED as they
prevent individual Collector attribution in the event of
compromise.
(4) Collector public keys MUST be published to a well-known
endpoint prior to the Collector emitting any evidence
records. The published JWK Set MUST be updated within 24
hours of any key rotation.
(5) Signing keys MUST be rotated at least annually. Key
rotation MUST NOT invalidate previously issued signatures.
The previous public key MUST remain published and
resolvable for the duration of the evidence retention
period.
(6) Key compromise MUST be declared by publishing a revocation
notice at the public key endpoint within 24 hours of
discovery. All evidence records signed by the compromised
key after the declared compromise time MUST be treated
as invalid.
(7) Implementers SHOULD maintain an out-of-band key backup
in a geographically separate HSM to enable recovery
without evidence continuity interruption.
(8) The Aggregator signing key, the Coverage Attestor signing
key, and every Collector signing key MUST be distinct, and
the Aggregator and Coverage Attestor keys MUST NOT be
usable by any Collector process. The purpose of the
Coverage Attestation is defeated if the same principal can
both suppress a record and attest that it was never
expected.
(9) The Coverage Attestor key SHOULD be held under separation of
duties from the Aggregator key, such that no single
operator can authorize use of both. Where an organization
cannot achieve this, it MUST disclose the limitation in the
Scorecard, because a verifier cannot otherwise distinguish
an attested coverage claim from a self-issued one.
(10) Key revocation MUST NOT invalidate the continuity chain.
Manifests signed by a revoked Aggregator key before the
declared compromise time remain valid links. The chain
MUST continue under the successor key with no gap in seq,
and the key transition MUST be recorded as an evidence
record of type "register-change".
9. Operational Procedures
9.1. Control Definition and the Control Register
9.1.1. Control Requirements
Implementers MUST define a minimum of 5 Controls and SHOULD
define 8 to 12 for a production deployment. Each Control MUST
have:
(a) A stable "control_id" (reverse-DNS format RECOMMENDED).
(b) A human-readable description and rationale.
(c) A measurable SLO target with a specific metric, operator,
threshold value, and unit.
(d) An assigned Collector or set of Collectors.
(e) An execution schedule (RECOMMENDED: at minimum once per
24-hour period), expressed as an expected record count per
aggregation window so that coverage can be counted rather
than inferred.
(f) An assigned Pillar (Section 10.1).
(g) A declared Anchor Expectation where the Control measures an
external target (Section 7.3.4).
(h) Mapping to at least one compliance framework control (see
Section 11) where applicable.
The following are RECOMMENDED baseline Controls:
Backup Restore Verification:
Execute a full restore of a production backup to an
isolated environment. Validate restored artifact
consistency. SLO example: restore completes in <= 30 min
with 100% data integrity checksum match.
TLS Certificate Expiry:
Verify all externally facing TLS certificates have
remaining validity > N days (RECOMMENDED: N >= 30).
Database Replication Lag:
Confirm replication lag across all read replicas is
below a defined threshold.
AI Model Drift Scan:
Compare current inference distribution against a
validated baseline distribution. Trigger WARN if
drift exceeds a configurable threshold; FAIL if it
exceeds a critical threshold.
Network Partition Recovery:
Inject a controlled network partition and verify
that the system recovers within the defined RTO.
Incident Response Drill:
Log evidence of a completed tabletop or live incident
response exercise, including participant count, scenario,
and findings.
Anchor Integrity Check: (new in -02)
Verify that each declared external anchor target still
resolves and, for targets declared immutable, still
matches its sealed baseline digest.
9.1.2. The Control Register
The Control Register is the signed, versioned document that
enumerates every Control the implementation asserts it operates.
It MUST contain, for each Control, the fields of Section 9.1.1,
and MUST carry a "register_version" identifier, an
"effective_from" timestamp, the digest of the preceding register
version, and an Aggregator or Coverage Attestor signature.
The Control Register MUST be published at a resolvable URI, MUST
be stored in the Evidence Store, and its digest MUST be committed
through the Coverage Attestation of every window in which it is
in force.
The Register is the anchor of the whole omission-resistance
property. Without a signed, versioned, externally visible
statement of what was supposed to run, coverage is
self-reported and worthless.
9.1.3. Register Changes
Adding, removing, retiring, or materially altering a Control MUST
produce an evidence record of "record_type": "register-change"
containing the prior and new register versions, the affected
control_ids, the nature of the change, the authorizing identity,
and a stated reason. That record is signed, stored, aggregated,
and anchored like any other.
Removing a Control is therefore permitted and is not treated as
misconduct. It is treated as a dated, signed, publicly
verifiable decision by a named party, which is the property that
matters. An organization that quietly stops testing restores
and an organization that documents a decision to stop testing
restores are distinguishable under this revision, and were not
under -01.
9.2. Evidence Collection
Each Collector MUST:
(1) Execute the assigned Control check at the scheduled time.
(2) Record ts_start immediately before execution begins.
(3) Capture raw output, logs, and any relevant artifacts.
(4) Map the result to one of: PASS, WARN, FAIL, ERROR.
(5) Populate all REQUIRED fields of the evidence schema
(Section 6.1), including "register_version".
(6) Store raw artifacts in the Evidence Store and populate
the "artifacts" array with their URIs and digests.
(7) Where commitment mode is in use, generate salts and compute
the Commitment Root per Section 6.4.
(8) Compute the canonical serialization (Section 6.3) and
set the "digest" field.
(9) Submit the pre-signature record to the Signer.
Collectors MUST be designed to be idempotent with respect to
re-execution. A re-run of the same Control within the same
aggregation window MUST produce a new record with a unique
"record_id"; it MUST NOT overwrite the prior record.
A Collector that cannot complete a check MUST emit an ERROR
record. Emitting nothing is not an acceptable response to a
failed check, and under Section 9.5 will be counted as missing
coverage rather than as silence.
9.3. Signing and Storage
The Signer MUST:
(1) Receive the pre-signature evidence record from a Collector
over an authenticated, encrypted channel (TLS 1.3 REQUIRED
per [RFC8446]).
(2) Re-compute the canonical digest and verify it matches
the submitted "digest" field before signing. A mismatch
MUST result in rejection of the record.
(3) Sign the digest using the Collector's assigned private key.
(4) Return the signed evidence record to the Collector.
The Evidence Store MUST:
(1) Accept only signed evidence records (records missing a
valid "sig" block MUST be rejected).
(2) Verify the Collector signature against the published
public key before storing.
(3) Return a stable, resolvable URI for the stored record.
(4) Enforce the configured WORM retention period.
(5) Store field salts, where present, in a separate access-
controlled store, and never in the same object as the
record.
9.4. Aggregation and Anchoring
At the close of each aggregation window, the Aggregator MUST:
(1) Query the Evidence Store for all records with "ts_end"
falling within the closed window.
(2) For each record, validate the Collector signature against
the published JWK Set. Exclude records failing validation.
(3) Log all excluded records with the reason for exclusion, and
carry that list into the manifest's "excluded" array.
(4) Order the validated set per Section 7.2.1 and construct the
Merkle tree per Section 7.2.2.
(5) Retrieve the Control Coverage Attestation for the window
and verify its signature. If no valid CCA exists, the
Aggregator MUST NOT publish a manifest claiming coverage;
it MUST publish a manifest with coverage_ratio 0 and an
explicit exclusion reason naming the missing attestation.
(6) Retrieve the preceding manifest for this chain_id and
compute its digest.
(7) Produce and sign the Aggregate Manifest per Section 7.4.2.
(8) Store the Aggregate Manifest in the Evidence Store.
(9) Submit the manifest digest to the Anchor across the
configured anchor classes.
(10) Receive and store the anchor receipts, publishing an Anchor
Addendum where receipts arrive after signing.
The Aggregator MUST NOT exclude a record on any ground other
than signature validation failure, schema invalidity, or
ts_end falling outside the window. In particular, a record MUST
NOT be excluded on the basis of its "result" value.
9.5. Control Coverage Attestation
This section is new in -02 and is the principal addition of this
revision.
9.5.1. Purpose
The Coverage Attestation converts the absence of evidence into a
positive, signed, anchored claim. Under -01, a verifier could
confirm that every record present was authentic, and could
confirm nothing at all about records that were never created.
Under this revision, an implementation states in advance what it
will produce and states afterward what it did produce, and both
statements are anchored.
9.5.2. Structure
The CCA MUST be a JSON document containing:
"rrp_version" (string, REQUIRED) "1.2"
"cca_id" (string, REQUIRED) UUID
"chain_id" (string, REQUIRED)
"window_start", "window_end" (strings, REQUIRED)
"register_version" (string, REQUIRED)
"register_digest" (string, REQUIRED)
Digest of the Control Register in force for the window.
"controls" (array, REQUIRED)
One entry per Control in the Register, each containing:
"control_id",
"pillar",
"expected_count" (number, from the schedule),
"observed_count" (number, valid records seen),
"observed_digests" (array of record digests, or a
digest-committed reference),
"status": one of "COMPLETE" (observed >= expected),
"PARTIAL" (0 < observed < expected),
"MISSING" (observed = 0).
"expected_total", "observed_total" (numbers, REQUIRED)
"coverage_ratio" (number, REQUIRED)
Computed per Section 9.5.3.
"attestor_id" (string, REQUIRED)
"digest", "sig" (REQUIRED)
Every Control in the Register MUST appear in the "controls"
array, including those with observed_count 0. A CCA that omits
registered Controls is non-conformant, and a Verifier MUST reject
it by comparing the control_id set against the register at
"register_digest".
9.5.3. Coverage Ratio
Coverage is computed per Control and then aggregated, so that one
Control emitting many records cannot compensate for another
emitting none:
cov(c) = min( observed_count(c) / expected_count(c), 1.0 )
coverage_ratio = ( sum over c in Register of cov(c) )
/ |Register|
Per-Pillar coverage, used in scoring per Section 10.2, is:
cov_P = ( sum over c in C_P of cov(c) ) / |C_P|
where C_P is the set of registered Controls assigned to Pillar P.
9.5.4. Attestation Requirements
(1) A CCA MUST be produced for every window, including windows
with zero records.
(2) The CCA MUST be produced by a principal whose signing key is
distinct from the Collector keys whose output it counts, per
Section 8 requirement (8).
(3) The CCA MUST be committed by the window's Aggregate Manifest
through "cca_digest", and is therefore anchored transitively.
(4) A Verifier MUST recompute coverage_ratio from the "controls"
array rather than trusting the stated value, and MUST
recompute observed_count from the manifest's included record
set rather than trusting the attestor. The attestation is
a claim; the manifest is the evidence for it. Where the two
disagree, the manifest governs and the disagreement is a
finding.
(5) The CCA MUST NOT be back-dated or amended. A correction is
issued as a new record of type "register-change" in a
subsequent window, referencing the CCA corrected.
9.6. Scorecard Publication
The Scorecard Generator SHOULD publish the Resilience Scorecard
within 4 hours of the Anchor completing its class A commitment.
The Scorecard MUST include:
(a) The aggregation date (UTC) and the manifest "seq".
(b) The overall RRP composite score (0-100).
(c) Per-pillar scores with weights, effective weights after any
renormalization, and contributing controls.
(d) Result summary (counts of PASS, WARN, FAIL, ERROR).
(e) The coverage ratio, per-pillar coverage, and an explicit
list of every Control with status PARTIAL or MISSING.
(f) The Merkle root for the period.
(g) The prev_manifest_digest and the chain_id.
(h) A reference to each anchor receipt (class, chain or service,
and txid or proof identifier).
(i) Evidence Store URIs for all included records.
(j) Any Remediation Event Records in the window at BR2 or above,
summarized with their Autonomy Mode and authorizing party.
(k) Any separation-of-duties limitation disclosed per Section 8
requirement (9).
A Scorecard that reports a composite score without reporting
coverage is non-conformant with this revision. The two figures
are meaningless apart: a score of 98 over 30% coverage is a
weaker claim than a score of 82 over full coverage, and a
Scorecard that presents only the former is misleading whether or
not it intends to be.
The Scorecard SHOULD be produced in a machine-parseable format
(JSON) in addition to a human-readable format (PDF).
9.7. Independent Verification
Any Verifier MUST be able to perform the following steps without
access to internal systems or organizational trust. Steps (10)
through (13) are new in -02.
(1) Retrieve a specific evidence record from its published URI.
(2) Re-compute the canonical serialization and digest,
confirming it matches the "digest" field in the record.
(3) Retrieve the Collector's public key from the published JWK
Set using the "kid" in the "sig" field.
(4) Validate the signature in the "sig" field over the "digest"
value using the retrieved public key.
(5) Retrieve the Aggregate Manifest for the relevant window.
(6) Confirm the record's digest appears in the manifest's
included record list.
(7) Recompute the Merkle root from the manifest's record list
per Section 7.2, using the ordering of Section 7.2.1 and the
construction named in the manifest's "construction" field.
(8) Confirm the recomputed Merkle root matches the manifest's
stated Merkle root.
(9) Confirm the manifest digest matches the on-chain commitment
by independently querying the referenced blockchain, and
confirm the commitment height precedes the close of the
Anchor Window.
(10) Retrieve the Control Register at the manifest's
register_version, retrieve the CCA at "cca_digest", and
confirm that every registered Control appears in the CCA.
(11) Recompute observed_count for each Control from the
manifest's included set and confirm it matches the CCA,
then recompute coverage_ratio.
(12) Walk the continuity chain across the range of interest,
confirming the invariants of Section 7.4.3.
(13) Where the range spans an algorithm migration, retrieve the
Migration Bridging Record and confirm the segment roots
under both algorithms, reporting the verification as
conditional on that MBR.
A Verifier completing all thirteen steps has independently
confirmed both that the evidence presented is authentic and that
no evidence which should have been presented is absent. The
second property did not exist in -01.
9.8. Autonomous Remediation and Human Oversight
This section is new in -02.
9.8.1. Scope
Deployed resilience systems increasingly act on what they
measure. An agent that restarts a failed collector, rotates a
near-expiry certificate, or fails over a lagging replica is
operationally valuable and is not, in itself, contrary to this
protocol. Two failure modes are. The first is an automated
action whose scope exceeds the confidence warranted by the
signal that triggered it. The second is a remediation loop that
repairs a symptom on every cycle without ever clearing the
cause, so that the Scorecard reports health while the underlying
fault persists indefinitely.
Both were observed in the reference deployments described in
Section 1.2, and the mechanisms below exist because of them.
9.8.2. Blast Radius Classes
Every candidate remediation MUST be classified before execution:
BR0:
Observation, diagnosis, notification, or ticket creation.
No change to system state.
BR1:
Reversible change confined to a single instance or process
with no customer-visible effect, such as restarting a
collector or clearing a local cache.
BR2:
Reversible change spanning multiple instances or altering
configuration within a single failure domain, with a defined
and tested rollback path.
BR3:
Change that is cross-domain, data-destructive, irreversible,
or security-critical. This includes primary datastore
failover, deletion or truncation of data, credential or key
rotation in response to suspected compromise, modification of
the Control Register, and any change to WORM retention
settings.
BR3 actions MUST NOT be executed automatically under any
Autonomy Mode. They MUST be queued for human authorization, and
the authorizing identity MUST be recorded in the RER.
Where classification is ambiguous, the higher class MUST be
assigned.
9.8.3. Autonomy Modes
OBSERVE:
The Remediator MAY propose actions and MUST NOT execute any.
All proposals enter the decision queue.
SUPERVISED:
The Remediator MAY execute BR0 and BR1 automatically. BR2 and
BR3 enter the decision queue.
AUTONOMOUS:
The Remediator MAY execute BR0, BR1, and BR2 automatically.
BR3 enters the decision queue.
The active Autonomy Mode MUST be recorded in every RER. A change
of Autonomy Mode is itself a BR3 action.
Regardless of mode, a finding arising from an Anchor Expectation
of "immutable" (Section 7.3.4) MUST be escalated and MUST NOT be
auto-remediated.
9.8.4. Circuit Breaker
A Remediator MUST maintain, per (control_id, action_type) pair, a
count of automated executions within a rolling window. When the
count exceeds a configured threshold (RECOMMENDED: 3 executions
in 24 hours) without the triggering condition clearing for at
least one full aggregation window, the Remediator MUST:
(1) Suspend automated remediation for that pair.
(2) Emit an RER with the suspension and the observed counts.
(3) Escalate to human review.
(4) Continue to allow the underlying control to record FAIL
results, which MUST continue to affect the score.
The purpose is to prevent a Remediator from converting a
persistent fault into an indefinite sequence of successful
repairs. A system that repairs the same thing every hour is not
resilient; it is failing every hour, and the Scorecard MUST
report it that way.
9.8.5. Result Immutability Under Remediation
Remediation MUST NOT alter the recorded result of the triggering
evidence record. Specifically:
(1) The triggering record MUST NOT be modified, deleted, or
excluded from the window.
(2) A Collector MUST NOT re-run a Control after remediation and
submit the passing result in place of the failing one. A
post-remediation verification check MAY be run and MUST be
recorded as an additional record; both records are included
in the window and both are scored.
(3) Linkage between a triggering record and its RERs is carried
by a separate linkage record referencing both digests, never
by mutating the original record.
(4) Where the same Control produces both FAIL and a subsequent
PASS in one window, the scoring function of Section 10.2
MUST use the worst result observed for that Control in the
window, not the most recent and not the mean.
9.8.6. Remediation Event Record
An RER is an evidence record with "record_type": "remediation"
whose "metadata" MUST include: "trigger_record_digest",
"blast_radius" (BR0-BR3), "autonomy_mode", "action_type",
"action_description", "authorized_by" (identity, or the literal
"automated"), "outcome" (one of "executed", "queued", "refused",
"failed"), and "rollback_available" (boolean).
RERs are signed, stored, aggregated, and anchored identically to
control records, and are therefore subject to the same
tamper-evidence and the same coverage accounting.
10. Resilience Scorecard Specification
10.1. Pillars, Weights, and Renormalization
RRP organizes resilience across five standard Pillars.
Implementers MAY redefine pillar weights for their specific
risk profile, provided weights sum to 1.0 (100%). The default
weights are:
+------------------------------+--------+---------+
| Pillar | Symbol | Weight |
+------------------------------+--------+---------+
| Recovery Capability | RC | 0.25 |
| Availability & Continuity | AC | 0.25 |
| Security Integrity | SI | 0.20 |
| AI Pipeline Resilience | AI | 0.15 |
| Operational Compliance | OC | 0.15 |
+------------------------------+--------+---------+
| Total | | 1.00 |
+------------------------------+--------+---------+
Each Control in the Register MUST be assigned to exactly one
Pillar. Implementers SHOULD ensure at least one Control is
assigned to each active Pillar.
Renormalization (new in -02). Revision -01 did not define the
composite score when a Pillar had no assigned Controls; the
summation simply lost that weight, silently deflating the
composite by up to 25 points and making an implementation with
fewer Pillars look worse than one with more, irrespective of
resilience. The following rule applies:
(1) Let A be the set of Pillars with at least one Control in the
Control Register. If A is empty, the composite score is 0.
(2) For each P in A, the effective weight is:
w_eff(P) = weight_P / ( sum over Q in A of weight_Q )
(3) Pillars not in A contribute nothing and their weight is
redistributed proportionally by (2).
(4) The Scorecard MUST list every Pillar not in A and MUST
publish the effective weights used.
(5) Renormalization applies only to Pillars with no registered
Controls. A Pillar whose registered Controls all failed to
report MUST NOT be renormalized away. That case is
missing coverage and is handled by Section 10.2, which
reduces the score. This distinction is deliberate:
renormalization must never become a mechanism by which
failing to measure improves the reported score.
10.2. Scoring Algorithm
For each Pillar P in A, let:
C_P = set of registered Controls assigned to P
O_P = subset of C_P that produced at least one valid,
non-stale evidence record in the window
r(c) = worst result observed for Control c in the window,
mapped PASS=100, WARN=75, FAIL=0, ERROR=0
cov_P = per-Pillar coverage from Section 9.5.3
The raw pillar score over observed Controls is:
raw_P = ( sum of r(c) for c in O_P ) / |O_P|,
or 0 if |O_P| = 0
The coverage-adjusted pillar score is:
adj_P = raw_P * cov_P
The capped pillar score is:
If any c in O_P has result FAIL or ERROR, or cov_P < 1.0:
pillar_P = min( adj_P, 60 )
Else:
pillar_P = adj_P
The composite RRP score is:
RRP_score = sum over P in A of ( w_eff(P) * pillar_P )
The composite score is a value in [0, 100].
Two changes from -01 are load-bearing. First, r(c) is the worst
observed result rather than an average over records, so that a
Control which fails once and passes nine times in a window is
scored as having failed. Second, adj_P multiplies by coverage
and incomplete coverage triggers the same 60 cap as an outright
failure, so that not measuring is never scored better than
measuring and finding a problem. Under -01, disabling a failing
Control raised the score. Under this revision it lowers it.
10.3. Score Decay
Evidence currency is critical to the integrity of the Scorecard.
To prevent stale evidence from inflating scores:
(1) If a Control has not produced any evidence record within
the 48-hour period ending at scorecard generation time,
its result MUST be treated as ERROR for scoring purposes
and its observed_count for coverage purposes MUST be 0.
(2) If a Control's most recent record is treated as ERROR
due to staleness, the Scorecard Generator MUST annotate
the Scorecard with a "stale evidence" warning for that
Control.
(3) Implementers MAY define shorter decay windows for higher-
frequency controls (e.g., controls scheduled hourly may
apply a 4-hour decay window). Decay windows MUST be
declared in the Control Register and MUST NOT be adjusted
retroactively for a window already scored.
10.4. Band Assignment and Hysteresis
For reporting purposes, RECOMMENDED bands are:
[90, 100]: Excellent - All controls passing with strong SLO
margin and full coverage.
[75, 90): Good - Minor warnings present; review recommended.
[60, 75): Moderate - Multiple warnings, a capped pillar, or
incomplete coverage; remediation required.
[0, 60): At Risk - One or more critical failures or
substantially incomplete coverage; immediate
remediation required.
Hysteresis (new in -02). Band assignment MUST be asymmetric:
(1) A downward band transition takes effect immediately, in the
first window whose composite score falls below the current
band's floor.
(2) An upward band transition takes effect only after two
consecutive windows at or above the higher band's floor.
This asymmetry is intentional. A score oscillating around a
boundary should be reported at the lower band, because the
condition producing the oscillation has not been resolved.
Symmetric banding permits a system to be reported as Excellent on
alternate days while a genuine intermittent fault persists, and
operational experience with the reference deployments in
Section 1.2 produced exactly that pattern before hysteresis was
introduced.
(3) The Scorecard MUST report both the raw band implied by the
current composite score and the effective band after
hysteresis, so that the mechanism is visible rather than
appearing as a reporting lag.
11. Compliance Mapping
RRP evidence records directly support audit evidence requirements
across the following frameworks. Mappings marked "(new in -02)"
were added in this revision.
SOC 2 (Trust Services Criteria):
CC7.1 (System Monitoring), CC7.2 (Anomaly Identification),
CC7.3 (Evaluation of Security Events), A1.2 (Recovery Plan
Testing), A1.3 (Recovery Objectives).
RRP Pillars: Recovery Capability, Availability & Continuity.
The Coverage Attestation is directly responsive to the
completeness assertions an auditor makes about a population
of controls, which is ordinarily established by inquiry and
sampling rather than by cryptographic means.
ISO/IEC 27001:2022:
Annex A 5.29 (Information Security During Disruption),
Annex A 5.30 (ICT Readiness for Business Continuity),
Annex A 8.6 (Capacity Management),
Annex A 8.16 (Monitoring Activities).
RRP Pillars: Recovery Capability, Operational Compliance.
ISO/IEC 42001:2023 (AI Management Systems): (new in -02)
Clauses on operational planning and control, performance
evaluation, and continual improvement for AI systems.
RRP Pillar: AI Pipeline Resilience. Evidence of model drift
scanning and of the remediation governance in Section 9.8
supports the operational control requirements.
NIST SP 800-53 Rev 5:
CP-4 (Contingency Plan Testing), CP-9 (System Backup),
CP-10 (System Recovery and Reconstitution),
SI-7 (Software, Firmware, and Information Integrity),
SI-12 (Information Management and Retention),
AU-9 (Protection of Audit Information),
AU-10 (Non-Repudiation).
RRP Pillars: all. AU-9 and AU-10 (new in -02) are the
closest existing analogues to the tamper-evidence and
continuity properties this protocol provides.
NIST AI RMF 1.0: (new in -02)
MEASURE 2.6 (deployed system safety), MANAGE 2.4
(mechanisms for deactivation and remediation).
RRP Pillar: AI Pipeline Resilience.
PCI DSS v4.0:
Requirement 10 (Log and Monitor All Access),
Requirement 11.6 (Change Detection),
Requirement 12.10 (Incident Response Plan).
RRP Pillars: Security Integrity, Operational Compliance.
HIPAA Security Rule (45 CFR Part 164):
164.308(a)(7) (Contingency Plan), 164.312(c)(1) (Integrity),
164.312(b) (Audit Controls).
RRP Pillars: Recovery Capability, Security Integrity.
Implementations in this domain SHOULD operate in commitment
mode (Section 6.4) so that evidence can be disclosed to an
auditor without exposing the operational detail that
accompanies it.
DORA (EU Digital Operational Resilience Act):
Article 11 (Response and Recovery), Article 12 (Backup
Policies and Restoration), Article 25 (Testing of ICT Tools
and Systems), Article 26 (Threat-Led Penetration Testing).
RRP Pillars: Recovery Capability, Availability & Continuity,
Operational Compliance.
NIS2 Directive (EU 2022/2555): (new in -02)
Article 21(2)(b) (incident handling), 21(2)(c) (business
continuity and backup management), 21(2)(f) (assessing
effectiveness of risk-management measures).
RRP Pillars: Recovery Capability, Operational Compliance.
Article 21(2)(f) requires assessment of effectiveness, which
is a claim about the measurement regime rather than about any
individual measurement, and is therefore addressed by the
Coverage Attestation rather than by evidence records alone.
EU AI Act (Regulation 2024/1689): (new in -02)
Article 12 (record-keeping and automatic logging),
Article 15 (accuracy, robustness, and cybersecurity),
Article 17 (quality management system),
Article 26 (deployer obligations, including log retention).
RRP Pillars: AI Pipeline Resilience, Operational Compliance.
Where an RRP deployment measures an AI system subject to the
Act, the evidence records and Remediation Event Records
together constitute the automatically generated logs
contemplated by Article 12, and Section 7.5 addresses the
retention horizon. Governance-specific record types are
treated more fully in [DRAFT-AIGOV-00].
SEC Cybersecurity Disclosure Rules (17 CFR 229.106):
(new in -02)
Item 106(b) (risk management processes) and Item 1.05 of
Form 8-K (material incident disclosure). RRP evidence
provides dated, externally anchored support for statements
about the existence and operation of resilience processes,
and the continuity chain provides a defensible basis for
statements about when a condition was first observed.
Implementers SHOULD include compliance framework mapping metadata
in the Control Register and in the "metadata" field of evidence
records to facilitate automated compliance reporting.
This mapping is informative. Nothing in this document
constitutes legal advice, and mapping a Control to a framework
citation does not establish that any regulator will accept the
resulting evidence as sufficient.
12. Threat Model
12.1. Adversary Classes
RRP considers the following adversary classes. The Omission
Adversary is new in -02 and motivates most of this revision.
Internal Attacker (IA):
An employee or contractor with access to Collector
infrastructure who may attempt to falsify evidence records
or suppress evidence of failures.
External Attacker (EA):
An adversary without initial access who may attempt to
tamper with stored evidence records, compromise Collector
signing keys, or perform a blockchain reorganization.
Omission Adversary (OM): (new in -02)
An adversary, typically internal and often acting without
any intent recognizable as attack, whose method is to
arrange that unfavorable evidence is never produced. The OM
disables a Collector, narrows a Control's scope, removes a
Control from the schedule, or simply lets a broken Collector
remain broken. The OM defeats -01 entirely, because every
record that -01 verifies remains authentic. The OM is the
most common adversary in practice, and is frequently
indistinguishable at the technical level from ordinary
operational neglect.
Collusion (CO):
Two or more internal parties (e.g., Collector operator
and Evidence Store administrator) colluding to produce
and store fraudulent evidence records.
Availability Adversary (AA):
An adversary whose goal is to prevent the Anchor from
publishing within the Anchor Window, thereby creating gaps
in the evidence chain.
12.2. Attack Scenarios and Mitigations
Scenario 1: Evidence Record Tampering
Threat: IA or EA modifies an evidence record after storage.
Impact: Fraudulent resilience claim.
Mitigation: WORM Evidence Store prevents modification.
Verification: Canonical digest mismatch detected by any
Verifier recomputing the digest.
Scenario 2: Collector Key Compromise
Threat: EA compromises a Collector's private signing key
and generates fraudulent signed evidence records.
Impact: Fraudulent records accepted by the Aggregator.
Mitigation: HSM/KMS key storage (Section 8 requirement 1).
Key revocation (Section 8 requirement 6) limits forward
impact. Per-Collector keys (Section 8 requirement 3)
limit blast radius.
Scenario 3: Aggregator Manipulation
Threat: IA manipulates Aggregator to exclude FAIL records
from the Merkle tree or compute an incorrect root.
Impact: Inflated score, incomplete audit trail.
Mitigation: Aggregate Manifest is signed and stored in WORM.
The "excluded" array is mandatory and non-omittable
(Section 7.4.2). Section 9.4 forbids exclusion on the
basis of result. The Coverage Attestation is produced by a
separate principal and counts records the Aggregator would
have to have included, so an excluded FAIL appears as a
discrepancy between CCA observed_count and manifest content,
which Section 9.5.4(4) requires the Verifier to check.
Scenario 4: On-Chain Reorg
Threat: EA performs a blockchain reorganization that removes
the anchor transaction.
Impact: Anchor receipt invalidated.
Mitigation: Wait for sufficient confirmation depth before
treating an anchor as finalized. RECOMMENDED: 6 blocks
for Bitcoin, finalized checkpoint for Ethereum. Use of two
independent chains plus class B and C anchors (Section 7.3)
means all must fail simultaneously.
Scenario 5: Anchor Window Denial
Threat: AA disrupts Anchor infrastructure, preventing
publication within the Anchor Window.
Impact: Gap in the anchor sequence for that window.
Mitigation: Redundant Anchor agents. The manifest is still
produced and chained, so the continuity chain does not break.
Late anchoring MUST be flagged in the Scorecard with an
explanation. Anchor receipts obtained outside the window
remain valid evidence of existence-by-time as of the later
anchor, but MUST reduce the Scorecard score for the affected
window, and MUST NOT be represented as timely.
Scenario 6: Silent Control Omission (new in -02)
Threat: OM disables a Collector or removes a Control from
the schedule without a register change, so that no failing
evidence is generated.
Impact: Under -01, the score improves. Every remaining
record verifies.
Mitigation: The Control Register (Section 9.1.2) states in
signed, anchored form what was expected. The Coverage
Attestation reports observed_count 0 with status MISSING.
Section 10.2 multiplies the pillar score by coverage and
applies the 60 cap. Removing a Control legitimately
requires a signed, dated register-change record naming the
authorizing party (Section 9.1.3).
Residual risk: an OM who controls both the Register and the
Coverage Attestor can rewrite expectations going forward.
This is bounded but not eliminated: the register-change
record is itself anchored and chained, so the narrowing is
visible as a dated act by a named party rather than as
silence. Section 8 requirements (8) and (9) raise the
number of principals that must cooperate.
Scenario 7: Whole-Window Deletion (new in -02)
Threat: IA deletes an entire window's records, manifest, and
local anchor receipt.
Impact: Under -01, undetectable from surviving artifacts.
Mitigation: The continuity chain (Section 7.4) makes the
following window's prev_manifest_digest unresolvable and
leaves a gap in seq. Section 7.4.3 invariants (1) through
(3) fail. Because manifests are anchored externally, the
original chain remains provable from third-party anchors
even if every internal copy is destroyed.
Residual risk: deletion of the most recent window, with no
successor yet produced, is detectable only via the external
anchor. This is why class A anchoring of every manifest,
including empty ones, is mandatory.
Scenario 8: Remediation Masking (new in -02)
Threat: An automated Remediator repairs a recurring fault on
every cycle, or a Collector re-runs a Control after
remediation and submits only the passing result.
Impact: A persistent fault is reported as continuous health.
Mitigation: Section 9.8.5 forbids replacing or suppressing
the triggering record and requires worst-result scoring
within a window. Section 9.8.4 requires a circuit breaker
that suspends automated remediation and escalates when the
same condition recurs. RERs are themselves evidence and
appear in the Scorecard at BR2 and above.
Scenario 9: Selective Disclosure Manipulation (new in -02)
Threat: An implementation in commitment mode discloses only
favorable fields, or discloses a field value with a salt
chosen after the fact to produce a desired commitment.
Impact: Misleading but individually verifiable disclosures.
Mitigation: Section 6.4.2 requires "result" and
"register_version" to be committed in every record, so the
outcome cannot be omitted from a disclosure. Salts are
32-octet CSPRNG output that MUST NOT be derived from
content, and the Commitment Root is fixed at record signing
time and anchored, so a later choice of salt cannot produce
a matching commitment without a preimage attack.
Scenario 10: Baseline Poisoning (new in -02)
Threat: An adversary causes an immutable-class target's
baseline to be sealed from an error page, a redirect, or a
response served during a compromise window.
Impact: The false content becomes the reference against
which all future observations are judged, so the real
content later reads as the violation.
Mitigation: Section 7.3.4 requires baselines to be sealed
only on validated, successfully received responses.
Implementations SHOULD seal a baseline only after N
consistent observations from at least two network vantage
points, and MUST record the sealing event as an evidence
record so that the baseline's own provenance is auditable.
13. Security Considerations
13.1. Cryptographic Agility
The signing algorithm and hash function are specified per-record
via the "sig.alg" field and are expected to evolve.
Implementers MUST NOT hard-code algorithm identifiers into
verifier logic. Verifiers MUST support at minimum Ed25519
and ES256.
This specification mandates SHA-256 for evidence and Merkle
tree hashing. Migration to a successor hash is specified in
Section 7.5 and is a first-class protocol operation rather than
a future consideration, because the retention horizons this
protocol targets make migration a certainty rather than a
contingency.
13.2. Replay Attacks
An adversary who obtains a valid signed evidence record for a
PASS result may attempt to replay it for a future window.
The "ts_start" and "ts_end" fields provide temporal scope.
The Aggregator MUST reject records whose "ts_end" falls outside
the current aggregation window. The "record_id" UUID prevents
exact-duplicate submission within the same window, and the
Coverage Attestation counts distinct record digests, so a
replayed record does not increase observed_count.
13.3. Sybil Attacks on Public Key Publication
An adversary may publish a forged public key at a URL designed
to resemble a legitimate Collector's key endpoint.
Implementers MUST publish Collector public keys at URLs under
organizational control with DNSSEC enabled [RFC4033] and
protected with TLS [RFC8446]. Verifiers MUST validate the TLS
certificate of the key endpoint. Implementations SHOULD
additionally publish the JWK Set digest through the continuity
chain, so that a substituted key set is detectable without
reliance on the endpoint's own integrity.
13.4. Privacy
Evidence records MAY contain operationally sensitive data
(e.g., system names, IP addresses, restore durations). They
MUST NOT contain personally identifiable information (PII) or
protected health information (PHI). Artifacts stored in the
Evidence Store that contain sensitive data MUST be encrypted
at rest. Only the artifact's URI and digest appear in the
evidence record; the artifact itself is not on-chain.
Commitment mode (Section 6.4) provides the mechanism by which
individual fields may be disclosed without disclosing the
record. Implementers handling regulated data SHOULD operate in
commitment mode by default.
Implementers MUST consider the tension between permanence and
erasure obligations. Anchoring a digest is not publication of
the underlying content, and deletion of the content leaves the
anchor intact and meaningless, which is the intended behavior:
the record of what was measured can be destroyed while the
record that a measurement occurred survives. Where an erasure
obligation attaches to content committed in an evidence record,
the content MUST be held only in the Evidence Store and MUST be
erasable there without breaking the chain. This property is
treated in more detail in [DRAFT-AIGOV-00].
13.5. Chain Selection
Implementers SHOULD select blockchain networks with established
proof-of-work or finalized proof-of-stake security. Chain
selection criteria SHOULD include: years of continuous
operation, total value secured, and reorganization history.
13.6. Transport Security
All communications between Collectors, Signers, Evidence Stores,
Coverage Attestors, Remediators, and Aggregators MUST use TLS
1.3 [RFC8446]. Certificate validation MUST be enforced;
self-signed certificates are NOT RECOMMENDED in production
deployments.
13.7. Salt Handling (new in -02)
Field salts are the confidentiality boundary of commitment mode.
Compromise of the salt store does not permit forgery, since
commitments are already anchored, but it does permit
confirmation of guessed values for low-entropy fields. Salts
MUST be generated from a CSPRNG, MUST be unique per field per
record, MUST NOT be derived from record content, and MUST be
stored under access control separate from the records. Salt
disclosure in a Selective Disclosure Response reveals only the
disclosed fields, since each field has an independent salt.
13.8. Autonomy Risk (new in -02)
Automated remediation introduces a class of harm that
measurement alone does not. A Remediator with write access to
production is a high-value target: an adversary who controls it
can cause damage under the appearance of routine repair.
Implementations MUST scope Remediator credentials to the
specific actions its Blast Radius Class permits, MUST NOT grant
a Remediator the ability to modify the Control Register, the
Evidence Store retention configuration, or its own Autonomy
Mode, and MUST record every action including refusals.
The prohibition on automating BR3 is a security requirement, not
a conservatism. The signals that trigger BR3 actions, such as
suspected key compromise, are precisely the signals an adversary
can most easily manufacture.
13.9. Trust Assumptions of the Coverage Attestation (new in -02)
The Coverage Attestation shifts, but does not eliminate, the
trust required. It converts "trust that they told you about
every control" into "trust that the Control Register was honest
at the time it was signed, and observe every subsequent change
to it." An implementation that begins with a deliberately
impoverished Register achieves full coverage trivially.
This is a real limit and implementers should not overstate the
guarantee. What the mechanism provides is that the scope of
measurement is public, dated, externally anchored, and
monotonically auditable: a narrowing is a visible act rather
than an absence. Assessing whether a given Register is
adequate to the risk remains a human judgment, and this
protocol does not attempt to automate it.
14. Relationship to Other Protocols in the Suite
RRP is one member of a suite of tamper-evident assurance
protocols sharing a common architectural lineage: canonical
serialization, per-record signing, immutable storage, Merkle
aggregation, hash-linked chaining, and dual-layer anchoring.
They are designed to interoperate and compose while remaining
independently deployable.
REM Protocol [DRAFT-REM-02]:
The Reilly EternaMark Protocol defines dual-layer digital
permanence for arbitrary artifacts via DOI registration and
blockchain timestamping, and in its -02 revision defines the
defensive publication mode under which anchored artifacts
function as prior art records. RRP Aggregate Manifests and
Scorecards SHOULD be archived using REM. The manifest
digest and anchor receipts SHOULD be embedded in the REM
metadata envelope. See Section 16.
Bulk Subtree Proofs [DRAFT-BSP-01]:
Defines a bulk subtree consistency proof that verifies a
contiguous span of a Merkle log by descent over full
subtrees at landmark breakpoints. RRP Verifiers auditing a
multi-year retention period SHOULD use this construction
rather than per-record inclusion proofs; see Section 7.2.3.
CTS (Cognitive Trust Stack) [DRAFT-CTS-01]:
Addresses AI behavioral provenance, bridging alignment
claims and cryptographic proof. CTS-generated behavioral
attestations MAY be incorporated as evidence in the AI
Pipeline Resilience pillar.
CBPI [DRAFT-CBPI-00]:
Cognitive Behavioral Provenance and Integrity for autonomous
AI agents defines Reinforcement Event Records, the Operant
Provenance Chain, the Conditioning Authority, and the
Behavioral Drift Index. The Remediator governance of
Section 9.8 is deliberately compatible: where a Remediator
is an adaptive agent rather than a fixed rule set, its
behavioral drift SHOULD be tracked under CBPI and its
Remediation Event Records MAY be dual-registered as CBPI
Reinforcement Event Records.
AIGOV [DRAFT-AIGOV-00]:
Verifiable AI governance and data privacy records define the
AI System Record, Governance Event Record, Register
Completeness Attestation, and Erasure Record, and introduce
erasure-compatible permanence. The Control Coverage
Attestation of Section 9.5 and the Register Completeness
Attestation of AIGOV are the same construction applied to
different registers, and implementations operating both
SHOULD share a single attestor and a single continuity
chain.
MWS [DRAFT-MWS-01]:
Machine-Web Symbiosis frames the operational relationship
between autonomous agents and web infrastructure within
which an RRP Collector and Remediator operate.
VSR [DRAFT-VSR-00]:
Verifiable Safeguards Records for nuclear material
accountancy applies commitment-based selective disclosure and
century-scale hash migration to a domain with extreme
retention requirements. The field commitment construction of
Section 6.4 and the Migration Bridging Record of Section 7.5
are aligned with VSR so that a single verifier
implementation serves both.
RSP (Reilly Sentinel Protocol):
Focuses on AI model behavioral integrity and inference
attestation. RSP-generated model integrity proofs MAY
be referenced as artifacts in RRP evidence records for the
AI Pipeline Resilience pillar.
RBIP (Reilly Banking Integrity Protocol):
Extends RRP with domain-specific controls for financial
institution resilience, including transaction reconciliation
proofs and regulatory reporting anchoring.
RGIP (Reilly Government Integrity Protocol):
Extends RRP with controls for government IT and public
record integrity, including FISMA alignment and FedRAMP
control mapping.
15. Implementation Guidance
This section provides non-normative guidance for implementers.
15.1. Cloud-Native Reference Architecture
The following reference mapping to cloud primitives is provided:
Evidence Store: Object storage with a compliance-mode
immutability policy, such as S3 Object Lock in COMPLIANCE
mode, Cloud Storage Bucket Lock, or Blob Storage
immutability policies. Governance-mode locks are NOT
RECOMMENDED, since an administrator who can lift the lock
defeats the WORM assumption.
Signer / KMS: A managed KMS with HSM-backed key material.
Salt Store: A secrets manager or separate encrypted store,
with an access policy disjoint from the Evidence Store
reader policy.
Coverage Attestor: A scheduled function in a separate
account, project, or subscription from the Collectors,
with read-only access to the Evidence Store and its own
KMS key. Co-locating the Attestor with the Collectors is
the most common way to build a conformant-looking
implementation that provides none of the assurance.
Anchor (class A): OpenTimestamps calendar client, or a
dedicated transaction submitter for an EVM chain.
Anchor (class B): A DOI registration agency deposit, batched
monthly.
Anchor (class C): Submission of the public manifest URI to
web and source archives.
Aggregator: A scheduled function triggered after the UTC
window boundary, with WORM-write access.
Scorecard Generator: A rendering pipeline producing PDF and
JSON.
15.2. Bootstrapping Sequence
New implementers SHOULD follow this sequence:
(1) Define Controls and SLOs and publish the initial Control
Register per Section 9.1.
(2) Provision KMS keys for each Collector, the Aggregator, and
the Coverage Attestor, observing Section 8 requirement (8).
(3) Publish Collector public keys at well-known URLs.
(4) Deploy Collectors with automated scheduling.
(5) Deploy Evidence Store with WORM and TLS.
(6) Deploy the Coverage Attestor under separation of duties.
(7) Deploy Aggregator with WORM-write access.
(8) Produce the genesis manifest with seq 0 and
prev_manifest_digest of 64 zeros.
(9) Configure Anchor agents across classes A, B, and C.
(10) Produce the first Scorecard and verify end-to-end using
the thirteen-step procedure in Section 9.7.
(11) Run for at least one window with deliberately disabled
Collectors and confirm that the Coverage Attestation
reports them MISSING and that the composite score falls.
An implementation that scores well with a Collector
switched off is misconfigured, and this is the fastest way
to find out.
15.3. Incremental Adoption
Organizations with existing monitoring infrastructure SHOULD
begin by wrapping one or two controls to validate the pipeline
before expanding to the full Control set. The Evidence Schema
is designed to be populated from existing check tool outputs
with minimal transformation.
A small Register operated honestly is more useful than a large
Register operated partially. Implementers SHOULD register only
Controls they intend to run, and SHOULD expand the Register
deliberately rather than aspirationally, since coverage is
measured against what is registered.
15.4. Migrating from -01
Implementations conforming to -01 SHOULD migrate as follows:
(1) Continue anchoring under the -01 construction until the
cutover window. Do not recompute historical roots.
(2) Publish the initial Control Register describing the
Controls already in operation.
(3) Begin producing Coverage Attestations. Expect the first
several windows to show coverage below 1.0; this is
informative, not a defect.
(4) Produce the genesis manifest of the continuity chain with
"legacy_ref" pointing at the last root anchored under -01.
(5) Switch the Merkle construction at the genesis manifest and
record "construction": "rfc6962".
(6) Enable commitment mode and Remediator governance
independently and later; neither is required for a
conformant -02 deployment, whereas the Register, the
Coverage Attestation, the continuity chain, and the
corrected Merkle construction are.
16. Prior Art and Defensive Publication
Artifacts produced under this protocol are anchored using the
dual-layer method of [DRAFT-REM-02]: an external timestamp
establishing existence-by-time and an archival deposit
establishing citable, resolvable persistence. Together these
constitute a public, dated, and independently verifiable
disclosure.
Where an implementer wishes an RRP artifact to serve as a
defensive publication, the artifact and its anchoring metadata
MAY be treated as a Prior Art Record in the sense of
[DRAFT-REM-02] Section 12.1, establishing the disclosure of its
contents as of the anchored date for the purposes of
35 U.S.C. 102(a)(1) [USC-35-102] and equivalent provisions in
other jurisdictions.
Two constraints apply and are stated here because they are
commonly misunderstood:
(1) Anchoring a digest is not disclosure of content. A Prior
Art Record requires that the content itself be publicly
accessible. An anchored manifest digest with the manifest
held privately establishes only that something existed, not
what it was.
(2) The date established is the date of anchoring, and the
assurance is only as strong as the weakest anchor relied
upon. Class C anchors (Section 7.3.3) are corroborative
and SHOULD NOT be relied upon alone for this purpose.
This document is itself published defensively. Nothing in this
section constitutes legal advice, and whether any particular
artifact qualifies as prior art in any particular proceeding is
a question for counsel and the relevant authority.
17. IANA Considerations
This revision makes concrete the registrations that -01
deferred. The author requests that IANA consider the following
when this specification achieves sufficient implementation and
community review.
17.1. Media Type Registrations
Type name: application
Subtype name: rrp-evidence+json
Required parameters: none
Optional parameters: none
Encoding considerations: binary; JSON is UTF-8 encoded
Security considerations: See Section 13 of this document.
Interoperability considerations: See Section 6.3.
Published specification: this document
Applications that use this media type: RRP Collectors,
Evidence Stores, Aggregators, and Verifiers
Fragment identifier considerations: as for application/json
Person and email address to contact for further information:
L.J. Reilly <lawrencejohnreilly@gmail.com>
Intended usage: COMMON
Change controller: IETF
The following additional subtypes are requested under the same
template, differing only in the object they carry:
application/rrp-manifest+json
application/rrp-coverage+json
application/rrp-scorecard+json
17.2. Well-Known URI Registration
URI suffix: rrp
Change controller: IETF
Specification document: this document
Status: permanent
Related information: Implementations publish key material at
/.well-known/rrp/keys.json, the Control Register at
/.well-known/rrp/register.json, and the continuity chain head
at /.well-known/rrp/chain-head.json.
A single suffix with a defined internal layout is requested in
preference to the three separate suffixes contemplated by -01,
which would have consumed registry space unnecessarily.
17.3. Structured Syntax Suffix
No new structured syntax suffix is requested. Revision -01
contemplated a "+rrp" suffix; on review this is unnecessary,
since RRP documents are JSON and CBOR documents and the existing
"+json" and "+cbor" suffixes are sufficient.
18. References
18.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>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D.,
and S. Rose, "DNS Security Introduction and
Requirements", RFC 4033, DOI 10.17487/RFC4033,
March 2005, <https://www.rfc-editor.org/info/rfc4033>.
[RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed.,
"JavaScript Object Notation (JSON) Pointer",
RFC 6901, DOI 10.17487/RFC6901, April 2013,
<https://www.rfc-editor.org/info/rfc6901>.
[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>.
[RFC6979] Pornin, T., "Deterministic Usage of the Digital
Signature Algorithm (DSA) and Elliptic Curve Digital
Signature Algorithm (ECDSA)", RFC 6979,
DOI 10.17487/RFC6979, August 2013,
<https://www.rfc-editor.org/info/rfc6979>.
[RFC7493] Bray, T., Ed., "The I-JSON Message Format",
RFC 7493, DOI 10.17487/RFC7493, March 2015,
<https://www.rfc-editor.org/info/rfc7493>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/info/rfc7517>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve
Digital Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, 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,
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>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS)
Protocol Version 1.3", RFC 8446,
DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[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>.
[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>.
[RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally
Unique IDentifiers (UUIDs)", RFC 9562,
DOI 10.17487/RFC9562, May 2024,
<https://www.rfc-editor.org/info/rfc9562>.
[FIPS180-4]
National Institute of Standards and Technology,
"Secure Hash Standard (SHS)", FIPS PUB 180-4,
DOI 10.6028/NIST.FIPS.180-4, August 2015.
18.2. Informative References
[RFC7089] Van de Sompel, H., Nelson, M., and R. Sanderson,
"HTTP Framework for Time-Based Access to Resource
States -- Memento", RFC 7089,
DOI 10.17487/RFC7089, December 2013,
<https://www.rfc-editor.org/info/rfc7089>.
[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>.
[FIPS204] National Institute of Standards and Technology,
"Module-Lattice-Based Digital Signature Standard",
FIPS PUB 204, DOI 10.6028/NIST.FIPS.204,
August 2024.
[I-D.SCITT-ARCH]
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/>.
[DRAFT-REM-02]
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, <https://datatracker.ietf.org/doc/
draft-reilly-rem-protocol/>.
[DRAFT-RRP-00]
Reilly, L.J., "Reilly Resilience Protocol (RRP):
Tamper-Evident Proof of System Resilience",
Work in Progress, Internet-Draft,
draft-reilly-resilience-protocol-00,
September 2025,
<https://datatracker.ietf.org/doc/
draft-reilly-resilience-protocol/00/>.
[DRAFT-RRP-01]
Reilly, L.J., "Reilly Resilience Protocol (RRP):
Tamper-Evident Proof of System Resilience",
Work in Progress, Internet-Draft,
draft-reilly-resilience-protocol-01,
March 2026,
<https://datatracker.ietf.org/doc/
draft-reilly-resilience-protocol/01/>.
[DRAFT-CTS-01]
Reilly, L.J., "Cognitive Trust Stack (CTS):
Cryptographic Behavioral Provenance for AI Systems",
Work in Progress, Internet-Draft,
draft-reilly-cts-01, 2026,
<https://datatracker.ietf.org/doc/
draft-reilly-cts/>.
[DRAFT-CBPI-00]
Reilly, L.J., "Cognitive Behavioral Provenance and
Integrity (CBPI) for Autonomous AI Agents",
Work in Progress, Internet-Draft,
draft-reilly-cbpi-00, 2026,
<https://datatracker.ietf.org/doc/
draft-reilly-cbpi/>.
[DRAFT-AIGOV-00]
Reilly, L.J., "Verifiable AI Governance and Data
Privacy Records", Work in Progress, Internet-Draft,
draft-reilly-aigov-00, 2026,
<https://datatracker.ietf.org/doc/
draft-reilly-aigov/>.
[DRAFT-MWS-01]
Reilly, L.J., "Machine-Web Symbiosis (MWS)",
Work in Progress, Internet-Draft,
draft-reilly-mws-01, 2026,
<https://datatracker.ietf.org/doc/
draft-reilly-mws/>.
[DRAFT-VSR-00]
Reilly, L.J., "Verifiable Safeguards Records (VSR)
for Nuclear Material Accountancy", Work in Progress,
Internet-Draft, draft-reilly-vsr-00, 2026,
<https://datatracker.ietf.org/doc/
draft-reilly-vsr/>.
[DRAFT-BSP-01]
Reilly, L.J., "Bulk Subtree Consistency Proofs for
Merkle Tree Certificates", Work in Progress,
Internet-Draft,
draft-reilly-plants-bulk-subtree-proofs-01, 2026,
<https://datatracker.ietf.org/doc/
draft-reilly-plants-bulk-subtree-proofs/>.
[RRP-WHITEPAPER-V2]
Reilly, L.J., "The Reilly Resilience Protocol (RRP):
A Tamper-Evident, Blockchain-Anchored Framework for
Proving IT, Cloud, and AI System Resilience",
Zenodo, DOI: 10.5281/zenodo.17100703,
September 11, 2025,
<https://zenodo.org/records/17100703>.
NOTE: This whitepaper was blockchain timestamped and
DOI archived on September 11, 2025, at the time of
its upload to Zenodo.
[NIST-800-53]
National Institute of Standards and Technology,
"Security and Privacy Controls for Information
Systems and Organizations", NIST Special Publication
800-53 Rev 5, September 2020,
<https://doi.org/10.6028/NIST.SP.800-53r5>.
[NIST-AI-RMF]
National Institute of Standards and Technology,
"Artificial Intelligence Risk Management Framework
(AI RMF 1.0)", NIST AI 100-1, January 2023,
<https://doi.org/10.6028/NIST.AI.100-1>.
[OPENTIMESTAMPS]
Todd, P., "OpenTimestamps: Scalable, Trust-Minimized,
Distributed Timestamping with Bitcoin",
<https://opentimestamps.org/>.
[USC-35-102]
United States Code, "Conditions for patentability;
novelty", 35 U.S.C. 102.
[EU-DORA] European Union, "Regulation (EU) 2022/2554 on
digital operational resilience for the financial
sector", December 2022.
[EU-NIS2] European Union, "Directive (EU) 2022/2555 on
measures for a high common level of cybersecurity
across the Union", December 2022.
[EU-AI-ACT]
European Union, "Regulation (EU) 2024/1689 laying
down harmonised rules on artificial intelligence",
June 2024.
Appendix A. Changes from -01
The following substantive changes were made from
draft-reilly-resilience-protocol-01 to this revision (-02).
A.1. Merkle Tree Construction Corrected (Section 7.2)
Revision -01 duplicated the final digest when the leaf count was
odd and attributed that construction to [RFC9162]. The
attribution was incorrect: [RFC6962] and [RFC9162] promote the
odd node rather than duplicating it. Duplication permits
distinct leaf multisets to produce identical roots and prevents
consistency proofs. Section 7.2 now specifies the [RFC6962]
construction in full, including the empty-tree and single-leaf
cases, with test vectors and an explicit statement of the
non-conformant -01 computation.
A.2. Leaf Ordering Changed (Section 7.2.1)
Ordering by digest, as in -01, is replaced by ordering by
(ts_end, record_id). Digest ordering destroyed temporal
sequence and made concatenation of windows non-monotone, which
is why -01 could not support consistency proofs.
A.3. Control Register Introduced (Section 9.1.2, 9.1.3)
A signed, versioned, published register of the Controls an
implementation asserts it operates. Changes to the register are
themselves evidence records requiring a named authorizing party.
A.4. Control Coverage Attestation Introduced (Section 9.5)
The principal addition of this revision. A signed per-window
statement enumerating every registered Control with expected and
observed record counts, produced by a principal with a key
distinct from the Collectors, committed by the Aggregate
Manifest, and therefore anchored. This converts the absence of
evidence into a verifiable claim and closes the Omission
Adversary gap described in Sections 1.1 and 12.1.
A.5. Evidence Continuity Chain Introduced (Section 7.4)
Aggregate Manifests are hash-linked by sequence number and
predecessor digest, with mandatory window adjacency, so that
deletion or reordering of a window is detectable. Empty Window
Records replace the -01 behavior of producing no anchor when a
window was empty, under which silence and suppression were
indistinguishable.
A.6. Anchoring Restructured (Section 7.3)
The anchored value is now the Aggregate Manifest digest rather
than the bare Merkle root, so that anchoring transitively covers
the coverage attestation and the prior chain. Anchors are
organized into three classes: blockchain, persistent identifier,
and keyless archival. Anchor Expectations for measured external
targets (live, dynamic, immutable) are defined, with immutable
violations forced to human review.
A.7. Field Commitments and Selective Disclosure (Section 6.4)
Salted per-field commitments with a Commitment Root, and a
Selective Disclosure Response format, allowing an individual
field to be proven against an anchored root without disclosing
the record. Addresses the privacy posture of -01 Section 13.4,
which stated requirements but supplied no mechanism.
A.8. Autonomous Remediation Governance (Section 9.8)
New Remediator role with Blast Radius Classes BR0 through BR3,
Autonomy Modes OBSERVE, SUPERVISED, and AUTONOMOUS, a mandatory
circuit breaker, Remediation Event Records, and a prohibition on
remediation altering the result of the triggering record. BR3
actions are never automated.
A.9. Hash and Signature Migration (Section 7.5)
Migration Bridging Records permit a chain segment computed under
a retiring algorithm to be bound to its recomputation under a
successor, without rewriting history. Required because the
protocol's retention horizons exceed the confident lifetime of
any specific algorithm.
A.10. Scoring Corrections (Section 10)
Weight renormalization is defined for Pillars with no registered
Controls, an undefined case in -01 that silently deflated the
composite. A coverage factor multiplies each pillar score, and
incomplete coverage triggers the same cap as an outright
failure, so that disabling a failing Control now lowers the
score rather than raising it. Within a window, a Control is
scored on its worst observed result rather than its most recent.
Band assignment gains asymmetric hysteresis: downward transitions
are immediate, upward transitions require two consecutive
windows.
A.11. Scorecard Requirements Expanded (Section 9.6)
Coverage ratio, missing Controls, chain position, effective
weights, and BR2-and-above remediations are now mandatory
content. A Scorecard reporting a composite score without
coverage is non-conformant.
A.12. Verification Procedure Extended (Section 9.7)
The nine-step procedure of -01 becomes thirteen steps, adding
register and coverage verification, continuity chain walking,
and migration bridging where applicable.
A.13. Key Management Extended (Section 8)
Three new requirements: distinct keys for Aggregator, Coverage
Attestor, and Collectors; separation of duties between Aggregator
and Coverage Attestor with mandatory disclosure where
unachievable; and continuity of the chain across key revocation.
A.14. Threat Model Extended (Section 12)
New Omission Adversary class. New scenarios 6 through 10:
silent control omission, whole-window deletion, remediation
masking, selective disclosure manipulation, and baseline
poisoning. Residual risks are stated explicitly rather than
implied.
A.15. Security Considerations Extended (Section 13)
New subsections on salt handling, autonomy risk, and the trust
assumptions of the Coverage Attestation, the last of which
states plainly what the new mechanism does not guarantee.
A.16. Compliance Mapping Extended (Section 11)
Added ISO/IEC 42001, NIST AI RMF, NIS2, EU AI Act, SEC
cybersecurity disclosure rules, and additional NIST 800-53
controls (CP-4, AU-9, AU-10). Corrected the DORA article
mapping, which in -01 cited Article 11 as backup policies; in
Regulation (EU) 2022/2554, backup and restoration are addressed
in Article 12 and response and recovery in Article 11.
A.17. Suite Relationships Updated (Section 14)
Updated to reference the current suite, including bulk subtree
proofs for efficient long-range verification, CBPI for adaptive
remediators, AIGOV for the shared attestation construction, VSR
for aligned commitment and migration mechanisms, and MWS.
A.18. Prior Art Section Added (Section 16)
Documents the treatment of RRP artifacts as prior art records
under 35 U.S.C. 102(a)(1), consistent with [DRAFT-REM-02], with
explicit statement of the two constraints most commonly
misunderstood.
A.19. IANA Considerations Made Concrete (Section 17)
Full media type registration templates for four subtypes, a
single /.well-known/rrp suffix with defined internal layout in
place of the three suffixes contemplated by -01, and withdrawal
of the proposed "+rrp" structured syntax suffix as unnecessary.
A.20. Schema and Reference Updates
"rrp_version" advanced to "1.2". New optional fields
"record_type", "register_version", "anchor_expectation",
"remediation_ref", and "commitments". UUID reference updated
from RFC 4122 to RFC 9562; timestamp handling now cites
RFC 3339 explicitly; I-JSON (RFC 7493) added for number
handling; RFC 6901 added for JSON Pointer; RFC 6962 promoted to
normative; RFC 7089 and RFC 7942 added; FIPS 180-4 and FIPS 204
added. RFC 5652 and RFC 7519, cited in -01 but unused in the
body, are removed.
A.21. Implementation Status Added (Section 1.2)
An [RFC7942] implementation status section describing the
reference deployments from which the hysteresis, circuit
breaker, and anchor expectation mechanisms were derived.
Appendix B. Worked Continuity Verification Example
This appendix is informative. It illustrates detection of a
deleted window.
An auditor is given manifests for seq 100 through 106 and asked
to confirm continuous operation for that period.
Step 1. The auditor confirms seq values 100, 101, 102, 104,
105, 106. Invariant (1) of Section 7.4.3 fails: 103 is absent.
Step 2. The auditor computes the digest of manifest 102 and
compares it to manifest 104's prev_manifest_digest. They do not
match, because manifest 104 committed to manifest 103. The
organization's explanation that "nothing happened that day"
is inconsistent with the artifacts it has itself published,
since an empty window would have produced manifest 103 with
merkle_root = MTH({}) rather than no manifest at all.
Step 3. The auditor checks window adjacency. Manifest 102 ends
at 2026-08-12T00:00:00Z and manifest 104 begins at
2026-08-14T00:00:00Z. Invariant (3) fails; twenty-four hours
are unaccounted for.
Step 4. The auditor queries the class A anchor for the period.
If the organization anchored manifest 103 before deleting it,
the on-chain commitment persists and the auditor recovers the
digest of the deleted manifest, though not its contents. The
organization can be asked to produce a manifest matching that
digest, and cannot.
Step 5. The auditor queries class C archival anchors. Where a
third-party archive captured the manifest URI, the contents of
the deleted window may be recoverable in full.
Step 6. The auditor examines the Coverage Attestations for
windows 102 and 104. If Control coverage drops sharply in 104
relative to 102, the deletion likely coincided with an
operational failure rather than a routine gap.
Under -01, steps 1 through 6 were unavailable. The auditor
would have been given six authentic manifests, would have
verified all six successfully, and would have had no basis on
which to ask about the seventh.
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
Zenodo Archive:
https://zenodo.org/records/17100703
DOI: 10.5281/zenodo.17100703