Operations and Management Area L. Melegassi Internet-Draft Catellix Intended status: Standards Track 28 May 2026 Expires: 29 November 2026 The MVPS Operational Log Format: Append-Only, Hash-Chained, Externally-Anchored Audit Logs draft-melegassi-opsawg-mvps-logging-00 Abstract Multi-Vantage Path Snapshot (MVPS) deployments run in critical environments where the operational record must be auditable: an investigator, regulator, or independent witness must be able to detect any after-the-fact alteration of what the system observed and did. This document specifies the MVPS operational log format: an append-only stream of structured records, each cryptographically chained to its predecessor, with completeness guaranteed by an external anchor reusing the Coherent-Witness Trust (CWT) checkpoint and the MVPS Proof Envelope. The format guarantees that recorded events cannot be silently edited, reordered, or interior-deleted, and -- once a head is anchored -- that the exact log prefix is pinned and tail truncation is exposed. The document is explicit about the limits: a bare hash chain cannot prove its own completeness (an anchor is REQUIRED); the chain is binding, not confidential. Every property is validated by scripts/validate_logging_format.py (8/8 PASS, exit 0) and recorded in evidence/logging_format_receipt.json. 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 29 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Relationship to CWT and the Proof Envelope . . . . . . . 3 1.2. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Log Record Format . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Canonical Encoding and the Leaf Hash . . . . . . . . . . 5 3.2. The Chain Link . . . . . . . . . . . . . . . . . . . . . 6 3.3. Event Taxonomy and Severity . . . . . . . . . . . . . . . 6 4. Verification Procedure . . . . . . . . . . . . . . . . . . . 7 5. External Anchoring (REQUIRED for completeness) . . . . . . . 8 6. Redaction . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Tamper-Evidence Properties . . . . . . . . . . . . . . . . . 9 8. Numerical Receipt . . . . . . . . . . . . . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 11.2. Informative References . . . . . . . . . . . . . . . . . 12 Appendix A. Worked Example . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction MVPS is deployed where the cost of an undetected lie about the past is high: critical infrastructure, regulated networks, contested environments. In such settings the operational log is not a debugging convenience; it is evidence. An evidence log must satisfy one property above all: any alteration of the recorded past is DETECTABLE by a party who did not write it. This document specifies that log. Records are append-only and hash-chained (each commits to the digest of its predecessor), so the head digest is a binding commitment to the entire ordered history. Completeness -- the guarantee that no tail was dropped -- is provided by anchoring the head externally, reusing machinery the MVPS family already defines. 1.1. Relationship to CWT and the Proof Envelope The Coherent-Witness Trust draft [I-D.melegassi-santos-ippm-mvps-cwt] defines a per-coordination-window Merkle checkpoint and a witness cosignature surface, but explicitly states it is NOT a long-running append-only log. This document is that log. It REUSES the CWT checkpoint as one anchor target and the MVPS Proof Envelope [I-D.melegassi-ippm-mvps-proof-envelope] as another: a periodic log head MAY be bound as an artifact in an envelope manifest, inheriting the envelope's tamper-evidence and optional post-quantum anchor. 1.2. Scope and Non-Goals This document specifies: o the record format and its canonical encoding, o the chain link and head computation, o the verification procedure, o the external-anchor requirement for completeness, o a redaction mechanism compatible with verification. This document does NOT: o provide confidentiality (the chain is binding, not hiding; Section 6 and Section 9); o guarantee completeness without an anchor (impossible; Section 5, Section 7); o define a transport; records MAY be shipped over syslog [RFC5424], files, or any ordered channel. 2. Terminology Record: one log entry (Section 3). Leaf hash: SHA-256 over the canonical record body with the record_hash field removed. Chain link: the field prev_hash of record i equals the record_hash of record i-1 (or GENESIS = 64 zero hex digits for i = 0). Head: the record_hash of the last record (GENESIS if empty). Anchor: a (head_hash, count) pair published through an external, witnessed channel (a CWT checkpoint or a Proof Envelope manifest). The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "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. 3. Log Record Format A record is a structured object with the following top-level fields: seq unsigned integer, contiguous from 0, MUST equal the record's position; prev_hash 64 hex digits (SHA-256 of the previous leaf, or GENESIS for seq 0); ts RFC 3339 UTC timestamp of record creation; event an open structured payload (Section 3.3); record_hash 64 hex digits, the leaf hash of this record. 3.1. Canonical Encoding and the Leaf Hash The leaf hash is computed over the canonical JSON [RFC8785] encoding of the record with the record_hash field removed: leaf(r) = SHA-256( JCS( r without "record_hash" ) ) Canonicalization makes the digest independent of key insertion order; two encoders MUST agree on the leaf hash. A CBOR profile [RFC8949] MAY be used on constrained links using CBOR deterministic encoding. 3.2. The Chain Link For seq 0, prev_hash MUST be GENESIS. For seq i >= 1: prev_hash_i = record_hash_{i-1} record_hash_i = leaf(r_i) The head after n records is record_hash_{n-1}. By linked timestamping [HS91] the head is a binding commitment to the entire ordered prefix under SHA-256 collision resistance. 3.3. Event Taxonomy and Severity The event payload SHOULD carry: kind a dotted taxonomy token, e.g. "vantage.join", "bundle.observe", "alarm.raise", "vantage.byzantine", "anchor.checkpoint"; sev one of debug, info, notice, warn, error, audit. Records with sev = "audit" MUST be retained for the deployment's full retention period and MUST be covered by at least one anchor. 4. Verification Procedure A verifier accepts a log L = (r_0, ..., r_{n-1}) iff, for every i: 1. seq_i == i; 2. prev_hash_i == (GENESIS if i == 0 else record_hash_{i-1}); 3. record_hash_i == leaf(r_i). Any failure localizes the first altered position. Verification is O(n) hashes and requires no secret. 5. External Anchoring (REQUIRED for completeness) A bare chain proves internal consistency but CANNOT prove it has not been truncated at the tail: any prefix of a valid log is itself a valid log (Section 7, T-LOG-TRUNC-1). Therefore: o Operators MUST publish anchors a = (head_hash, count) at a chosen cadence (per N records or per T seconds). o An anchor SHOULD be a CWT checkpoint [I-D.melegassi-santos-ippm-mvps-cwt] (witness-cosigned) or a Proof Envelope manifest entry [I-D.melegassi-ippm-mvps-proof-envelope]. o Completeness is guaranteed only up to the most recently anchored head. Records after the last anchor enjoy edit/reorder/delete evidence but not truncation evidence. Given an anchor, a verifier rejects any log whose head or count disagrees, exposing truncation and rollback. 6. Redaction To remove a sensitive value v while keeping the record verifiable, a writer MAY replace v with a salted commitment: c = SHA-256( salt || v ) retaining salt in the record. The leaf hash is computed over the committed form, so verification is unchanged and the record stays in the chain. A holder of v reproduces c; a party without v learns only c. This is BINDING, not hiding: it is not encryption and provides no confidentiality guarantee in the IND sense (Section 9). 7. Tamper-Evidence Properties The following are proved in the companion (docs/MVPS_LOGGING_PROOF.txt) and validated by scripts/validate_logging_format.py: T-LOG-CHAIN-1 a well-formed chain verifies end to end; T-LOG-EDIT-1 editing any record's payload breaks the chain; T-LOG-REORDER-1 reordering two records breaks the chain; T-LOG-DELETE-1 deleting an interior record breaks the chain; T-LOG-TRUNC-1 tail truncation is NOT self-detectable; it is detectable with an external anchor; T-LOG-ANCHOR-1 an anchor (head_hash, count) binds the exact prefix; T-LOG-CANON-1 canonical encoding is key-order independent; T-LOG-REDACT-1 salted redaction preserves the commitment. Each reduces to SHA-256 collision resistance and linked timestamping [HS91], plus witness EUF-CMA [RFC9162] for the anchor. 8. Numerical Receipt scripts/validate_logging_format.py builds a five-record log, exercises each tamper class, and writes evidence/logging_format_receipt.json with the demo head digest, platform metadata, severity vocabulary, anchor targets, the explicit non-claims, and a SHA-256 of its own canonical body. At time of writing all eight checks PASS (exit 0). 9. Security Considerations The log provides tamper-EVIDENCE, not tamper-PREVENTION: an attacker with write access can still destroy the file, but cannot do so silently once a head has been anchored (Section 5). Operators MUST anchor at a cadence matched to their threat model; the window between anchors is the maximum silently-truncatable tail. The chain is not confidential. Sensitive fields MUST be redacted (Section 6) or the whole transport encrypted; the commitment scheme provides binding only. Quantum considerations follow the Proof Envelope [I-D.melegassi-ippm-mvps-proof-envelope]: SHA-256 retains a halved (Grover) preimage margin of 2^128, which is finite and sufficient; anchors MAY migrate to a post-quantum witness signature without changing any record on the wire. 10. IANA Considerations This document requests no IANA actions. The event "kind" taxonomy is an open, deployment-defined namespace; a later revision MAY request a registry if interoperability requires it. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, June 2020. [RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, December 2021. 11.2. Informative References [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, December 2020. [HS91] Haber, S. and W. Stornetta, "How to Time-Stamp a Digital Document", Journal of Cryptology 3(2), 1991. [I-D.melegassi-santos-ippm-mvps-cwt] Melegassi, L. and J. Santos, "MVPS Coherent-Witness Trust", draft-melegassi-santos-ippm-mvps-cwt-00, 2026. [I-D.melegassi-ippm-mvps-proof-envelope] Melegassi, L., "MVPS Proof Envelope", draft-melegassi- ippm-mvps-proof-envelope-00, 2026. Appendix A. Worked Example Five records (vantage.join, bundle.observe, alarm.raise, anchor.checkpoint, vantage.byzantine) chained from GENESIS produce a head digest reproduced exactly by the validator. Editing the alarm.raise record's d2 value from 38.7 to 0.0 causes verification to fail at seq 2, demonstrating T-LOG-EDIT-1. The full transcript is the output of scripts/validate_logging_format.py. Author's Address Leonardo Melegassi Catellix Brazil Email: melegassi@catellix.com