Network Working Group                                       L.J. Reilly
Internet-Draft                                               Independent
Intended status: Informational                        September 27, 2025
Expires: March 31, 2026


          Reilly Resilience Protocol (RRP): Tamper-Evident Proof
                        of System Resilience
                 draft-reilly-resilience-protocol-00

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 turns resilience claims
   into cryptographically signed evidence persisted in immutable storage
   and batched into a daily Merkle root that is publicly time-anchored
   on blockchains. The protocol outputs an executive Resilience
   Scorecard backed by independently verifiable receipts. RRP composes
   with the Reilly EternaMark (REM) protocol to ensure dual-layer digital
   permanence using both DOI archival and blockchain timestamping.

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

Copyright Notice

   Copyright (c) 2025 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.

1.  Introduction

   Organizations often claim "high availability," "recoverability," and
   "compliance," but outages, failed restores, configuration drift, and
   silent AI degradation continue to occur. Traditional logs and
   dashboards can be edited, omitted, or lack objective time validity.

   RRP closes this trust gap by producing daily, tamper-evident proof
   that critical controls executed successfully. Evidence MUST be
   signed, persisted in immutable storage, and anchored into a public
   blockchain Merkle root for time attestation. The protocol defines a
   Resilience Scorecard that SHOULD be consumable by executives, while
   remaining fully verifiable by auditors.

2.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 and RFC 8174
   when, and only when, they appear in all capitals, as shown here.

3.  Protocol Principles

   * Test restores, not backups.  Recovery MUST be demonstrated by an
     actual restore + validation.

   * Evidence over narrative.  Every resilience claim MUST map to
     signed, immutable evidence.

   * Minimum on-chain.  Only Merkle roots MUST be anchored. Sensitive
     artifacts MUST remain off-chain.

   * Composable.  Existing monitoring and testing systems SHOULD be
     wrapped to produce standardized evidence records.

4.  Architecture

   RRP consists of the following roles:

   * Collectors: MUST generate normalized evidence JSON/CBOR for each
     control check.

   * Signer: MUST sign evidence digests with a private key (Ed25519 or
     ECDSA P-256) stored in a KMS/HSM.

   * Evidence Store: MUST preserve full JSON and supporting artifacts in
     WORM/immutable storage.

   * Aggregator: MUST validate signatures, construct a Merkle tree, and
     compute the root daily.

   * Anchor: MUST publish the Merkle root to a public blockchain
     (Bitcoin/OpenTimestamps or Ethereum/L2).

   * Scorecard: SHOULD compute weighted pillar scores and present a PDF
     or dashboard for executives.

5.  Operations

   Step 1: Define Controls and SLOs
      Implementers MUST define 5-12 critical controls with measurable
      SLOs (e.g., Restore <= 30 min).

   Step 2: Collect Evidence
      Collectors MUST execute active checks (e.g., DB restore, TLS
      expiry, AI drift scan) and emit canonical evidence.

   Step 3: Sign Evidence
      Each evidence JSON MUST be hashed (SHA-256) and signed using a per-
      collector key.

   Step 4: Store Evidence
      Evidence and artifacts MUST be stored in immutable object storage
      with retention and versioning.

   Step 5: Aggregate and Anchor
      Aggregators MUST compute the Merkle root over all results once per
      day and MUST anchor it into a public chain.

   Step 6: Publish Scorecard
      Scorecard SHOULD provide a 0-100 RRP score. Stale evidence MUST
      decay the score. Critical FAILS MUST cap a pillar at 60.

   Step 7: Independent Verification
      Auditors MUST be able to re-derive digests, validate collector
      signatures, verify Merkle inclusion proofs, and validate anchor
      receipts without vendor trust.

6.  Security Considerations

   * Multiple chains SHOULD be used to mitigate correlated blockchain
     risk.

   * Keys MUST be rotated periodically (at least annually).

   * Verifiers MUST treat all evidence inputs as untrusted until hashes,
     signatures, and inclusion proofs are validated.

7.  Relationship to REM

   RRP specifies how to generate daily, verifiable resilience
   evidence. The REM protocol specifies how to preserve that evidence
   permanently via DOI archival + blockchain timestamping. RRP evidence
   packages SHOULD integrate with REM by publishing batch metadata as
   DOI-archived objects, embedding Merkle roots and anchor receipts.

8.  IANA Considerations

   This document has no IANA actions.

9.  References

9.1.  Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119
             Key Words", BCP 14, RFC 8174, May 2017.

   [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
             RFC 8152, July 2017.

   [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)",
             RFC 5652, September 2009.

   [RFC9162] Laurie, B., et al., "Merkle Tree Proofs", RFC 9162,
             December 2021.

   [RFC8259] Bray, T., "The JavaScript Object Notation (JSON) Data
             Interchange Format", RFC 8259, December 2017.

   [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
             Representation (CBOR)", RFC 8949, December 2020.

9.2.  Informative References

   Reilly, L.J., "Reilly EternaMark (REM) Protocol - Dual-Layer Digital
   Permanence Using DOI Archiving and Blockchain Timestamping", Work in
   Progress, draft-reilly-rem-protocol-00, September 2025.

   Reilly, L.J., "The Reilly Resilience Protocol (RRP) Whitepaper v2",
   Zenodo, DOI: 10.5281/zenodo.17100703, September 2025.

Author's Address

   Lawrence John Reilly Jr.
   Independent Researcher
   Email: lawrencejohnreilly@gmail.com
