



Network Working Group                                       L. Melegassi
Internet-Draft                                                  Catellix
Intended status: Standards Track                   J. A. S. Barbosa
Expires: 26 November 2026                                 RedTeamLeaders
                                                             25 May 2026


         MVPS Trust Profile: Lightweight Authentication via
       HMAC-SHA256, Operator Epoch Anchors, and Independent
        Witness Cosignatures for Multi-Vantage Path Snapshots
              draft-melegassi-santos-ippm-mvps-cwt-00


Abstract

   The Multi-Vantage Path Snapshot (MVPS) bundle format
   [I-D.melegassi-ippm-mvps-bundle] specifies a deterministic wire
   envelope but defers cryptographic binding of vantage reports.
   This document specifies the MVPS Trust Profile, named
   Coherent-Witness Trust (CWT), which closes that gap with
   minimal cryptographic overhead: HMAC-SHA256 per-snapshot
   authentication under an epoch-bound vantage session key,
   anchored every epoch by an Ed25519-signed Operator Epoch
   Manifest, and cosigned by independent witnesses on a bundle
   Merkle checkpoint.

   The measured per-snapshot crypto cost is 2.1 us -- strictly
   less than the 4.2 us required to parse the JSON snapshot it
   protects.  At N = 1000 vantages and 1 Hz tick, the total
   verification load is 0.21 % of one CPU core.

   The profile inherits the full MVPS v4.0 theorem catalogue
   and proves two theorems not available in simpler per-snapshot
   signature designs: T-COAL-1 (multi-operator coalition
   resistance via witness independence) and T-SPLIT-1 (collector
   split-view resistance via cosignature quorum).  Numerical
   receipts are in evidence/mvps_cwt_overhead_receipt.json and
   scripts/validate_cwt_theorems.py (12/12 PASS).

   The design draws on two production precedents: the HMAC-
   personalized authentication of the Tesla vehicle-command
   protocol [TESLA-VEHICLE-CMD] and the witness-cosignature
   model of the Sigsum / tlog-witness ecosystem
   [C2SP-TLOG-WITNESS].  Neither codebase is reused; constructs
   are independently composed for the multi-vantage measurement
   setting.


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 26 November 2026.


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.  Motivation: Lightweight Trust Without Compromise . . . .   3
     1.2.  Design Rationale vs. Per-Snapshot Ed25519  . . . . . . .   4
     1.3.  Relationship to MVPS v4.0 Mathematics  . . . . . . . . .   5
     1.4.  Production Precedents (Tesla, Sigsum) . . . . . . . . .   5
   2.  Terminology and Conventions  . . . . . . . . . . . . . . . .   6
   3.  Trust Boundary and Preconditions . . . . . . . . . . . . . .   7
     3.1.  H-TRUST-CWT: Authenticated Vantage Reporting . . . . . .   7
     3.2.  H-ADM: Admitted Vantage Set  . . . . . . . . . . . . . .   8
     3.3.  H-WIT: Independent Witness Network . . . . . . . . . . .   8
     3.4.  Impact on Downstream Theorems  . . . . . . . . . . . . .   9
   4.  Threat Model . . . . . . . . . . . . . . . . . . . . . . . .  10
     4.1.  Adversary Capabilities . . . . . . . . . . . . . . . . .  10
     4.2.  Attack Classes . . . . . . . . . . . . . . . . . . . . .  11
     4.3.  Operational Impact Matrix  . . . . . . . . . . . . . . .  12
   5.  Three-Tier Key Hierarchy . . . . . . . . . . . . . . . . . .  13
     5.1.  Layer 1: Vantage HMAC Session Key  . . . . . . . . . . .  13
     5.2.  Layer 2: Operator Epoch Manifest (Ed25519) . . . . . . .  14
     5.3.  Layer 3: Witness Network (Ed25519 Cosignatures)  . . . .  15
     5.4.  Key Derivation via HKDF  . . . . . . . . . . . . . . . .  15
     5.5.  Rotation and Compromise  . . . . . . . . . . . . . . . .  16
   6.  Snapshot Authentication (HMAC-Personalized)  . . . . . . . .  17
     6.1.  Personalized Authentication Fields . . . . . . . . . . .  17
     6.2.  HMAC Computation . . . . . . . . . . . . . . . . . . . .  18
     6.3.  Wire Format  . . . . . . . . . . . . . . . . . . . . . .  19
     6.4.  Verification Procedure . . . . . . . . . . . . . . . . .  20
   7.  Operator Epoch Manifest  . . . . . . . . . . . . . . . . . .  21
     7.1.  Manifest Content . . . . . . . . . . . . . . . . . . . .  21
     7.2.  Distribution and Caching . . . . . . . . . . . . . . . .  22
     7.3.  Epoch Transitions  . . . . . . . . . . . . . . . . . . .  22
   8.  Bundle Checkpoint and Witness Cosignatures . . . . . . . . .  23
     8.1.  Merkle Aggregation . . . . . . . . . . . . . . . . . . .  23
     8.2.  Checkpoint Format  . . . . . . . . . . . . . . . . . . .  24
     8.3.  Witness Submission Protocol  . . . . . . . . . . . . . .  25
     8.4.  Quorum Policy  . . . . . . . . . . . . . . . . . . . . .  26
   9.  Anti-Replay (Embedded Counter) . . . . . . . . . . . . . . .  27
     9.1.  Counter Semantics  . . . . . . . . . . . . . . . . . . .  27
     9.2.  Freshness via expires_at . . . . . . . . . . . . . . . .  27
     9.3.  Minimal Replay Cache . . . . . . . . . . . . . . . . . .  28
   10. Parser Safety Limits . . . . . . . . . . . . . . . . . . . .  28
   11. Path Fingerprint: Security Semantics . . . . . . . . . . . .  29
   12. Witness Network Architecture . . . . . . . . . . . . . . . .  29
     12.1.  Witness Identity and Key Publication  . . . . . . . . .  29
     12.2.  Cross-Organization Requirement  . . . . . . . . . . . .  30
     12.3.  Split-View Detection  . . . . . . . . . . . . . . . . .  30
     12.4.  Witness Liveness  . . . . . . . . . . . . . . . . . . .  31
   13. Interoperability with Coherence-BFD  . . . . . . . . . . . .  31
   14. Operational Considerations . . . . . . . . . . . . . . . . .  32
     14.1.  Cost Analysis . . . . . . . . . . . . . . . . . . . . .  32
     14.2.  Embedded and LEO Vantages . . . . . . . . . . . . . . .  33
     14.3.  Production Precedents . . . . . . . . . . . . . . . . .  33
     14.4.  Archival Mode . . . . . . . . . . . . . . . . . . . . .  34
   15. Security Considerations  . . . . . . . . . . . . . . . . . .  34
   16. Privacy Considerations . . . . . . . . . . . . . . . . . . .  35
   17. IANA Considerations  . . . . . . . . . . . . . . . . . . . .  35
   18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  36
   19. References . . . . . . . . . . . . . . . . . . . . . . . . .  36
     19.1.  Normative References  . . . . . . . . . . . . . . . . .  36
     19.2.  Informative References  . . . . . . . . . . . . . . . .  37
   Appendix A.  JSON CWT Extension (Informative)  . . . . . . . . .  38
   Appendix B.  Worked Verification Example . . . . . . . . . . . .  39
   Appendix C.  Mathematical Core (Normative) . . . . . . . . . . .  40
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .  43


