Network Working Group                                         L.J. Reilly
Internet-Draft                                       Independent Submission
Intended status: Informational                                 26 September 2025
Expires: 30 March 2026


   Reilly Sentinel Protocol (RSP): Blockchain-Anchored Integrity for AI
      Datasets, Training, Fine-Tuning, and Inference Provenance
                  draft-reilly-sentinel-protocol-00


Abstract

   The Reilly Sentinel Protocol (RSP) specifies an interoperable,
   dual-layer method for establishing integrity, provenance, and
   auditability across the artificial intelligence (AI) lifecycle.
   RSP defines a Sentinel Evidence Package (SEP) that binds payload
   digests, provenance metadata, signatures, blockchain timestamp
   proofs, and resolvable identifiers (DOIs).  This enables
   tamper-evident, independently verifiable receipts for datasets,
   data transformations, training jobs, checkpoints, fine-tuning
   runs, evaluations, and inference outputs.

   RSP is transport-agnostic and serializable in JSON and CBOR.  It
   leverages existing IETF and industry building blocks, including
   COSE/CMS signatures, CBOR (RFC 8949), CDDL (RFC 8610), JSON
   (RFC 8259), and NTS-secured time (RFC 8915).  Anchoring is done
   via append-only blockchain receipts (e.g., OpenTimestamps-style
   proofs) and identity/lineage is stabilized with a DOI registry.
   The result is an evidence-grade audit trail for regulated and
   safety-critical AI deployments.


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 30 March 2026.


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.


Table of Contents

   1.  Introduction
   2.  Conventions and Terminology
   3.  Architecture and Roles
   4.  Sentinel Evidence Package (SEP) Data Model
   5.  Serialization and Media Types
   6.  Anchoring and Proofs
   7.  DOI Registration and Metadata
   8.  Protocol Operations
   9.  Verification Algorithm
   10. Error Handling
   11. Manageability and Telemetry
   12. Privacy Considerations
   13. Security Considerations
   14. IANA Considerations
   15. Implementation Status
   16. References
       16.1. Normative References
       16.2. Informative References
   Appendix A.  CDDL for CBOR SEP
   Appendix B.  Example JSON SEP
   Appendix C.  Verification Report (JSON)
   Appendix D.  Example OpenTimestamps Receipt
   Appendix E.  Example DOI Metadata Mapping
   Acknowledgments
   Author's Address


1.  Introduction

   Artificial Intelligence (AI) systems are increasingly used in
   high-stakes contexts (defense, healthcare, finance, critical
   infrastructure).  Confidence in AI outcomes depends on the ability
   to show where data came from, how models were trained or adapted,
   when inferences were produced, and whether any of these artifacts
   have been altered.

   RSP addresses these needs by defining a minimal yet extensible
   evidence container -- the Sentinel Evidence Package (SEP) -- and a
   verification process that any independent party can execute without
   trusting the producer's infrastructure.  RSP is content- and model-
   agnostic: it does not dictate the model architecture or task; it
   only standardizes how integrity, time, identity, and lineage are
   recorded and verified.

   RSP combines two complementary layers of permanence:

   *  Blockchain anchoring:  an append-only proof of existence by a
      given time for payload digests and roll-up digests.

   *  DOI registration:  globally resolvable, citable identifiers with
      metadata, lineage, and retention semantics.

   This dual anchoring makes later manipulations detectable and enables
   reliable long-term discovery and citation.


2.  Conventions and Terminology

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

   SEP:  Sentinel Evidence Package; the container defined by this
      document.

   Artifact:  Any AI lifecycle asset -- dataset, data transform,
      training configuration, training log, model checkpoint, fine-
      tuning diff, evaluation artifact, or inference record.

   Digest:  A cryptographic hash (e.g., SHA-256) of a payload or
      Merkle root over chunked payloads.

   OTS:  OpenTimestamps-style proof object or functionally equivalent
      blockchain timestamp receipt.

   DOI:  Digital Object Identifier; a resolvable identifier (via
      DataCite/Crossref or internal Handle) providing metadata and
      lineage stability.

   COSE:  CBOR Object Signing and Encryption; RSP uses COSE signatures
      (RFC 9052, RFC 9053).

   CMS:  Cryptographic Message Syntax (RFC 5652).


3.  Architecture and Roles

   Producer:  Creates artifacts, computes digests, collects device/
      environment attestations, signs SEPs, and requests anchoring and
      DOI registration.

   Registrar:  Provides two sub-services: (a) Anchoring Orchestrator
      that submits digests to public chains and returns proofs; (b) DOI
      Registrar that mints DOIs and stores metadata, lineage, and
      fixity.

   Verifier:  Recomputes digests, validates signatures, checks OTS
      receipts against independent nodes, and resolves DOI metadata and
      lineage without trusting Producer or Registrar beyond their
      signatures.

   Storage:  WORM (Write-Once-Read-Many) or equivalent immutable object
      storage for SEPs, proofs, and payloads under retention policy.

   Time:  Authenticated time sources (NTS, RFC 8915) and monotonic
      counters to resist back-dating and rollback.

   RSP does not mandate a specific trust relation among these roles; in
   many deployments, Producer and Registrar are separate entities.


