Supply Chain Integrity, Transparency, and Trust L. J. Reilly Internet-Draft REM Technologies & Consulting, LLC Intended status: Standards Track 4 August 2026 Expires: 5 February 2027 Verifiable Safeguards Records (VSR) for Nuclear Material Accountancy draft-reilly-vsr-00 Abstract Nuclear material accountancy reporting flows from facility operators to State Systems of Accounting for and Control of nuclear material (SSACs), to regional inspectorates, and to the International Atomic Energy Agency. The records exchanged are confidential, are held in separate databases that are rarely reconciled against one another, and rest on asserted rather than demonstrated integrity: a party holding a record can alter it after the fact without leaving evidence detectable by any other party. This document defines Verifiable Safeguards Records (VSR), a profile of COSE-signed statements and transparency-log registration that produces tamper-evident, independently verifiable evidence about accountancy declarations without disclosing their contents. VSR specifies a commitment-based record format supporting selective disclosure to differently authorized inspectorates, a cross-party reconciliation procedure for transit matching and discrepancy notices, and a dual-layer anchoring scheme that preserves verifiability beyond the operational lifetime of any single registry -- the horizon required for spent fuel management, decommissioning, and geological repository closure. VSR is an evidence layer. It does not verify physical measurements, detect undeclared material, or substitute for inspection. 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/. Reilly Expires 5 February 2027 [Page 1] Internet-Draft Verifiable Safeguards Records August 2026 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 5 February 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . 4 1.2. Conventions and Definitions . . . . . . . . . . . . . . . 4 2. Trust and Deployment Model . . . . . . . . . . . . . . . . . 5 3. The Safeguards Attestation Record . . . . . . . . . . . . . . 5 3.1. Signing . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. MBA and KMP References . . . . . . . . . . . . . . . . . 7 3.3. Commitment Construction . . . . . . . . . . . . . . . . . 7 4. Registration and Inclusion Evidence . . . . . . . . . . . . . 8 4.1. Verification Procedure . . . . . . . . . . . . . . . . . 8 4.2. Selective Disclosure . . . . . . . . . . . . . . . . . . 9 5. Reconciliation and Transit Matching . . . . . . . . . . . . . 9 6. Dual-Layer Anchoring . . . . . . . . . . . . . . . . . . . . 10 7. Longevity, Hash Agility, and Custodial Succession . . . . . . 11 7.1. Signature Lifetime . . . . . . . . . . . . . . . . . . . 11 7.2. Hash Migration . . . . . . . . . . . . . . . . . . . . . 11 7.3. Custodial Succession . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8.1. Metadata Exposure . . . . . . . . . . . . . . . . . . . . 13 9. Non-Proliferation Considerations . . . . . . . . . . . . . . 13 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10.1. Media Type Registration . . . . . . . . . . . . . . . . 14 10.2. VSR Declaration Types Registry . . . . . . . . . . . . . 14 10.3. VSR Payload Labels Registry . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 Reilly Expires 5 February 2027 [Page 2] Internet-Draft Verifiable Safeguards Records August 2026 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . 15 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction Nuclear material accountancy generates a continuous stream of declarations: inventory change reports, physical inventory listings, and material balance reports, each scoped to a material balance area (MBA) and referencing key measurement points (KMP). These declarations move between an operator, a national regulatory authority, a regional inspectorate, and an international inspectorate. Each participant stores its own copy. Two structural weaknesses follow. First, the copies are seldom compared, so a divergence between them may persist undetected for an extended period. Second, integrity is asserted by the custodian of each copy; there is no artifact a third party can check to establish that a record produced today is the record that was produced on the declared date. Retrospective alteration of an electronic record is therefore not, in the general case, detectable. Prototype work has established that a shared ledger addresses the first weakness [SLUMBAT] [SLAFKA]. That work also surfaced the tension this document is principally concerned with: the confidentiality required of safeguards data pushes toward end-to-end encryption, which in turn erodes the auditability that motivated the shared ledger in the first place. VSR resolves that tension by registering commitments rather than content. What is made verifiable is the existence, time, ordering, and authorship of a declaration, together with the ability of an authorized party to later prove that a specific disclosed value was the value committed to. The declaration itself never leaves the custody boundary of the parties entitled to it. A third requirement is temporal. Accountancy records associated with spent fuel management and geological disposal must remain meaningful for periods that exceed the expected lifetime of any registry operator, signature algorithm, or organization [RKM]. VSR therefore separates short-horizon verifiability (log inclusion) from long- horizon verifiability (external anchoring plus archival deposit), and specifies a migration procedure that carries evidence across cryptographic transitions without breaking the chain. Reilly Expires 5 February 2027 [Page 3] Internet-Draft Verifiable Safeguards Records August 2026 1.1. Scope and Non-Goals VSR is in scope for: integrity and non-repudiation of declarations after they are created; ordering and completeness of a declaration series; verifiable reconciliation between two parties' views of the same transfer; and preservation of the above across decades. VSR is explicitly out of scope for, and provides no assurance regarding: the accuracy of physical measurement; the correctness or completeness of what an operator chooses to declare; detection of undeclared material or activity; containment and surveillance; and environmental sampling. A declaration that is false when written is equally false when verified. See Section 9. 1.2. Conventions and Definitions 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. Declaration: An accountancy report produced by a Declarant. Its structure and content are defined by the applicable safeguards regime and are opaque to this document. Declarant: The party that authors a Declaration, typically a facility operator or a State authority acting on its behalf. Verifier: Any party checking VSR evidence. A Verifier need not be authorized to see Declaration content. Discloser / Recipient: Parties to a disclosure, in which committed values are revealed and checked against a previously registered record. Safeguards Attestation Record (SAR): The signed, registrable object defined in Section 3. A SAR commits to a Declaration; it does not contain one. Registry: An append-only log service that admits SARs and returns inclusion evidence. A Transparency Service as described in [SCITT-ARCH] satisfies this role, as does a log of the construction described in [RFC6962]. Epoch: A bounded interval of Registry operation, summarized by a single root commitment (Section 6). Reilly Expires 5 February 2027 [Page 4] Internet-Draft Verifiable Safeguards Records August 2026 Anchor: Evidence, external to the Registry, that an Epoch root existed at or before a given time. 2. Trust and Deployment Model VSR assumes four roles, which may be filled by four organizations or collapsed where a regime permits: Declarant, State authority, regional inspectorate, and international inspectorate. Any of these may act as Verifier. The Registry is a fifth role and is assumed to be partly untrusted. Specifically, the Registry is trusted to be available and to return proofs. It is _not_ trusted for integrity: a Registry that equivocates, back-dates, or omits entries is expected to be caught, either by a Verifier comparing its view against another Verifier's, or by the external Anchor of Section 6 failing to correspond. A Registry never receives Declaration content and so is not a confidentiality dependency. VSR does not require a single global Registry, and deployments SHOULD NOT assume one. A State-operated Registry whose Epoch roots are anchored publicly yields the same verifiability to an external Verifier as a shared one, while leaving custody of the log within national control. Where multiple Registries are used, cross- registration per Section 5 preserves reconciliation across them. Adversary model. The primary adversary is a party with legitimate write access that later wishes to alter, delete, reorder, or back- date its own prior records so that the altered history appears consistent to an inspectorate. Secondary adversaries are a Registry operator colluding with such a party, and a passive observer of Registry traffic attempting to infer facility activity from registration metadata (Section 8.1). 3. The Safeguards Attestation Record A SAR is a COSE_Sign1 object [RFC9052] whose payload is the CBOR [RFC8949] encoding of the structure below, expressed in CDDL [RFC8610]. Reilly Expires 5 February 2027 [Page 5] Internet-Draft Verifiable Safeguards Records August 2026 sar-payload = { 1 => uint ; version, 1 for this document 2 => decl-type ; class of declaration committed to 3 => bstr ; mba-ref: opaque MBA reference (Sec 4.2) 4 => period ; reporting period covered 5 => bstr ; commit: root commitment (Sec 4.3) 6 => uint ; seq: per-mba-ref monotonic counter 7 => bstr / null ; prev: commit of SAR seq-1, null if seq = 0 8 => bstr ; declarant: key identifier of signer 9 => uint ; issued: seconds since 1970-01-01T00:00:00Z ? 10 => [+ xref-ref] ; cross-references (Sec 6) ? 11 => alg-profile ; hash suite in use (Sec 7.1) * label => any ; extensions; unknown labels MUST be preserved } decl-type = &( inventory-change: 1, physical-inventory: 2, material-balance: 3, transfer-shipper: 4, transfer-receiver: 5, correction: 6, reconciliation: 7, discrepancy: 8, padding: 9 ; carries no declaration (Sec 9.4) ) period = [ start: uint, end: uint ] xref-ref = { 1 => bstr ; transfer-id or reconciliation subject 2 => bstr / null ; counterpart SAR commit if known 3 => tstr / null ; counterpart registry identifier } alg-profile = { 1 => int ; primary hash alg (COSE Algorithms registry) ? 2 => int ; secondary hash alg during migration } 3.1. Signing The SAR MUST be signed by a key bound to the Declarant under the deploying regime's credentialing arrangements. This document does not define that binding. Implementations MUST populate the COSE kid header and MUST include the signing algorithm in the protected header. Signature validity over long horizons is not relied upon; see Section 7. Reilly Expires 5 February 2027 [Page 6] Internet-Draft Verifiable Safeguards Records August 2026 3.2. MBA and KMP References Facility, MBA, and KMP identifiers are themselves sensitive in aggregate. A SAR MUST NOT carry a natural-language or regime- assigned facility identifier. mba-ref MUST be an opaque value produced by a keyed derivation from the regime identifier under a key held by the Declarant and shared only with authorized inspectorates. Two SARs for the same MBA are linkable to one another by design -- this is required for sequence verification -- but are not resolvable to a facility by an unauthorized Verifier. A mba-ref SHOULD be rotated only at reporting-period boundaries, and rotation MUST be bridged by a correction-type SAR naming both values under disclosure, so that sequence continuity remains provable to an authorized party. 3.3. Commitment Construction The commit field is the root of a Merkle tree over the individually salted fields of the Declaration. Constructing it per field rather than over the serialized whole is what permits disclosure of one line item without disclosure of the rest. Let the Declaration be decomposed by the Declarant into an ordered sequence of fields f[0..n-1], where the decomposition granularity MUST be no coarser than one batch entry per field. For each field, the Declarant generates a fresh salt s[i] of at least 128 bits from a cryptographically secure source, and computes the leaf leaf[i] = H( 0x00 || i || s[i] || canonical(f[i]) ) where canonical() is the deterministic CBOR encoding of the field per Section 4.2 of [RFC8949], i is encoded as a 4-octet big-endian integer, and H is the primary hash of the alg-profile. Interior nodes are computed as H(0x01 || left || right). An odd node at any level is promoted unchanged. commit is the resulting root. Salts MUST be per field and MUST NOT be derived from field content. Field value spaces in accountancy data are small and highly structured; an unsalted or uniformly salted commitment is recoverable by enumeration. This is the single most consequential implementation requirement in this document. The Declarant MUST retain the field decomposition, the salts, and the tree for the retention period applicable to the Declaration itself. Loss of salts renders the commitment undisclosable while leaving it verifiable as to existence and time -- a partial but not total loss of evidentiary value. Reilly Expires 5 February 2027 [Page 7] Internet-Draft Verifiable Safeguards Records August 2026 4. Registration and Inclusion Evidence The Declarant submits the SAR to a Registry. The Registry MUST verify the signature, MUST reject a SAR whose seq and prev do not extend the highest previously admitted SAR for that mba-ref and declarant, and MUST return a receipt constituting an inclusion proof against a signed log root. The chained prev field is deliberately redundant with the log structure. It binds the series independently of the Registry, so that a Declarant's history remains ordered and gap-evident even if the Registry is replaced, migrated, or found to have equivocated. Rejection of a non-extending SAR means corrections are additive. A Declarant that must revise a Declaration MUST register a new SAR of type correction carrying a fresh commitment and cross-referencing the superseded record. The superseded record is not removed. The visible fact that a correction occurred, and when, is intended evidence and MUST NOT be suppressible by any party. 4.1. Verification Procedure To verify a SAR, a Verifier MUST: 1. Check the COSE signature against a key it accepts for the named Declarant at the issued time. 2. Check the receipt's inclusion proof against a log root it accepts. 3. Check that the accepted log root is itself consistent with any earlier root the Verifier has retained, using a consistency proof. 4. Check that the log root is covered by a valid Anchor per Section 6, if verification is occurring outside the Registry's warranted operating period. To verify a series covering an inspection interval, a Verifier SHOULD request a bulk subtree consistency proof [BULK] rather than a proof per record. An inspection interval may cover many thousands of entries; per-record verification scales linearly in entries where subtree verification scales logarithmically in log size, and the difference determines whether full-history verification is practical at inspection time or merely in principle. Reilly Expires 5 February 2027 [Page 8] Internet-Draft Verifiable Safeguards Records August 2026 4.2. Selective Disclosure To disclose field i, the Discloser transmits, over a channel protected under the applicable regime, the tuple (i, s[i], f[i], path[i]) where path[i] is the Merkle authentication path. The Recipient recomputes leaf[i], applies the path, and compares the result to the commit in the registered SAR. A successful check establishes that the disclosed value is the value committed at registration time. It establishes nothing about the value's correspondence to physical reality. Disclosure to a Recipient at one authorization level reveals to that Recipient the tree's shape, and hence an upper bound on the number of fields in the Declaration. Where this is unacceptable, Declarants MAY pad the leaf sequence to a fixed power of two with leaves committing to a null field; padding leaves MUST be independently salted so that they are not distinguishable from populated leaves without disclosure. 5. Reconciliation and Transit Matching A transfer of material between MBAs produces two independent Declarations: one by the shipper, one by the receiver. Under current practice their agreement is established, if at all, by later comparison inside an inspectorate. VSR makes the comparison itself an artifact. Both parties register SARs of type transfer-shipper and transfer- receiver, each carrying an xref-ref whose transfer-id is a value agreed between them out of band. The transfer-id MUST be a high- entropy value with no derivable relation to material characteristics, quantity, route, or schedule. A party holding both Declarations -- typically the State authority or an inspectorate -- performs the comparison and registers a SAR of type reconciliation, committing to the comparison outcome and cross- referencing both input SARs. Where the comparison fails, or where a counterpart SAR does not appear within the matching window applicable under the regime, a SAR of type discrepancy MUST be registered instead. The property obtained is narrow and worth stating precisely: it becomes infeasible to resolve a discrepancy retroactively without the prior existence of that discrepancy remaining permanently visible. The correction record and the original both persist, in order, with times that a third party can check. What VSR removes is the quiet fix. Reilly Expires 5 February 2027 [Page 9] Internet-Draft Verifiable Safeguards Records August 2026 Where the two parties register to different Registries, each xref-ref MUST name the counterpart Registry, and the reconciling party MUST obtain and retain inclusion evidence from both. 6. Dual-Layer Anchoring Log inclusion is sufficient evidence only for as long as the Registry exists, is operated honestly, and remains checkable. None of these hold over the horizons applicable to spent fuel and repository records. VSR therefore specifies a second, external layer. A Registry MUST close Epochs at a fixed cadence and MUST, for each Epoch: 1. Compute the Epoch root over all entries admitted in the Epoch, and a consistency proof from the prior Epoch root. 2. Obtain an external timestamp over the Epoch root from at least one anchoring medium that is not under the control of the Registry operator or of any Declarant registering to it. 3. Deposit an Epoch manifest -- Epoch root, consistency proof, cadence metadata, and alg-profile -- with at least one archival service that issues a persistent identifier and undertakes preservation independent of the Registry. The two external mechanisms answer different failure modes and neither substitutes for the other. The timestamp establishes that a root existed no later than a given time, and survives the Registry's disappearance but not the loss of the manifest. The archival deposit establishes what the root was and how to interpret it, and survives institutional discontinuity but does not by itself establish time. Deployments MUST implement both. A deployment implementing only log inclusion does not conform to this document. Anchoring media and archival services are not specified here and will differ by jurisdiction. The requirements on them are: independence from the Registry operator, publication such that the anchor is checkable by a party with no relationship to any participant, and an operating undertaking longer than the Registry's. Anchoring MUST NOT publish anything beyond Epoch roots and the manifest; in particular it MUST NOT publish individual SARs, whose registration pattern is itself sensitive (Section 8.1). Reilly Expires 5 February 2027 [Page 10] Internet-Draft Verifiable Safeguards Records August 2026 7. Longevity, Hash Agility, and Custodial Succession A deployment MUST declare a Record Longevity Profile: the intended verifiability horizon, the re-anchoring cadence, the succession arrangement for Registry custody, and the trigger conditions for algorithm migration. 7.1. Signature Lifetime Signature algorithms and the credentials binding keys to Declarants will not remain valid across the horizons in question. VSR does not require them to. After an Epoch is anchored, evidentiary weight rests on the hash chain and the Anchor, not on continued signature verifiability. A Verifier operating long after issuance SHOULD treat signature verification as unavailable rather than as failed, and MUST report which of the four checks in Section 4.1 it was able to complete. 7.2. Hash Migration When a primary hash is to be retired, the Registry MUST enter a migration period during which alg-profile carries both algorithms and each Epoch root is computed and anchored under both. At the close of the migration period the Registry MUST register a bridging record: a SAR of type correction committing, under the new algorithm, to the final Epoch root computed under the old one, and MUST anchor it. The bridging record is what carries evidentiary continuity across the transition. A history that is re-hashed without a bridging record anchored under the old algorithm before its retirement is not distinguishable from a history rewritten at migration time, and MUST be treated as unverified prior to the migration point. Declarants SHOULD likewise recompute and re-register commitments for Declarations still within their retention period, preserving the original salts so that prior disclosures remain checkable against both commitments. 7.3. Custodial Succession Where custody of a Registry transfers between organizations, the outgoing custodian MUST register and anchor a final Epoch and the incoming custodian MUST register a first Epoch whose consistency proof extends it. A gap between them is a permanent, visible discontinuity in the evidence and cannot be remedied afterwards. Reilly Expires 5 February 2027 [Page 11] Internet-Draft Verifiable Safeguards Records August 2026 8. Security Considerations Origination. VSR binds a Declarant to a Declaration at a time. It has no bearing on whether the Declaration is true. An operator intending to misreport can misreport into a VSR deployment as readily as into a spreadsheet, and will produce a well-formed, fully verifiable record of the misreport. The value is confined to the detection of subsequent alteration, omission, and reordering. Commitment strength. See Section 3.3. Accountancy fields have low entropy. Salt reuse across fields, derivation of salts from content, or use of a salt shorter than 128 bits reduces the commitment to a lookup table over plausible values and defeats the confidentiality property entirely. Registry equivocation. A Registry may present different views to different Verifiers. Inclusion proofs alone do not detect this. Deployments MUST require Verifiers to compare accepted log roots against the external Anchor, and SHOULD arrange for at least two mutually independent parties to retain and periodically compare roots. Back-dating. The issued field is Declarant-asserted and MUST NOT be relied upon. Time evidence derives from Epoch anchoring, which bounds a record from above only: a record can be shown to have existed no later than its Anchor, never that it existed no earlier. Deployments requiring a lower bound MUST obtain it by requiring registration within a bounded interval of the reporting period and treating late registration as a discrepancy. Key compromise. A compromised Declarant key permits registration of fraudulent SARs but does not permit alteration of previously anchored ones. Revocation MUST be registered as a record in the log so that the interval of compromise is itself part of the verifiable history. Post-quantum posture. The hash-based components of VSR -- commitments, chaining, log structure, anchoring -- retain their properties under quantum attack with adequate output length. The signatures do not. Deployments SHOULD migrate Declarant signing to quantum-resistant algorithms, and MUST in any case not design evidentiary procedures that depend on signature verification remaining possible after the anchoring horizon. Reilly Expires 5 February 2027 [Page 12] Internet-Draft Verifiable Safeguards Records August 2026 8.1. Metadata Exposure Registration timing, volume, and periodicity constitute a side channel. Campaign cadence, outage, and inventory-taking schedules may be inferable from registration patterns even where every payload is a commitment and every identifier opaque. This is a genuine cost of transparency-based approaches in this domain and is not fully eliminable. Mitigations: Declarants SHOULD register at a fixed cadence independent of activity, emitting SARs of type padding when no Declaration is due; Epoch cadence SHOULD be coarse enough that intra- Epoch ordering is not externally observable; and Registries SHOULD accept submissions over a channel that conceals submitter identity from network observers. Padding records MUST be indistinguishable from substantive ones without disclosure. 9. Non-Proliferation Considerations This section is normative as to deployment. VSR is an integrity layer over declared information. It cannot detect undeclared material, undeclared activity, or undeclared facilities, which remain the province of inspection, containment and surveillance, environmental sampling, and complementary access. A deployment MUST NOT be represented as providing assurance in these areas, and MUST NOT be relied upon to justify reduction of inspection effort. Adoption MUST NOT diminish any obligation or authority existing under a comprehensive safeguards agreement [INFCIRC153], an additional protocol, or a regional arrangement. Where a VSR procedure and a regime requirement conflict, the regime requirement governs and the deployment is non-conforming. SAR payloads MUST NOT carry design information, process information, facility layout, transport arrangements, or physical protection information, whether directly or in an extension label. The format provides no field for such content and implementations MUST NOT add one. Identifiers are opaque per Section 3.2 for this reason as much as for confidentiality. Implementers and deployers should note that software, technical data, and services relating to nuclear activities may be subject to national export control and licensing requirements independent of anything stated in this document, and that publication of an interoperability specification does not itself constitute authorization to transfer any implementation of it. Reilly Expires 5 February 2027 [Page 13] Internet-Draft Verifiable Safeguards Records August 2026 10. IANA Considerations This document requests the following actions. 10.1. Media Type Registration Registration of application/vsr-sar+cose in the "Media Types" registry, for a Safeguards Attestation Record as defined in Section 3. Encoding: binary. Security considerations: see Section 8. Change controller: IETF. 10.2. VSR Declaration Types Registry Creation of a "VSR Declaration Types" registry with the values in Section 3 as initial entries, values 1 through 8 assigned as listed, value 9 assigned to padding, values 10 through 32767 available under Specification Required, and values 32768 and above reserved for Private Use. 10.3. VSR Payload Labels Registry Creation of a "VSR Payload Labels" registry for the map labels of sar-payload, with labels 1 through 11 as assigned in Section 3, labels 12 through 255 available under Specification Required, and labels 256 and above under First Come First Served. Registrations MUST state their conformance with Section 9. 11. References 11.1. Normative References [BULK] Reilly, L. J., "Bulk Subtree Consistency Proofs for Merkle Tree Certificates", Work in Progress, Internet-Draft, draft-reilly-plants-bulk-subtree-proofs-01, 2026, . [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, . Reilly Expires 5 February 2027 [Page 14] Internet-Draft Verifiable Safeguards Records August 2026 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, June 2019, . [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", STD 96, RFC 9052, August 2022, . 11.2. Informative References [INFCIRC153] International Atomic Energy Agency, "The Structure and Content of Agreements Between the Agency and States Required in Connection with the Treaty on the Non- Proliferation of Nuclear Weapons", INFCIRC/153 (Corrected), 1972, . [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, June 2013, . [RKM] OECD Nuclear Energy Agency, "Preservation of Records, Knowledge and Memory (RK&M) Across Generations", 2019, . [SCITT-ARCH] Birkholz, H., "An Architecture for Trustworthy and Transparent Digital Supply Chains", Work in Progress, Internet-Draft, draft-ietf-scitt-architecture, 2026, . [SLAFKA] Vestergaard, C., "SLAFKA: Demonstrating the Potential for Distributed Ledger Technology for Nuclear Safeguards Information Management", Stimson Center, STUK, and University of New South Wales, 2020, . Reilly Expires 5 February 2027 [Page 15] Internet-Draft Verifiable Safeguards Records August 2026 [SLUMBAT] Green, G. and E. G. Obbard, "The SLUMBAT demo of blockchain based nuclear safeguards", Journal of Nuclear Science and Technology, Vol. 58, No. 5, 2021, . Acknowledgements The problem framing in this document follows directly from the SLUMBAT and SLAFKA prototypes, whose authors identified the tension between confidentiality and auditability that this specification attempts to resolve. Author's Address Lawrence John Reilly REM Technologies & Consulting, LLC Tampa, FL United States of America Email: lawrencejohnreilly@gmail.com Reilly Expires 5 February 2027 [Page 16]