1.  Introduction

   The MVPS bundle format [I-D.melegassi-ippm-mvps-bundle] is consumed
   by several detection profiles
   ([I-D.melegassi-coherence-bfd],
    [I-D.melegassi-ippm-mvps-coherence-leadtime],
    [I-D.melegassi-mvps-ddos-resilience],
    [I-D.melegassi-mvps-ai-coherence]).  Section 10.2 of the base
   bundle acknowledges bundle poisoning and defers cryptographic
   binding.  Section 10.3 acknowledges replay without mandating a
   mechanism.

   Without authenticated vantage reporting, any detection profile
   that consumes MVPS bundles operates on unverified input.  A
   compromised or spoofed vantage can inject arbitrary values into
   C_1, C_2, C_3 and D^2 without detection.  This document closes
   that gap.

   Three concrete problems motivate the design:

   (a) Per-snapshot public-key verification (e.g., Ed25519) costs
       ~79 us, scaling to ~7.9 % of one CPU core at N = 1000
       vantages / 1 Hz tick -- a non-trivial tax on the broker.

   (b) Per-operator Sybil quotas protect only against a SINGLE-
       OPERATOR adversary.  Multi-operator collusion (each operator
       within individual quota, coalition mass >= N/2) is not
       formally defeated without an independent third party.

   (c) A compromised collector can present different bundle contents
       to different consumers (split-view) without breaking per-
       snapshot signatures.

   This document specifies the MVPS Coherent-Witness Trust (CWT)
   profile.  It addresses (a), (b), and (c) simultaneously with
   three minimal cryptographic layers at matched cadences:

      LAYER 1: HMAC-SHA256 per snapshot (hot path; 2.1 us
               measured; Section 6).
      LAYER 2: Ed25519-signed Operator Epoch Manifest (anchor;
               once per hour; Section 7).
      LAYER 3: Ed25519 witness cosignatures on bundle Merkle
               checkpoint (split-view / coalition defense;
               Section 8).

   CWT inherits the full MVPS v4.0 theorem catalogue and proves
   two additional theorems T-COAL-1 and T-SPLIT-1 (Appendix C).
   Proofs are in [MVPS-CWT-PROOF]; numerical receipt is in
   evidence/mvps_cwt_overhead_receipt.json; validator exit code
   is scripts/validate_cwt_theorems.py (12/12 PASS).


1.1.  Design Goals

   CWT is designed to be simultaneously:

   o  NEAR-ZERO OVERHEAD.  The hot-path cost (HMAC-SHA256 per
      snapshot) is 2.1 us -- below the 4.2 us cost of parsing
      the snapshot it authenticates.  Crypto overhead is invisible
      in any realistic broker budget (Section 14.1, measured
      receipt evidence/mvps_cwt_overhead_receipt.json).

   o  EMBEDDED-READY.  HMAC-SHA256 is universally available as
      hardware primitive on ARM Cortex-M, IoT SoCs, and LEO
      satellite payloads.  No per-snapshot Ed25519 key pair is
      required at the vantage; only a 32-octet session key.

   o  FORENSICALLY TRANSPARENT.  Append-only Merkle checkpoints
      cosigned by independent witnesses give public auditors a
      tamper-evident log of every bundle without requiring access
      to per-snapshot MAC keys.

   o  COALITION AND SPLIT-VIEW RESISTANT.  The witness layer
      closes two attack classes not addressed by simpler designs:
      multi-operator Sybil coalitions (T-COAL-1) and collector
      split-view (T-SPLIT-1).  These are strengthening, not
      relaxation, relative to signature-per-snapshot approaches.


1.2.  Design Rationale vs. Per-Snapshot Ed25519

   A straightforward trust design would place one Ed25519 signature
   per snapshot (sign at vantage, verify at consumer).  CWT does
   not use that approach for the following reasons, each quantified:

   (a) COST.  Ed25519 verify costs ~79 us on a modern core.
       At N = 1000 vantages, 1 Hz: 79 ms/s = 7.9 % of one core
       for authentication alone, before any coherence algebra.
       HMAC-SHA256 at the same workload: 2.1 ms/s = 0.21 %.

   (b) EMBEDDED DEPLOYMENT.  A 32-octet HMAC session key fits
       in any SoC key store.  Ed25519 requires a 64-octet private
       key and a constant-time scalar-multiplication library, not
       universally available on constrained hardware.

   (c) COALITION GAP.  Per-snapshot signatures do not prevent a
       group of operators from collectively owning >= N/2 admitted
       vantages while each stays within individual quota.  CWT
       closes this with witness cosignatures (T-COAL-1).

   (d) SPLIT-VIEW GAP.  A collector that signs bundles can present
       different "current" bundles to different consumers without
       violating any per-snapshot signature.  CWT closes this
       by binding the collector to a single Merkle root per
       (bundle_id, bundle_seq) via witness cosignatures (T-SPLIT-1).

   Implementations that require individual-snapshot non-repudiation
   (e.g., for legal evidence chains) MAY combine CWT Layer 1 with
   an additional per-snapshot Ed25519 signature in an extension
   field; this is out of scope for this document.


1.3.  Relationship to MVPS v4.0 Mathematics

   The MVPS v4.0 mathematical catalogue [MVPS-V4] is inherited
   verbatim under H-TRUST-CWT + H-ADM + H-WIT + f < N/2 + MVPS-A4.
   See Appendix C, Theorem T-COMP-2-CWT.

   CWT additionally proves two theorems beyond the v4.0 catalogue:

   T-COAL-1.  Multi-operator coalition with combined Sybil mass
              f' >= N/2 is detected with overwhelming probability
              when at least floor(w/2)+1 of w independent witnesses
              are honest (Appendix C.6).

   T-SPLIT-1. Collector split-view of a bundle checkpoint is
              detected by any two auditors querying any honest
              witness within one checkpoint window (Appendix C.6).


1.4.  Production Precedents (Tesla vehicle-command and Sigsum)

   Two production systems inform CWT's wire format choices without
   reusing their code:

   o  TESLA VEHICLE-COMMAND PROTOCOL
      <https://github.com/teslamotors/vehicle-command>.  Authenticates
      safety-critical commands (vehicle unlock, drive enable) using
      HMAC-SHA256 with personalization fields (counter, epoch,
      expires_at).  Demonstrates that HMAC-SHA256 with anti-replay
      personalization is acceptable for safety-critical authoriza-
      tion at scale on embedded hardware (BLE SoCs, Secure Elements).
      CWT's Section 6.1 personalization fields follow this pattern,
      adapted for measurement bundles.

   o  SIGSUM / TLOG-WITNESS [C2SP-TLOG-WITNESS].  Transparency log
      ecosystem with independent witnesses cosigning checkpoints to
      prevent split-view attacks.  Built-in policy
      "sigsum-generic-2025-1" requires two logs and three witnesses.
      CWT's Layer 3 (Section 8 and Section 12) directly adopts the
      tlog-witness API surface (POST /add-checkpoint) and the
      cosignature format of [C2SP-TLOG-COSIGNATURE].

   CWT is NOT a Sigsum log; the bundle Merkle tree is a small,
   per-coordination-window structure, not a long-running append-only
   log.  However, the cosignature semantics and witness trust model
   are deliberately compatible to maximize reuse of existing tooling.