4.  Sentinel Evidence Package (SEP) Data Model

   An SEP is a self-describing manifest that binds digest(s), metadata,
   signatures, proofs, and identifiers.  The canonical fields are:

   *  version:  Protocol version string (e.g., "1.0").

   *  artifact.type:  "dataset", "datatransform", "training.config",
      "training.log", "training.checkpoint", "fine-tune.diff",
      "evaluation", "inference", or an extension token.

   *  payloads[]:  Optional array with entries { cid, size, mime,
      chunking }; payload storage MAY be external.  'cid' MUST encode
      algorithm and value (e.g., "sha256:HEX").

   *  digests:  Object with at least sha256 and sha3_256 members
      (hex-encoded).  For chunked payloads, digests.root is the Merkle
      root, and digests.leaves MAY be omitted.

   *  timestamps:  wallclock (RFC 3339) and monotonic counter.  The
      'source' SHOULD indicate NTS, Roughtime, or equivalent.

   *  authors[]:  Optional list of creators/operators; MAY include
      device IDs and certificate references.

   *  attestation:  Optional device/firmware/build attestation claims
      (out of scope to specify here; see RATS, RFC 9334).

   *  rem:  Anchoring and identity sub-object:
        - rem.ots_proof_ref: URN or locator to proof file.
        - rem.doi: DOI string.
        - rem.lineage: parent[], siblings[], supersedes[].

   *  class:  Optional classification/handling indicators (tokenized).

   *  policies:  Retention and access policy references.

   *  signatures[]:  One or more COSE_Sign1 or CMS signatures covering
      the manifest canonical form.  Certificate chains MUST be
      included.

   The manifest MUST be canonicalized prior to signing; canonical JSON
   (JCS, RFC 8785) or deterministic CBOR (RFC 8949 Section 4.2) MAY be
   used.


5.  Serialization and Media Types

   RSP SEPs MAY be emitted as JSON (RFC 8259) or CBOR (RFC 8949).
   This document defines two media types for IANA registration:

   *  application/rsp-ep+json
   *  application/rsp-ep+cbor

   The "+" structured suffix follows RFC 6839.  See Section 14 for
   IANA templates.


6.  Anchoring and Proofs

   Producers submit digests (payload or roll-up Merkle roots) to the
   Anchoring Orchestrator.  The orchestrator MUST anchor to at least
   one public append-only chain and SHOULD support multiple chains for
   diversity.  Proofs MUST be exportable and independently checkable.

   OpenTimestamps receipts are RECOMMENDED where applicable.  When
   using other schemes, a proof MUST include sufficient data for
   independent verification (e.g., chain identifier, transaction
   locator, inclusion path).

   Roll-up anchoring:  Operators SHOULD periodically compute a Merkle
   tree over all new artifact digests and anchor the root to reduce
   per-artifact anchoring cost and to provide compact audit coverage.


7.  DOI Registration and Metadata

   After anchoring, the Registrar mints a DOI and stores a metadata
   record containing at least: title or short label, creators,
   creation time, fixity (digests), lineage links, and policy URIs.
   DOIs for classified material MAY be internal Handles resolvable on
   private networks; unclassified artifacts MAY use public DOIs
   (e.g., DataCite).

   A DOI SHOULD be minted for each material evolution that changes
   fixity (e.g., new dataset version, fine-tune result, evaluation
   report).  Prior DOIs MUST NOT be deleted; instead, metadata MAY
   indicate "superseded-by".


8.  Protocol Operations

   The following abstract operations are defined; concrete APIs are out
   of scope, but typical deployments use REST or gRPC.

   8.1  SEAL

      Inputs:  manifest draft (unsigned), digests, optional attestation.
      Action:  Canonicalize, sign (COSE/CMS), return SEP (unsigned ->
               signed).

   8.2  ANCHOR

      Inputs:  digest(s) (payload or roll-up).  Action: Anchor to one
               or more chains; return proof reference(s).

   8.3  REGISTER

      Inputs:  metadata (including fixity, lineage).  Action: Mint DOI,
               bind DOI <-> SEP <-> proofs; return DOI.

   8.4  VERIFY

      Inputs:  DOI or SEP URI (plus payload, if accessible).  Action:
               Recompute digests; validate signatures; check time
               discipline; verify proofs; emit Verification Report.


