| Internet-Draft | Verification Defect Quarantine | October 2026 |
| Watts | Expires 17 April 2027 | [Page] |
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.¶
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 17 April 2027.¶
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.¶
Conformance testing normally assumes that the expected value, invariant, or state transition encoded by a test vector is correct. That assumption is operationally dangerous when the vector itself is defective. A verifier that correctly rejects an invalid vector can appear non-conformant, while an implementation that reproduces the defective value can appear conformant.¶
This document defines a narrow profile for that failure mode. A VDQ implementation maintains separate state for the tested subject and for the verifier. 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 two conclusions MUST NOT be collapsed into one another.¶
VDQ is intended to compose with protocol-specific conformance suites, verification-promotion systems, transparency services, and release gates. It is especially useful where a conformance result can influence deployment, acquisition, authorization, or safety decisions.¶
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.¶
The specification, implementation, vector set, or release candidate being evaluated.¶
The implementation that executes the registered verification procedure.¶
A test vector whose result is required for a declared conformance profile.¶
A self-contained input and derivation sufficient to demonstrate that a claimed normative expectation cannot hold under the declared preconditions.¶
A state that prevents an affected vector, section, profile, or release from being used to justify a stronger assurance claim until the defect is resolved, superseded, or explicitly scoped out by the relying party.¶
The result concerning the tested subject: PASS, FAIL, INDETERMINATE, DEFECT_REPORTED, or DEFECT_REPRODUCED.¶
The result concerning the verifier's behavior: PASS, FAIL, INDETERMINATE, or DETECTION_PASS.¶
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 or complete.¶
A local defect report does not equal independent reproduction.¶
A VDQ receipt does not amend an Internet-Draft or RFC and does not constitute RFC errata verification.¶
INDETERMINATE does not equal PASS.¶
VDQ defines the following defect classes:¶
A published input violates a precondition required by the specification, such as an elliptic-curve point that is not on the declared curve.¶
The published expected value is inconsistent with the declared operation or invariant.¶
More than one materially different interpretation remains possible because required semantics are missing or ambiguous.¶
The vector contains an expected value without a reproducible derivation or binding to the declared algorithm.¶
The specification and vector are usable, but the implementation under test fails the declared expectation.¶
Available evidence is insufficient to decide whether the defect lies in the subject, verifier, environment, or specification.¶
A VDQ receipt is a machine-readable, non-bearer evidence object. It MUST identify the subject artifact and digest, vector identifier, whether the vector is normative, defect class, subject status, verifier status, quarantine scope, promotion-block state, counterexample witness, evidence digest, and creation time.¶
Interoperable JSON receipts SHOULD use the JSON Canonicalization Scheme [RFC8785] before computing receipt digests. A receipt MAY be registered in a transparency service such as the architecture described by [RFC9943]. Transparency proves inclusion of a statement; it does not prove that the statement is true.¶
The receipt is evidence about a conformance dispute. Possession of the receipt MUST NOT confer authorization, deployment approval, standards status, or patent rights.¶
Validate syntax, subject digest, vector identifier, and registered verification procedure.¶
Determine whether the vector is normative for the requested conformance profile.¶
Evaluate specification preconditions before comparing implementation output with the expected value.¶
If a precondition or expected value is contradicted by a reproducible counterexample, set VerifierStatus to DETECTION_PASS and SubjectStatus to DEFECT_REPORTED or DEFECT_REPRODUCED according to the registered independence requirements.¶
If the affected vector is normative, set QuarantineScope to at least VECTOR and set PromotionBlocked to true.¶
If the vector is usable and the implementation fails it, set SubjectStatus to FAIL without quarantining the specification.¶
If the defect cannot be reproduced or attribution is uncertain, preserve INDETERMINATE and block any assurance promotion that depends on the disputed vector.¶
When a later revision corrects or supersedes the vector, issue a new receipt that references the predecessor. Historical receipts MUST NOT be silently rewritten.¶
For finite-field and elliptic-curve vectors, a VDQ verifier MUST validate the declared field, curve discriminant, point-membership preconditions, and subgroup assumptions before executing higher-level group identities. Fundamental elliptic-curve arithmetic and validation are established by [RFC6090]; VDQ does not define new elliptic-curve cryptography.¶
A point (x,y) claimed to lie on a short-Weierstrass curve y^2 = x^3 + ax + b modulo p is defective as a test input if the two sides are unequal modulo p. The resulting modular values form a compact counterexample witness.¶
Passing arithmetic fixtures demonstrates only the registered arithmetic relation. It MUST NOT be treated as evidence of authorization, identity, security, empirical truth, or standards endorsement.¶
Verification Promotion Boundaries (VPB) [I-D.watts-vpb] separates specification validation, local conformance, independent reproduction, security testing, and release eligibility. VDQ supplies a narrower receipt for a specific VPB failure mode: the expected conformance oracle is itself defective.¶
A VDQ quarantine state MUST block promotion through any stage that requires the affected normative vector. The verifier MAY record DETECTION_PASS for the specific fault, but that status MUST NOT satisfy a higher assurance stage by itself.¶
The RFC Editor maintains an errata process for published RFCs. Test-vector and technical errors have occurred in published RFCs, demonstrating that conformance oracles can themselves require correction. VDQ is not a replacement for that process. A VDQ receipt can accompany an errata report, implementation report, or Internet-Draft issue, but only the applicable document process can change or formally classify the specification.¶
For Internet-Drafts, a VDQ finding is evidence for the author and community to evaluate in a later revision. It does not create IETF consensus or endorsement.¶
Organizations using conformance results for procurement, deployment, authorization, or release SHOULD require that normative-vector defects be quarantined rather than accepted as passing evidence. High-assurance profiles MAY require independent reproduction before DEFECT_REPORTED is elevated to DEFECT_REPRODUCED.¶
The current NIST AI Agent Standards Initiative emphasizes secure and interoperable agent protocols and open standards development. VDQ can support such assurance programs by preventing a defective expected value from becoming a false positive in release or acquisition testing. This statement does not imply NIST or U.S. Government endorsement.¶
A VDQ implementation claiming conformance MUST reproduce the companion positive and negative vectors. A conforming implementation MUST NOT report PASS for a normative vector whose declared preconditions are contradicted by a registered reproducible counterexample. It MUST NOT interpret a local defect report as independent reproduction. It MUST NOT clear a quarantine state merely because an implementation reproduces the defective expected value.¶
The profile is directly falsifiable. A counterexample to VDQ itself is any case in which the reference algorithm promotes a subject despite a normative reproducible defect, silently converts INDETERMINATE to PASS, or changes historical defect evidence without an explicit superseding record.¶
Attackers can exploit conformance pipelines by substituting expected values, suppressing negative vectors, altering provenance, using the implementation under test to generate its own oracle, or treating a disputed vector as authoritative after a defect is known. Implementations SHOULD bind vector sets, procedures, source artifacts, and reports to cryptographic digests and SHOULD separate test generation from the implementation under test.¶
Quarantine can also be abused to cause denial of service. A deployment SHOULD therefore distinguish local reports from independently reproduced defects and SHOULD scope quarantine to the smallest justified unit. High-impact decisions MAY require human review before release-wide quarantine.¶
A DETECTION_PASS is narrow evidence of one demonstrated fault-detection capability. It is not a security certification.¶
Defect receipts can disclose internal build identifiers, source locations, implementation digests, or security weaknesses. Deployments SHOULD minimize unnecessary disclosure and MAY publish a redacted receipt that preserves the counterexample and artifact digest while withholding sensitive operational context.¶
This document has no IANA actions.¶