2.  Terminology and Conventions

   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.

   Admitted set:
      Same as [I-D.melegassi-santos-ippm-mvps-trust].  Denoted A.

   Coalition (adversary):
      A set of operators C with combined |coalition_vantages| >= N/2
      in A, each operator within its individual quota.

   Epoch:
      A bounded time interval, typically one hour, during which a
      single operator session key K_v_epoch is used by vantage v.
      Identified by uint32 epoch_id, monotonically increasing per
      operator.

   K_v_epoch:
      The HMAC-SHA256 key used by vantage v during epoch_id.  Derived
      via HKDF [RFC5869] from an operator master key and the tuple
      (vantage_id, epoch_id).

   Operator Epoch Manifest (OEM):
      An Ed25519-signed JSON document, published by an operator at the
      start of each epoch, binding K_v_epoch commitments to vantage
      identities.

   Checkpoint:
      A Merkle tree root over the SHA-256 digests of snapshots
      contained in a bundle, plus metadata (bundle_id, bundle_seq,
      issued_at).

   Witness:
      An independent service that verifies checkpoint consistency
      and cosigns checkpoints it accepts.  Witness identity and
      cosignature format follow [C2SP-TLOG-COSIGNATURE].

   Quorum:
      The minimum number of independent witness cosignatures REQUIRED
      for a checkpoint to be accepted by a consumer.  Default 2.

   Split-view:
      A failure mode in which a malicious collector presents
      different "current" bundle contents to different consumers.


3.  Trust Boundary and Preconditions

3.1.  H-TRUST-CWT: Authenticated Vantage Reporting

   HYPOTHESIS H-TRUST-CWT.  Every snapshot consumed by a CWT-conformant
   detector carries a valid HMAC-SHA256-Personalized tag (Section 6)
   computed under K_v_epoch, where the (vantage_id, K_v_epoch
   commitment, epoch_id) tuple is bound by a current Operator Epoch
   Manifest (Section 7).

   Enforcement:

      o  Each snapshot carries a CWT trust wrapper (Section 6.3).

      o  The consumer verifies the HMAC tag using K_v_epoch obtained
         from the current OEM (Section 7) before parsing snapshot
         fields beyond the trust wrapper.

      o  Snapshots failing verification MUST be discarded and MUST NOT
         contribute to N or to C_1, C_2, C_3.


3.2.  H-ADM: Admitted Vantage Set

   Identical to Section 3.2 of
   [I-D.melegassi-santos-ippm-mvps-trust]: the consumer maintains an
   explicit admitted set A; only vantages in A count toward N.

   Admission is established by the Operator Epoch Manifest plus the
   campaign Admission Policy Document; vantage_id strings alone do
   NOT prove membership in A.


3.3.  H-WIT: Independent Witness Network

   HYPOTHESIS H-WIT.  The consumer accepts bundle checkpoints only when
   they carry cosignatures from at least q independent witnesses,
   where q is the campaign-configured quorum (default q = 2), drawn
   from a published witness anchor set W.

   "Independent" in this document means:

      o  distinct organizational control (different legal entities or
         distinct administrative domains),

      o  distinct jurisdiction or distinct upstream AS path, where
         possible,

      o  no shared key material (each witness uses its own Ed25519
         key pair).

   Enforcement:

      o  Bundles whose checkpoint lacks q valid cosignatures from W
         MUST be rejected.

      o  Witness key rotation follows Section 12.1.


3.4.  Impact on Downstream Theorems

   Table 1 maps trust failures specific to CWT to MVPS preconditions
   and downstream effects.

   +==================+======================+=========================+
   | Failure mode     | Precondition lost    | Downstream effect       |
   +==================+======================+=========================+
   | Missing/invalid  | H-TRUST-CWT          | Snapshot rejected;      |
   | HMAC tag         |                      | N not incremented       |
   +------------------+----------------------+-------------------------+
   | Stale OEM        | H-TRUST-CWT (K_v     | All snapshots in stale  |
   | (expired epoch)  | binding lost)        | window rejected         |
   +------------------+----------------------+-------------------------+
   | Coalition        | H-ADM                | Theorem 9 would void    |
   | f' >= N/2 across | (single-operator     | except witnesses detect |
   | operators        | quota satisfied)     | (T-COAL-1)              |
   +------------------+----------------------+-------------------------+
   | Collector split- | H-WIT                | Two views of same       |
   | view             |                      | checkpoint detected by  |
   |                  |                      | quorum disagreement     |
   |                  |                      | (T-SPLIT-1)             |
   +------------------+----------------------+-------------------------+
   | Counter regress  | anti-replay          | Snapshot rejected       |
   +------------------+----------------------+-------------------------+
   | Expired snapshot | freshness            | Snapshot rejected       |
   | (expires_at)     |                      |                         |
   +------------------+----------------------+-------------------------+
   | Witness          | H-WIT (quorum lost   | Consumer falls back to  |
   | unavailability   | below q)             | safe mode or rejects    |
   +==================+======================+=========================+


4.  Threat Model

4.1.  Adversary Capabilities

   Adversary A is modeled as in Section 4.1 of
   [I-D.melegassi-santos-ippm-mvps-trust] (compromise, impersonation,
   Sybil, collector compromise, MITM, replay, parser DoS, gauge gap),
   extended with:

      (i)  Multi-operator coalition: A controls k <= number_of_operators
           operator accounts, each within individual quota, with
           combined admitted vantages >= N/2.

      (j)  Split-view collector: A controls the collector, observes
           bundle queries from different consumers, and tailors
           differing bundle contents per consumer.

   A does NOT have:

      (k)  Ability to forge HMAC-SHA256 tags without K_v_epoch
           (HMAC unforgeable under PRF assumption [RFC2104]).

      (l)  Ability to forge Ed25519 signatures on OEMs without the
           operator private key.

      (m)  Ability to compromise floor(w/2)+1 of w independent
           witnesses (witness independence is operational hypothesis
           H-WIT).