9.  Verification Algorithm

   Given a DOI or SEP:

   1.  Resolve DOI (if provided) to retrieve minimal metadata including
       fixity, lineage, and pointers to SEP and payload (subject to
       policy).

   2.  Fetch SEP.  Parse and canonicalize the manifest according to its
       serialization; verify that the 'digests' field matches the
       payload (if accessible).

   3.  Validate signatures (COSE/CMS).  Check certificate validity and
       revocation (OCSP/CRL).  Attestation claims MAY be evaluated via
       a verifier (cf. RATS, RFC 9334).

   4.  Validate time: ensure wallclock is plausible (NTS/secure time)
       and monotonic counter continuity holds relative to adjacent
       SEPs.

   5.  Validate anchoring proofs independently using public chain data.

   6.  Emit a Verification Report with fields: hash_ok, sig_ok,
       attestation_ok, ots_ok, time_ok, doi_ok, and overall verdict.
       The report SHOULD itself be signed.


10.  Error Handling

   RSP defines abstract error conditions with suggested codes/strings:

     ERR_PARSE          - malformed SEP or encoding
     ERR_DIGEST_MISMATCH- recomputed digest != manifest
     ERR_SIG_INVALID    - signature or chain invalid
     ERR_TIME_INVALID   - unauthenticated or non-monotonic time
     ERR_PROOF_INVALID  - proof not verifiable on stated chain
     ERR_DOI_RESOLVE    - DOI metadata unavailable/inconsistent
     ERR_POLICY_DENIED  - access denied by policy

   Implementations SHOULD map these to transport-specific error
   responses.


11.  Manageability and Telemetry

   Deployments SHOULD monitor:
     - Anchoring SLA (time to first chain inclusion).
     - Coverage (% artifacts with valid SEPs and DOIs).
     - Verification pass rate and dominant failure reasons.
     - Key health (expiration, revocation events).
     - Time-source health (NTS/stratum, Roughtime reachability).

   Daily or mission-rollup Merkle roots SHOULD be recorded and
   anchored, enabling compact audits.


12.  Privacy Considerations

   SEPs record integrity metadata; payloads MAY be withheld.  Where
   privacy is required, field-level encryption SHOULD be used for
   sensitive manifest attributes while keeping digests and proofs
   public.  DOI records for sensitive artifacts SHOULD minimize
   personally identifiable information.  Policy URIs SHOULD reflect
   access constraints.


13.  Security Considerations

   Key compromise:  Private keys used for COSE/CMS MUST be protected in
   HSMs or equivalent.  Short-lived device certificates and revocation
   (OCSP/CRL) are RECOMMENDED.  Compromised keys MUST NOT trigger data
   deletion; instead, append revocation facts and supersede with new
   signatures.

   Time attacks:  Producers MUST use authenticated time (NTS) and
   monotonic counters.  Multiple time sources are RECOMMENDED.  Large
   backward jumps MUST be flagged.

   Proof stability:  Anchoring to multiple independent chains
   (heterogeneous consensus) reduces correlation risk.  Re-anchoring of
   historical Merkle roots over time is RECOMMENDED for longevity.

   Replay/substitution:  Bind signatures to digests and policy context;
   DOIs provide stable identity to detect swaps.

   Supply chain:  Model and dataset supply chain attestations (e.g.,
   SBOM-like metadata, RATS evidence) are RECOMMENDED but out of scope
   to normatively specify here.

   Security considerations follow RFC 3552 guidance.


14.  IANA Considerations

   IANA is requested to register the following media types:

   14.1  application/rsp-ep+json

     Type name:           application
     Subtype name:        rsp-ep+json
     Required parameters: none
     Optional parameters: charset (per RFC 6838)
     Encoding considerations:  binary; JSON (RFC 8259)
     Security considerations:  see Section 13
     Interoperability considerations:  none
     Published specification:  this document
     Applications that use this media type:  AI provenance systems
     Fragment identifier considerations:  per RFC 7303
     Additional information:
       Magic number(s):  n/a
       File extension(s):  .rsp.json
       Macintosh file type code(s):  n/a
     Person & email address to contact for further information:
       Lawrence John Reilly Jr. <lawrencejohnreilly@gmail.com>
     Intended usage:  COMMON
     Restrictions on usage:  none
     Author:  IETF
     Change controller:  IESG

   14.2  application/rsp-ep+cbor

     Type name:           application
     Subtype name:        rsp-ep+cbor
     Required parameters: none
     Optional parameters: none
     Encoding considerations:  binary; CBOR (RFC 8949)
     Security considerations:  see Section 13
     Interoperability considerations:  none
     Published specification:  this document
     Applications that use this media type:  AI provenance systems
     Fragment identifier considerations:  none
     Additional information:
       Magic number(s):  n/a
       File extension(s):  .rsp.cbor
       Macintosh file type code(s):  n/a
     Person & email address to contact for further information:
       Lawrence John Reilly Jr. <lawrencejohnreilly@gmail.com>
     Intended usage:  COMMON
     Restrictions on usage:  none
     Author:  IETF
     Change controller:  IESG


