Verifiable Safeguards Records (VSR) for Nuclear Material Accountancy
draft-reilly-vsr-00

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,
              <https://datatracker.ietf.org/doc/draft-reilly-plants-
              bulk-subtree-proofs/>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, May 2017,
              <https://www.rfc-editor.org/info/rfc8174>.

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,
              <https://www.rfc-editor.org/info/rfc8610>.

   [RFC8949]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", STD 94, RFC 8949, 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, August 2022,
              <https://www.rfc-editor.org/info/rfc9052>.

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,
              <https://www.iaea.org/publications/documents/infcircs/
              structure-and-content-agreements-between-agency-and-
              states-required-connection-treaty-non-proliferation-
              nuclear-weapons>.

   [RFC6962]  Laurie, B., Langley, A., and E. Kasper, "Certificate
              Transparency", RFC 6962, June 2013,
              <https://www.rfc-editor.org/info/rfc6962>.

   [RKM]      OECD Nuclear Energy Agency, "Preservation of Records,
              Knowledge and Memory (RK&M) Across Generations", 2019,
              <https://www.oecd-nea.org/rwm/rkm/>.

   [SCITT-ARCH]
              Birkholz, H., "An Architecture for Trustworthy and
              Transparent Digital Supply Chains", Work in Progress,
              Internet-Draft, draft-ietf-scitt-architecture, 2026,
              <https://datatracker.ietf.org/doc/draft-ietf-scitt-
              architecture/>.

   [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,
              <https://www.stimson.org/2020/slafka/>.

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,
              <https://doi.org/10.1080/00223131.2020.1858990>.

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]