4.2.  Attack Classes

   The following attack classes MUST be addressed by CWT
   implementations.

   T-POISON (vantage lying):
      Defense: HMAC tag verification + multi-vantage corroboration +
      C_1 speed-of-light bound.

   T-COLL (collector tampering):
      Defense: per-snapshot HMAC verified at consumer; checkpoint
      Merkle root cosigned by witnesses (Section 8).

   T-MITM (unsigned transport):
      Defense: HMAC over canonical snapshot bytes; TLS 1.3 [RFC8446]
      or DTLS 1.3 [RFC9147] on transport RECOMMENDED.

   T-SYBIL (fake vantage majority within one operator):
      Defense: operator quota (Section 5.2) and Admission Policy.

   T-REPLAY (stale bundle):
      Defense: per-snapshot counter + expires_at (Section 9).

   T-PARSER (DoS):
      Defense: Section 10 mandatory parser limits.

   T-GAUGE (same fingerprint, different physical path):
      Defense: Section 11 (multi-signal consumption).

   T-COAL (multi-operator coalition):  NEW.
      Defense: witness independence (H-WIT) and quorum cosignature
      (Section 12).  Even when sum of individual operator quotas
      reaches N/2, an adversary cannot influence the consumer's
      accepted bundle stream without colluding with floor(w/2)+1
      witnesses (Theorem T-COAL-1, Appendix C).

   T-SPLIT (collector split-view):  NEW.
      Defense: witness cosignature commits the witness to a single
      checkpoint per (bundle_id, bundle_seq).  Two auditors querying
      any honest witness within one checkpoint window will detect
      disagreement (Theorem T-SPLIT-1, Appendix C).


4.3.  Operational Impact Matrix

   When H-TRUST-CWT, H-ADM, or H-WIT fail, the downstream profiles
   [I-D.melegassi-coherence-bfd],
   [I-D.melegassi-ippm-mvps-coherence-leadtime],
   [I-D.melegassi-mvps-ddos-resilience], and
   [I-D.melegassi-mvps-ai-coherence] lose integrity guarantees.
   Two CWT-specific failure modes are notable:

      o  Without H-WIT, AI-Coherence Part B is vulnerable to a single
         compromised operator + collector pair manufacturing
         "consensus" across all customer queries.

      o  Without H-WIT, Coherence-BFD ALARM can be selectively masked
         to specific customers via split-view.

   Implementers SHOULD treat CWT as a hard dependency for
   production deployment, analogous to RPKI for origin validation.


5.  Three-Tier Key Hierarchy

   CWT defines exactly three layers of key material.  Each layer uses
   a distinct primitive matched to its cadence.


5.1.  Layer 1: Vantage HMAC Session Key

   Each vantage v holds a per-epoch HMAC-SHA256 session key
   K_v_epoch, valid for the duration of one epoch.  K_v_epoch is
   derived (Section 5.4) at the start of each epoch from:

      o  an operator master key K_op (held by the operator only),

      o  the vantage identifier vantage_id,

      o  the epoch_id (uint32, monotonically increasing per operator).

   K_v_epoch is REQUIRED to be 32 octets.  It is NOT distributed to
   consumers; only its commitment H(K_v_epoch) appears in the
   Operator Epoch Manifest (Section 7).

   Consumers MUST obtain K_v_epoch via one of the following channels:

      (a) An out-of-band per-campaign secret distribution (preferred
          for closed-operator deployments).

      (b) A delayed-disclosure mechanism similar to TESLA [TESLA]:
          the operator publishes K_v_epoch in the NEXT epoch's OEM
          along with the new H(K_v_(epoch+1)).  Consumers verify
          past-epoch snapshots upon disclosure.  This trades real-
          time verification for public auditability.

   This document defines mode (a) as MANDATORY-TO-IMPLEMENT; mode (b)
   is OPTIONAL.


5.2.  Layer 2: Operator Epoch Manifest (Ed25519)

   Each operator holds a long-lived Ed25519 key pair (op_sk, op_pk).
   Once per epoch (typically once per hour), the operator publishes
   an Operator Epoch Manifest (OEM) signed under op_sk:

      OEM = (epoch_id, operator_id, issued_at, expires_at,
             vantage_commitments[], policy_hash, op_signature)

   where vantage_commitments[i] = (vantage_id_i, H(K_v_epoch_i),
   admission_tier_i).

   The operator's op_pk is distributed via the campaign Admission
   Policy Document (signed by the campaign root, out of band).

   OEM verification cost is paid once per epoch per operator
   (~150 us); it is amortized across all snapshots in the epoch.


5.3.  Layer 3: Witness Network (Ed25519 Cosignatures)

   The witness layer is composed of w >= 3 independent witnesses,
   each holding an Ed25519 key pair.  Witness public keys are
   published in the campaign Admission Policy Document and SHOULD
   ALSO be published by each witness operator at a well-known URI.

   When a collector emits a bundle, it computes the bundle checkpoint
   (Section 8) and submits the checkpoint to each witness via the
   POST /add-checkpoint endpoint specified by [C2SP-TLOG-WITNESS].
   Each accepting witness returns a cosignature in the format of
   [C2SP-TLOG-COSIGNATURE].

   A bundle is "witness-anchored" once it carries at least q
   cosignatures from distinct witnesses in W (Section 12.2).


5.4.  Key Derivation via HKDF

   K_v_epoch is derived as:

      K_v_epoch =
         HKDF-SHA256(
            salt   = "MVPS-CWT-v1|operator:" || operator_id,
            ikm    = K_op,
            info   = "vantage:" || vantage_id || "|epoch:" || epoch_id,
            length = 32)

   K_op is itself a 32-octet operator master secret, generated with a
   CSPRNG and stored with operational-secret protection.

   Implementations MUST NOT reuse K_op across operators or campaigns.


5.5.  Rotation and Compromise

   K_op rotation:
      SHOULD occur at least every 90 days.  Triggers a campaign-wide
      manifest refresh.

   K_v_epoch rotation:
      Implicit: a new K_v_epoch is derived at every epoch_id
      increment.  Default cadence: hourly.

   Witness key rotation:
      SHOULD occur at least every 180 days.  Witness operators MUST
      publish revocation entries on compromise.

   Operator Ed25519 key rotation:
      SHOULD occur at least every 180 days.

   Compromise of K_op exposes all in-window K_v_epoch derivatives;
   immediate K_op rotation (and OEM re-issuance with a fresh
   policy_hash) restores soundness for future epochs.


6.  Snapshot Authentication (HMAC-Personalized)

6.1.  Personalized Authentication Fields

   Each authenticated snapshot carries the following personalization
   tuple in its trust wrapper:

   {
     "epoch_id":   <uint32>,
     "counter":    <uint64, strictly increasing per (vantage_id,
                                                     epoch_id)>,
     "expires_at": <uint32 RFC 3339 seconds-since-epoch>,
     "vantage_id": "<string>",
     "operator_id":"<string>"
   }

   The expires_at field MUST be no later than the OEM's expires_at
   for the matching epoch_id.