15.  Implementation Status

   A background report describing RSP's intent and design is archived at
   Zenodo (doi:10.5281/zenodo.17103522).  Reference implementations for
   SEP creation, anchoring integration, and verification are planned for
   public release.

16.  References

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

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

   [RFC8610]  Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
              Definition Language (CDDL): A Notational Convention to
              Express CBOR and JSON Data Structures", RFC 8610, June 2019.

   [RFC8785]  rfc-editor.org, "JSON Canonicalization Scheme (JCS)",
              RFC 8785, June 2020.

   [RFC8915]  Franke, D., "Network Time Security for the Network Time
              Protocol", RFC 8915, September 2020.

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

   [RFC9052]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Structures and Process", RFC 9052, August 2022.

   [RFC9053]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Algorithms", RFC 9053, August 2022.

   [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
              Timestamps", RFC 3339, July 2002.

16.2.  Informative References

   [RSP]      Reilly, L. J., "Reilly Sentinel Protocol", Zenodo,
              doi:10.5281/zenodo.17103522.

   [REM]      Reilly, L. J., "Reilly EternaMark (REM) Protocol",
              Zenodo, doi:10.5281/zenodo.17129012.

   [RATS]     Birkholz, H., et al., "Remote Attestation Procedures
              Architecture", RFC 9334, November 2022.

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

   [SCITT]    IETF, "Supply Chain Integrity, Transparency, and Trust
              (SCITT) Working Group Charter", IETF Datatracker.

   [C2PA]     Coalition for Content Provenance and Authenticity, "C2PA
              Specification", 2023.

   [OTS]      OpenTimestamps community, "OpenTimestamps: Scalable
              Timestamping", online documentation.

   [DATACITE] DataCite Metadata Schema 4.x, DataCite.


Appendix A.  CDDL for CBOR SEP

   sep = {
     version: tstr,
     artifact: {
       type: tstr
     },
     ? payloads: [* payload],
     digests: {
       sha256: tstr,        ; lowercase hex
       sha3_256: tstr,
       ? root: tstr
     },
     timestamps: {
       wallclock: tstr,     ; RFC3339
       ? monotonic: uint,
       ? source: tstr
     },
     ? authors: [* { name: tstr, ? id: tstr }],
     ? attestation: any,
     rem: {
       ots_proof_ref: tstr,
       doi: tstr,
       lineage: {
         ? parent: [* tstr],
         ? siblings: [* tstr],
         ? supersedes: [* tstr]
       }
     },
     ? class: any,
     ? policies: any,
     signatures: [* any]    ; COSE_Sign1 or CMS
   }

   payload = { cid: tstr, size: uint, ? mime: tstr, ? chunking: tstr }


Appendix B.  Example JSON SEP

   {
     "version": "1.0",
     "artifact": {"type": "training.checkpoint"},
     "digests": {"sha256": "ab..", "sha3_256": "cd.."},
     "timestamps": {"wallclock": "2025-09-26T12:34:56Z", "source": "NTS"},
     "rem": {
       "ots_proof_ref": "urn:ots:btc:txid:...",
       "doi": "doi:10.rsp/abc123",
       "lineage": {"parent": ["doi:10.rsp/dataset456"]}
     },
     "signatures": [{"...": "COSE_Sign1 bytes (base64url)"}]
   }


Appendix C.  Verification Report (JSON)

   {
     "doi": "doi:10.rsp/abc123",
     "hash_ok": true,
     "sig_ok": true,
     "attestation_ok": true,
     "ots_ok": true,
     "time_ok": true,
     "doi_ok": true,
     "verified_at": "2025-09-26T20:10:22Z"
   }


Appendix D.  Example OpenTimestamps Receipt

   (Non-normative) An OTS receipt includes commitment operations and
   attestations that enable independent reconstruction of inclusion
   in a public chain.  See [OTS].


Appendix E.  Example DOI Metadata Mapping

   title: "Model Checkpoint R1 (ResNet-50 finetune)"
   creators: [{"name": "Org Unit 7"}]
   created: "2025-09-26T12:34:56Z"
   fixity: {"sha256": "...", "sha3_256": "..."}
   lineage.parent: ["doi:10.rsp/dataset456"]
   policy_uri: "abac://policy/default/retention/75y"


Acknowledgments

   The author thanks reviewers and implementers who provided feedback on
   RSP design and alignment with REM and SCITT efforts.


Author's Address

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


Expires: 30 March 2026
