Verification Defect Quarantine for Protocol Conformance Systems

Introduction 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.

Requirements Language 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 when, and only when, they appear in all capitals.

Terminology

Subject: The specification, implementation, vector set, or release candidate being evaluated.
Verifier: The implementation that executes the registered verification procedure.
Normative Vector: A test vector whose result is required for a declared conformance profile.
Counterexample Witness: A self-contained input and derivation sufficient to demonstrate that a claimed normative expectation cannot hold under the declared preconditions.
Quarantine: 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.
Subject Status: The result concerning the tested subject: PASS, FAIL, INDETERMINATE, DEFECT_REPORTED, or DEFECT_REPRODUCED.
Verifier Status: The result concerning the verifier's behavior: PASS, FAIL, INDETERMINATE, or DETECTION_PASS.

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 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.

Defect Classes VDQ defines the following defect classes:

PRECONDITION_DEFECT: A published input violates a precondition required by the specification, such as an elliptic-curve point that is not on the declared curve.
VECTOR_MISMATCH: The published expected value is inconsistent with the declared operation or invariant.
AMBIGUOUS_SPECIFICATION: More than one materially different interpretation remains possible because required semantics are missing or ambiguous.
UNSUPPORTED_EXPECTATION: The vector contains an expected value without a reproducible derivation or binding to the declared algorithm.
IMPLEMENTATION_FAILURE: The specification and vector are usable, but the implementation under test fails the declared expectation.
INDETERMINATE: Available evidence is insufficient to decide whether the defect lies in the subject, verifier, environment, or specification.

Verification Defect Quarantine Receipt 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 before computing receipt digests. A receipt MAY be registered in a transparency service such as the architecture described by . 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.

Evaluation Algorithm

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.

Arithmetic Counterexample Profile 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 ; 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.

Relationship to Verification Promotion Verification Promotion Boundaries (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.

Relationship to RFC Errata and Working Documents 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.

High-Assurance Deployment Considerations 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.

Conformance and Falsification 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.

Security Considerations 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.

Privacy Considerations 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.

IANA Considerations This document has no IANA actions.