6.2.  HMAC Computation

   Let canonical_payload be the canonical UTF-8 byte sequence of the
   base bundle snapshot fields, sorted lexicographically per
   [I-D.melegassi-ippm-mvps-bundle] Section 5.1:

      o  destination, end-timestamp, hops, path_fingerprint,
         start-timestamp, vantage-id.

   The authenticated input M is:

      M = "MVPS-CWT-v1|"
       || canonical_payload
       || "|epoch:"   || ascii(epoch_id)
       || "|counter:" || ascii(counter)
       || "|expires:" || ascii(expires_at)
       || "|vantage:" || vantage_id
       || "|operator:"|| operator_id

   The tag is:

      tag = HMAC-SHA256(K_v_epoch, M)

   tag is 32 octets, base64url-encoded for wire format.


6.3.  Wire Format

   The CWT trust wrapper is carried alongside the base snapshot:

   {
     "snapshot": { ... base MVPS snapshot fields ... },
     "mvps_cwt": {
       "version":    1,
       "operator_id":"<string>",
       "vantage_id": "<string>",
       "epoch_id":   <uint32>,
       "counter":    <uint64>,
       "expires_at": <uint32>,
       "tag":        "<base64url, 32 octets>"
     }
   }

   The wrapper overhead is ~48 octets per snapshot (32-octet tag
   plus small uint fields), versus ~128 octets for a per-snapshot
   Ed25519 design (64-octet signature plus key identifier).


6.4.  Verification Procedure

   For each snapshot, the consumer:

   1.  Enforces Section 10 limits on raw byte size before JSON parse.

   2.  Extracts (operator_id, vantage_id, epoch_id, counter,
       expires_at, tag).

   3.  Loads OEM for (operator_id, epoch_id); verifies its Ed25519
       signature, expires_at validity, and bundle admission policy.

   4.  Loads K_v_epoch via the channel of Section 5.1 (out of band)
       and checks H(K_v_epoch) against the OEM commitment.

   5.  Reconstructs M (Section 6.2) and computes
       expected_tag = HMAC-SHA256(K_v_epoch, M).

   6.  Performs constant-time comparison expected_tag == tag.

   7.  Checks counter strictly greater than last accepted counter for
       (vantage_id, epoch_id); checks now < expires_at.

   8.  Only then merges snapshot into bundle processing.

   Failure at any step: discard snapshot, log trust failure, do not
   adjust N.


7.  Operator Epoch Manifest

7.1.  Manifest Content

   {
     "oem_version":  1,
     "operator_id":  "<string>",
     "epoch_id":     <uint32>,
     "issued_at":    "<RFC3339Z>",
     "expires_at":   "<RFC3339Z>",
     "vantage_commitments": [
       {
         "vantage_id":      "<string>",
         "k_v_commitment":  "<hex, SHA-256 of K_v_epoch>",
         "admission_tier":  "atlas-probe | operator-noc | ...",
         "key_disclosure":  "out-of-band | delayed"
       }
     ],
     "policy_hash":    "<hex, SHA-256 of Admission Policy Document>",
     "ed25519_signature": "<base64url, 64 octets>"
   }

   The signature is computed over the canonical JSON of the OEM with
   the ed25519_signature field removed.


7.2.  Distribution and Caching

   OEMs SHOULD be served over HTTPS from a well-known operator URI.
   Consumers cache OEMs for the lifetime of expires_at; cache size is
   bounded by the number of operators and the overlap window between
   epochs (typically <= 2 OEMs per operator at any time).


7.3.  Epoch Transitions

   The operator MUST publish OEM_(epoch+1) before the current OEM's
   expires_at, with overlap >= 5 minutes (default), to avoid
   verification gaps.  Snapshots submitted during overlap MAY carry
   either epoch_id; consumers MUST accept either, provided the OEM
   for that epoch is valid.


8.  Bundle Checkpoint and Witness Cosignatures

8.1.  Merkle Aggregation

   For each bundle b containing snapshots s_1, ..., s_m, the collector
   computes:

      leaf_i        = SHA-256(canonical(s_i with mvps_cwt wrapper))
      checkpoint_root = MerkleTreeRoot(leaf_1, ..., leaf_m)

   The Merkle tree construction follows [RFC9162] Section 2.1 (RFC
   6962-bis), with leaf domain separator 0x00 and node domain
   separator 0x01.


8.2.  Checkpoint Format

   A checkpoint is a textual record in the format of
   [C2SP-TLOG-CHECKPOINT]:

      origin:        "mvps-cwt/v1/<campaign_id>"
      tree_size:     m
      root_hash:     <base64 checkpoint_root>
      timestamp:     <RFC3339Z issued_at>
      extra:         "bundle_id=<uuid>;bundle_seq=<uint64>"

   followed by one or more signature lines:

      "- <key_id> <base64 signature>"

   The collector signs the checkpoint with its own Ed25519 key.
   Witnesses cosign the checkpoint per Section 8.3.


8.3.  Witness Submission Protocol

   The collector POSTs the checkpoint (and any required consistency
   proof) to each witness's /add-checkpoint endpoint per
   [C2SP-TLOG-WITNESS] Section 3.

   On accept, the witness returns a cosignature line in the
   [C2SP-TLOG-COSIGNATURE] format.  The collector appends the
   cosignature lines to the checkpoint and includes the final
   checkpoint in the bundle envelope as field "cwt_checkpoint".


8.4.  Quorum Policy

   A consumer MUST accept a bundle only if its cwt_checkpoint carries
   at least q valid cosignatures from witnesses listed in the campaign
   Admission Policy Document, where q is the quorum parameter
   (default q = 2).

   Cosignatures are valid when:

      o  the signing key matches a witness key_id in W,

      o  the witness has not been revoked at the checkpoint timestamp,

      o  the cosignature verifies under [C2SP-TLOG-COSIGNATURE]
         semantics over the checkpoint bytes.


9.  Anti-Replay (Embedded Counter)

9.1.  Counter Semantics

   counter is a uint64 strictly increasing per (vantage_id, epoch_id).
   counter resets to 0 at every epoch_id increment.

   This eliminates the need for the bundle-level (bundle_id,
   bundle_seq) cache REQUIRED by
   [I-D.melegassi-santos-ippm-mvps-trust] Section 8.2; CWT consumers
   maintain only the per-(vantage_id, epoch_id) last-accepted counter,
   which is bounded by N vantages.


9.2.  Freshness via expires_at

   The per-snapshot expires_at field defines the consumer-side
   freshness window.  Consumers MUST reject snapshots where
   now >= expires_at.  No separate freshness_ttl parameter is needed.


9.3.  Minimal Replay Cache

   Per-(vantage_id, epoch_id) state at the consumer:

      last_counter[vantage_id][epoch_id] : uint64

   Size: O(N) per active epoch.  Two epochs maximum during overlap
   window.  Garbage-collected on epoch expires_at.


10.  Parser Safety Limits

   The mandatory limits of
   [I-D.melegassi-santos-ippm-mvps-trust] Section 9 apply unchanged:

      max_bundle_bytes:        1 048 576
      max_snapshots:           256
      max_hops_per_snapshot:   128
      max_json_depth:          32
      max_string_length:       4096
      max_vantage_id_length:   128
      max_extensions_per_hop:  8

   In addition, CWT-specific limits:

      max_oems_cached:         64
      max_witness_cosigs:      16
      max_epoch_overlap:       7200 s


