Network Working Group D. O. Watts Internet-Draft GoodShyt Group Inc. Intended status: Informational 14 October 2026 Expires: 14 April 2027 Verification Defect Quarantine for Protocol Conformance Systems draft-watts-verification-defect-quarantine-00 Abstract Protocol conformance systems commonly treat a published test vector as an oracle. When the oracle itself is malformed, internally inconsistent, ambiguous, or arithmetically false, an implementation can be penalized for rejecting the defect or can be falsely promoted for reproducing it. This document defines Verification Defect Quarantine (VDQ), a transport-neutral receipt and fail-closed state model for separating the status of the tested subject from the demonstrated fault-detection behavior of the verifier. VDQ records reproducible counterexamples, quarantines affected normative vectors from assurance promotion, preserves INDETERMINATE when a defect cannot yet be reproduced, and supports append-only supersession when a specification is corrected. VDQ does not amend an Internet-Draft or RFC, does not replace the RFC Editor errata process, and does not by itself establish implementation security. 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at https://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at https://www.ietf.org/shadow.html This Internet-Draft will expire on 14 April 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Introduction Conformance testing normally assumes that the expected value, invariant, or state transition encoded by a test vector is correct. That assumption is dangerous when the vector itself is defective. VDQ keeps two states separate: SubjectStatus != VerifierStatus A reproducible defect in a normative vector is negative evidence about use of that vector as a conformance oracle. The same event can be positive evidence that the verifier detected the specific defect. These conclusions MUST NOT be collapsed into one another. 2. Requirements Language The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals. 3. Terminology Subject: the specification, implementation, vector set, or release candidate being evaluated. Verifier: the implementation executing the registered verification procedure. Counterexample Witness: self-contained inputs and derivation sufficient to show that a claimed normative expectation cannot hold under the declared preconditions. Quarantine: a state preventing an affected vector, section, profile, or release from being used to justify stronger assurance until resolved. 4. Non-Collapse Principles A failing normative vector does not by itself prove an implementation defect. Detecting a defective normative vector does not make the tested subject conformant. Detecting one defect does not certify the verifier as secure. A local report is not independent reproduction. INDETERMINATE is not PASS. 5. Defect Classes PRECONDITION_DEFECT, VECTOR_MISMATCH, AMBIGUOUS_SPECIFICATION, UNSUPPORTED_EXPECTATION, IMPLEMENTATION_FAILURE, and INDETERMINATE. 6. Verification Defect Quarantine Receipt A VDQ receipt is a machine-readable, non-bearer evidence object. It records the subject digest, vector, defect class, separate subject and verifier states, quarantine scope, promotion-block state, reproducible counterexample witness, and evidence digest. 7. Evaluation Algorithm 1. Validate syntax, provenance, and the registered procedure. 2. Determine whether the vector is normative. 3. Validate specification preconditions before comparing outputs. 4. A reproducible normative defect yields DETECTION_PASS for the verifier and DEFECT_REPORTED or DEFECT_REPRODUCED for the subject. 5. The affected normative vector is quarantined from promotion. 6. A valid vector failed by the implementation yields subject FAIL. 7. Unresolved attribution remains INDETERMINATE and cannot promote. 8. Corrections supersede earlier receipts; history is not rewritten. 8. Arithmetic Counterexample Profile For elliptic-curve vectors, a verifier validates the field, curve discriminant, point membership, and subgroup preconditions before executing higher-level group identities. A claimed point (x,y) on y^2 = x^3 + ax + b mod p is defective when the two sides differ modulo p. Passing arithmetic fixtures demonstrates only the registered arithmetic relation and does not establish identity, authorization, security, or standards endorsement. 9. Relationship to Verification Promotion Verification Promotion Boundaries separates specification validation, local conformance, independent reproduction, security testing, and release eligibility. VDQ supplies a narrower receipt for a defective conformance oracle. Quarantine blocks any promotion that depends on the affected normative vector. 10. Relationship to RFC Errata The RFC Editor maintains the errata process for published RFCs. VDQ does not replace that process. A VDQ receipt may accompany an errata report or Internet-Draft issue, but only the applicable document process can formally classify or change the specification. 11. High-Assurance Deployment Considerations Organizations using conformance results for procurement, deployment, authorization, or release should quarantine defective normative vectors rather than accept them as passing evidence. High-assurance profiles may require independent reproduction before a defect is treated as reproduced. 12. Security Considerations Attackers can substitute expected values, suppress negative vectors, alter provenance, generate expected results with the implementation under test, or continue using a vector after a defect is known. VDQ implementations should bind vectors, procedures, source artifacts, and reports to cryptographic digests. Quarantine can itself be abused for denial of service, so scope should be no broader than justified. 13. IANA Considerations This document has no IANA actions. 14. References RFC 2119, RFC 8174, RFC 8785, RFC 6090, RFC 9943, the RFC Editor Errata system, NIST AI Agent Standards Initiative, and draft-watts-verification-promotion-boundaries-00. Author's Address Deonte O'dell Watts GoodShyt Group Inc. San Francisco, CA, US Email: deonte@goodshyt.fun ORCID: 0009-0005-8586-3650