11.  Path Fingerprint: Security Semantics

   The gauge-gap semantics of
   [I-D.melegassi-santos-ippm-mvps-trust] Section 10 apply unchanged.
   CWT consumers MUST combine path_fingerprint with per-snapshot RTT
   (C_1), cross-vantage distribution divergence (C_2), and edge-set
   Jaccard (C_3) before declaring coherence.

   Detectors using ONLY the path-fingerprint are NOT CWT-conformant.


12.  Witness Network Architecture

12.1.  Witness Identity and Key Publication

   Each witness publishes:

      o  an Ed25519 public key in [C2SP-TLOG-COSIGNATURE] format,

      o  a "witness identity descriptor" specifying organizational
         identity, jurisdiction, contact, key validity window,

      o  a revocation feed (signed entries listing revoked keys).

   The campaign Admission Policy Document lists the witness public
   keys to be accepted, with assigned key_id labels.


12.2.  Cross-Organization Requirement

   The witness anchor set W MUST satisfy:

      |W|     >= 3,
      q       >= 2     (default; campaigns MAY require higher),
      diversity(W) such that no single organizational entity controls
                       more than floor(|W|/2) witnesses.

   For |W| = 3, no entity controls more than 1.  For |W| = 5, no
   entity controls more than 2.  These are the operational
   instantiations of H-WIT (Section 3.3).


12.3.  Split-View Detection

   A consumer suspecting split-view MAY query any honest witness
   (out of band) for its history of cosigned checkpoints for a given
   campaign + bundle_id.  Any two consumers comparing their accepted
   bundles for the same (bundle_id, bundle_seq) MUST receive identical
   root_hash values when any single honest witness is queried by both.

   This is the operational instantiation of Theorem T-SPLIT-1
   (Appendix C).


12.4.  Witness Liveness

   A witness MAY fail or be temporarily unreachable.  If fewer than q
   cosignatures are obtained within a configured timeout
   (default 5 s after collector submission), the collector:

      o  MAY publish a partial-quorum bundle marked "degraded": true,

      o  MUST NOT silently omit the degraded flag.

   Consumers in production mode MUST reject degraded bundles unless
   campaign policy permits degraded ingestion explicitly (e.g., for
   continuity during scheduled witness maintenance).


13.  Interoperability with Coherence-BFD

   Coherence-BFD [I-D.melegassi-coherence-bfd] uses AuthHMAC-SHA256
   on the UDP control plane.  That HMAC key MUST be cryptographically
   independent from K_v_epoch of this document.  Implementations MUST
   derive the Coherence-BFD HMAC key under a distinct HKDF label
   (e.g., "coherence-bfd-auth-v1") even if the underlying K_op is
   shared.

   Consumers using both protocols MUST verify CWT trust on bundle
   ingest independently of Coherence-BFD session state.


14.  Operational Considerations

14.1.  Cost Analysis (Measured Receipt)

   The following per-operation latencies were measured on an end-to-
   end run of scripts/bench_cwt_overhead.py and stored at
   evidence/mvps_cwt_overhead_receipt.json (machine-readable,
   reproducible).  The corresponding figure is
   docs/figures/bench_cwt_overhead.png.

   Median per-op latency (canonical snapshot = 497 bytes):

      json_decode (baseline parse)  :  4.20 us
      sha256 (1 leaf)               :  0.70 us
      hmac_sha256 (CWT hot path)    :  2.10 us    <--- CWT per-snap
      hkdf_sha256 (per-epoch derive):  4.10 us
      ed25519_sign  (Trust signer)  : 28.70 us
      ed25519_verify (Trust verify) : 78.80 us    <--- Trust per-snap

   KEY CLAIM (verified): the CWT hot-path HMAC tag costs LESS than
   parsing the JSON snapshot it protects (2.10 us vs 4.20 us).
   Crypto overhead is therefore strictly below the parse-itself
   overhead a consumer ALREADY pays.

   At N = 1000 vantages with 1 Hz tick:

      CWT load   : 0.21 % of one CPU core
      Trust load : 7.88 % of one CPU core
      Baseline   : 0.42 % of one CPU core (json_decode alone)

   CWT speedup over Trust per-snapshot: 37.5x.

   Per-epoch costs (amortized hourly per operator) and per-checkpoint
   costs (amortized per witness submission) are dominated by Ed25519
   verify at ~29 us sign / ~79 us verify; at the default
   epoch = 1 hour, q = 2 witnesses, the per-epoch overhead is
   well under 1 ms per operator per epoch and is therefore
   measurement-noise relative to baseline broker operations.

   The receipt also records platform metadata (CPU, OS, Python
   version) and the iteration counts used (200 000 fast ops,
   30 000 slow ops with warmup), to permit independent reproduction.


14.2.  Embedded and LEO Vantages

   On ARM Cortex-M class devices, HMAC-SHA256 is typically available
   as a hardware primitive or as a well-optimized software routine.
   Ed25519 implementations exist but are heavier in code size and
   energy.

   CWT vantages need to:

      o  hold K_v_epoch (32 octets) for the current epoch,

      o  compute HMAC-SHA256 over canonical_payload + personalization,

      o  derive K_v_(epoch+1) at epoch boundaries.

   Memory footprint at vantage: < 1 KiB persistent state.


14.3.  Production Precedents

   The HMAC-SHA256-Personalized pattern of Section 6 is derived from
   the Tesla vehicle-command protocol, which uses the equivalent
   structure (epoch + counter + expires_at + tag) to authenticate
   safety-critical commands at scale on embedded automotive hardware.

   The witness cosignature pattern of Section 8 is derived from the
   Sigsum / tlog-witness ecosystem, whose policy
   "sigsum-generic-2025-1" (two logs, three witnesses) is in
   production use for transparency-log signatures.

   Neither precedent is reused as code; both are referenced to
   demonstrate that the underlying primitives have been deployed in
   security-critical contexts.


14.4.  Archival Mode

   For archival research, consumers MAY accept expired epochs
   provided:

      o  the OEM's ed25519_signature still verifies,

      o  the bundle checkpoint carries the original witness
         cosignatures,

      o  the consumer explicitly declares "archival" mode out of band.

   Archival mode MUST NOT feed live detectors.


15.  Security Considerations

   This entire document is security-focused.  Additional notes
   specific to CWT:

      o  K_v_epoch unforgeability reduces to HMAC-SHA256 PRF
         assumption [RFC2104].

      o  K_op compromise exposes all in-epoch K_v_epoch.  Mitigation:
         keep K_op in HSM or sealed storage; rotate every 90 days.

      o  Operator Ed25519 compromise allows manifest forgery for
         that operator.  Mitigation: witness cosignatures bind
         consumers to a checkpoint independent of the operator's
         manifest, limiting the attack to past-epoch reattribution.

      o  Witness compromise reduces the effective quorum.  Campaigns
         SHOULD set quorum q with margin (e.g., q = 2 of 5 rather
         than q = 2 of 3).

      o  Post-quantum migration: HMAC-SHA256 is widely believed to
         retain unforgeability against quantum adversaries with
         halved security margin (Grover); Ed25519 OEM and witness
         signatures are quantum-vulnerable in the long term.  A
         future PQ-MVPS-CWT revision MAY substitute post-quantum
         signature schemes at Layers 2 and 3 without changing
         Layer 1.


16.  Privacy Considerations

   OEMs and witness cosignatures may contain operator identifiers and
   ASN scope.  Publications MUST respect the redaction guidance of
   [I-D.melegassi-ippm-mvps-bundle] Section 9.  Admission tiers
   SHOULD use coarse labels in public bundles.


17.  IANA Considerations

   This document requests registration of one MVPS Bundle Capability
   Flag in the registry defined by
   [I-D.melegassi-ippm-mvps-bundle] Section 11.3:

   Flag name:  cwt-profile-v1
   Semantics:  Bundle includes mvps_cwt per snapshot, an Operator
               Epoch Manifest reference, and a witness-cosigned
               cwt_checkpoint.  Consumers MUST verify per Section 6,
               Section 7, and Section 8 before coherence computation.

   If the base registry is not yet established, implementations
   SHOULD use the string "cwt-profile-v1" in a bundle-level
   "capability_flags" array until IANA assignment.


18.  Acknowledgements

   The authors thank Joas Antonio dos Santos Barbosa for the
   security review of the MVPS bundle format that motivated this
   trust profile and for the outcome-driven red-team perspective
   that guided the choice of minimal cryptographic primitives.

   The authors acknowledge the Tesla vehicle-command protocol
   maintainers and the Sigsum / tlog-witness community whose
   production designs are the conceptual ancestors of Sections 6
   and 8 respectively.  No code from either project is incorporated
   in this specification.

   The authors thank Benoit Donnet (ULiege) for earlier
   correspondence on key-management granularity that informed the
   three-tier model.


19.  References

19.1.  Normative References

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
              Keyed-Hashing for Message Authentication", RFC 2104,
              February 1997.

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

   [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-
              Expand Key Derivation Function (HKDF)", RFC 5869,
              May 2010.

   [RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash
              Algorithms (SHA and SHA-based HMAC and HKDF)",
              RFC 6234, May 2011.

   [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
              Signature Algorithm (EdDSA)", RFC 8032, January 2017.

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

   [RFC9162]  Laurie, B., Messeri, E., and R. Stradling, "Certificate
              Transparency Version 2.0", RFC 9162, December 2021.

   [I-D.melegassi-ippm-mvps-bundle]
              Melegassi, L., "Multi-Vantage Path Snapshot (MVPS): A
              Canonical Bundle Format for Coordinated Traceroute
              Measurements", draft-melegassi-ippm-mvps-bundle-00,
              May 2026.


19.2.  Informative References

   [I-D.melegassi-santos-ippm-mvps-trust]
              Melegassi, L. and Santos, J. A., "MVPS Trust Profile:
              Authentication, Parser Safety, and Threat Model for
              Multi-Vantage Path Snapshots",
              draft-melegassi-santos-ippm-mvps-trust-00, May 2026.

   [I-D.melegassi-coherence-bfd]
              Melegassi, L., "Coherence-BFD: Sub-Second Coherence
              Detection Using Bidirectional Forwarding Detection
              Patterns", draft-melegassi-coherence-bfd-00, May 2026.

   [I-D.melegassi-ippm-mvps-coherence-leadtime]
              Melegassi, L., "Empirical Lead-Time and Zero-Day
              Predictability Profile for Multi-Vantage Path
              Coherence", draft-melegassi-ippm-mvps-coherence-
              leadtime-00, May 2026.

   [I-D.melegassi-mvps-ddos-resilience]
              Melegassi, L., "Volume-Independent DDoS Detection via
              Coherence-BFD: The MVPS DDoS Resilience Profile",
              draft-melegassi-mvps-ddos-resilience-00, May 2026.

   [I-D.melegassi-mvps-ai-coherence]
              Melegassi, L., "MVPS AI-Coherence Extension: Semantic,
              Byzantine, and Infrastructure-Cognitive Monitoring",
              draft-melegassi-mvps-ai-coherence-00, May 2026.

   [I-D.melegassi-iab-mvps-architecture]
              Melegassi, L., "MVPS Architecture: Specification
              Conformance for the Multi-Vantage Path-Coherence
              Drafts", draft-melegassi-iab-mvps-architecture-00,
              May 2026.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS)
              Protocol Version 1.3", RFC 8446, August 2018.

   [RFC9147]  Tschofenig, H. and T. Fossati, "The Datagram Transport
              Layer Security (DTLS) Protocol Version 1.3", RFC 9147,
              February 2022.

   [C2SP-TLOG-WITNESS]
              Community Cryptography Specification Project,
              "tlog-witness: A Witness Protocol for Transparency
              Logs", <https://c2sp.org/tlog-witness>.

   [C2SP-TLOG-CHECKPOINT]
              Community Cryptography Specification Project,
              "tlog-checkpoint: Checkpoint format for transparency
              logs", <https://c2sp.org/tlog-checkpoint>.

   [C2SP-TLOG-COSIGNATURE]
              Community Cryptography Specification Project,
              "tlog-cosignature: Cosignature format for transparency
              logs", <https://c2sp.org/tlog-cosignature>.

   [TESLA-VEHICLE-CMD]
              Tesla, Inc., "vehicle-command Protocol Specification",
              <https://github.com/teslamotors/vehicle-command/blob/
              main/pkg/protocol/protocol.md>, 2024.

   [TESLA]    Perrig, A., Canetti, R., Tygar, J.D., and D. Song,
              "The TESLA Broadcast Authentication Protocol",
              CryptoBytes Vol. 5, No. 2, 2002.

   [MVPS-V4]  Melegassi, L., "MVPS Mathematical Existence Proof --
              Version 4.0", Catellix technical note, May 2026.

   [MVPS-CWT-PROOF]
              Melegassi, L. and Santos, J. A., "MVPS Coherent-Witness
              Trust -- Mathematical Existence Proof", Catellix
              technical note, May 2026.


Appendix A.  JSON CWT Extension (Informative)

   Minimal CWT-wrapped snapshot (illustrative keys only):

   {
     "snapshot": {
       "destination": { "address": "203.0.113.1" },
       "end-timestamp": "2026-05-25T12:00:01Z",
       "hops": [
         { "index": 1, "address": "198.51.100.1", "rtt_ms": 1.2 }
       ],
       "path_fingerprint":
         "abc123...",
       "start-timestamp": "2026-05-25T12:00:00Z",
       "vantage-id": "v-probe-sp4-001"
     },
     "mvps_cwt": {
       "version":    1,
       "operator_id":"redteamleaders-br",
       "vantage_id": "v-probe-sp4-001",
       "epoch_id":   42,
       "counter":    17,
       "expires_at": 1779274800,
       "tag":        "base64url-32-octets..."
     }
   }


Appendix B.  Worked Verification Example

   1. Campaign publishes Admission Policy Document listing operator
      Ed25519 keys and witness Ed25519 keys (out of band).

   2. Operator generates K_op, derives per-vantage K_v_epoch for
      epoch 42, publishes Operator Epoch Manifest signed under op_sk.

   3. Vantage receives K_v_epoch via out-of-band channel
      (Section 5.1(a)).  Computes HMAC-SHA256 tag for each snapshot
      with monotonic counter.

   4. Collector aggregates snapshots into a bundle, computes Merkle
      checkpoint, submits to each of 3 witnesses via
      POST /add-checkpoint.

   5. Witnesses verify checkpoint consistency (this campaign's
      append-only history), return cosignatures.

   6. Collector publishes bundle with cwt_checkpoint containing the
      collector signature + 2 of 3 witness cosignatures (q = 2).

   7. Consumer verifies:
        (a) OEM signature under operator's op_pk,
        (b) HMAC tag of each snapshot under K_v_epoch,
        (c) counter monotonicity per (vantage_id, epoch_id),
        (d) freshness via expires_at,
        (e) checkpoint cosignatures meet q witnesses from W,
        (f) Section 10 parser limits before any of the above.

   If step 7 succeeds, snapshots feed C_1, C_2, C_3, D^2.


Appendix C.  Mathematical Core (Normative)

   This appendix states the trust-layer theorems of CWT.
   Full proofs appear in [MVPS-CWT-PROOF].  Profile-independent
   necessity theorems (T-VOID-*, T-GG-*, T-PARSE-1) are cited
   from [MVPS-CWT-PROOF] without re-statement.


C.1.  Definitions (summary)

   Verify-CWT(S) is the acceptance predicate of Section 6.4 plus the
   bundle-checkpoint quorum check of Section 8.4.  B_trusted is the
   bundle content after all snapshots and the bundle checkpoint pass
   Verify-CWT.  Admitted set A, Byzantine count f, gauge-gap witness
   (P1, P2), witness anchor set W with quorum q are as in
   [MVPS-CWT-PROOF] Section 1.


C.2.  Authentication theorems

   THEOREM T-AUTH-CWT-1 (Origin authentication soundness).
      Under HMAC-SHA256 PRF security [RFC2104] and Ed25519 EUF-CMA
      [RFC8032] on the OEM, Verify-CWT(S) = ACCEPT implies the
      snapshot was produced by an entity holding K_v_epoch for the
      claimed (vantage_id, epoch_id), and that K_v_epoch was bound
      to vantage_id by a current OEM signed by the operator, except
      with negligible probability.

   THEOREM T-AUTH-CWT-2 (Honest completeness).
      A correctly tagged honest snapshot under a valid OEM, with
      monotonic counter and live expires_at, is accepted by
      Verify-CWT.


C.3.  Impossibility without authentication (NECESSITY)

   THEOREM T-VOID-1 (see [MVPS-CWT-PROOF] Section 3).
   THEOREM T-VOID-2 (see [MVPS-CWT-PROOF] Section 3).
   THEOREM T-VOID-3 (see [MVPS-CWT-PROOF] Section 3).
   THEOREM T-VOID-4 (see [MVPS-CWT-PROOF] Section 3).

   These NECESSITY theorems are profile-independent: they show
   what fails in any unauthenticated MVPS deployment.


C.4.  Gauge-gap theorems

   THEOREM T-GG-1 (see [MVPS-CWT-PROOF] Section 2).
   THEOREM T-GG-2 (see [MVPS-CWT-PROOF] Section 2).
   THEOREM T-GG-3 (see [MVPS-CWT-PROOF] Section 2).


C.5.  Composition with MVPS v4.0 (SUFFICIENCY)

   THEOREM T-COMP-1-CWT.
      Under H-TRUST-CWT, H-ADM, H-WIT, and f < N/2, [MVPS-V4]
      Theorem 9 (geometric-median max-bias on C_2) applies to
      B_trusted.

   THEOREM T-COMP-2-CWT.
      Under H-TRUST-CWT, H-ADM, H-WIT, f < N/2, and MVPS-A4, the
      full v4.0 catalogue and the Architecture Invariance Theorem of
      [I-D.melegassi-iab-mvps-architecture] apply unchanged to
      B_trusted.


C.6.  Coalition and Split-View theorems (CWT-specific)

   THEOREM T-COAL-1 (Coalition resistance via witness independence).
      Let an adversary control a coalition of operators with
      combined admitted vantage mass f' >= N/2.  Suppose:
         (i)  the witness anchor set W contains w >= 3 independent
              witnesses,
         (ii) no organizational entity controls more than
              floor(w/2) witnesses,
         (iii) quorum q >= 2 is enforced.
      Then any bundle whose contents reflect the coalition's poison
      is detected by an external auditor querying any honest witness
      within one checkpoint window.  Equivalently: T-COMP-1-CWT
      holds with effective f_effective = (f' - witness_correction)
      < N/2 from the auditor's perspective.

   THEOREM T-SPLIT-1 (Split-view resistance via cosignature quorum).
      Let a malicious collector hold a valid collector key.  Under
      q >= 2 and witness independence, any two consumers receiving
      "the same" bundle (matching bundle_id, bundle_seq) will obtain
      identical root_hash values when at least one honest witness
      participates in the cosignature, except with negligible
      probability.  Equivalently: collector split-view is detectable
      with probability at least 1 - (1 - 1/w)^q for q honest
      cosignatures of w witnesses.


C.7.  Parser and replay

   THEOREM T-PARSE-1 (see [MVPS-CWT-PROOF] Section 6).

   THEOREM T-REPLAY-1-CWT.
      Strictly monotonic per-(vantage_id, epoch_id) counter combined
      with per-snapshot expires_at field rejects byte-identical
      replay and rejects beyond-window stale replay, using only
      O(N) consumer state per active epoch.


C.8.  Designs and conjectures (not theorems)

   Design D-CWT-ROT: key rotation cadence (Section 5.5).

   Design D-CWT-DLY: delayed-key disclosure (TESLA-style; Section
   5.1(b)) trades real-time verification for public auditability.

   Conjecture CONJ-CWT-A4: witness diversity restores approximate
   conditional independence (MVPS-A4) of vantage observations.
   EMPIRICAL.


C.9.  Numerical receipt

   Constructive witnesses for T-AUTH-CWT-1, T-AUTH-CWT-2, T-COAL-1,
   T-SPLIT-1, T-COMP-1-CWT, T-REPLAY-1-CWT, T-VOID-*, T-GG-*,
   and T-PARSE-1 are validated by scripts/validate_cwt_theorems.py
   (12/12 PASS).  Implementations SHOULD run this script in CI
   alongside scripts/validate_v4_against_all_attacks.py.


Authors' Addresses

   Leonardo Melegassi
   Catellix
   Andradina, SP
   Brazil

   Email: melegassi@catellix.com
   URI:   https://catellix.com/


   Joas Antonio dos Santos Barbosa
   RedTeamLeaders
   Brazil

   Email: joasantonio108@gmail.com
