| Internet-Draft | Verification Promotion Boundaries | October 2026 |
| Watts | Expires 17 April 2027 | [Page] |
Protocol implementations frequently combine specification checks, deterministic test vectors, security testing, independent reproduction, and release decisions. A common failure mode is evidence collapse: a result at one assurance level is silently treated as sufficient for a stronger conclusion. This document defines Verification Promotion Boundaries (VPB), a machine-readable profile and state-transition procedure that separates specification validation, local conformance, independent reproduction, authorized security testing, and release eligibility. VPB also defines dual-state handling for specification defects: detecting a bad normative vector is negative evidence about the tested subject but may be positive fault-detection evidence about the verifier. Unknown evidence never promotes. This document does not define a new cryptographic primitive, authorization protocol, or IETF certification program.¶
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.¶
Protocol research often moves through several evidence classes: a document is written, an implementation passes local vectors, another implementation reproduces the result, security testing is performed, and a human release authority decides whether deployment is appropriate. These states are not interchangeable.¶
VPB formalizes the non-collapse rule: a result produced for one assurance class MUST NOT be represented as satisfying a stronger assurance class unless evidence required by the stronger class is present. The profile is designed for laboratories that validate portfolios of related Internet-Drafts or experimental protocol specifications, but it is protocol-neutral.¶
A motivating case is arithmetic conformance. A verifier can correctly reject a published elliptic-curve point that does not satisfy the declared curve equation. That outcome is a failure of the tested vector, not a failure of the verifier. VPB therefore keeps subject status separate from verifier-evidence status.¶
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, build, or release candidate being evaluated.¶
The implementation that executes a declared verification procedure.¶
A transition to a stronger assurance stage.¶
A reproducible finding that a published expected value or normative test input is inconsistent with the specification it is intended to represent.¶
A reproduction performed by a producer and implementation distinct from the producer and implementation whose local result is being reproduced.¶
VPB defines the following ordered stages: REGISTERED, SPEC_VALIDATED, LOCAL_CONFORMANT, INDEPENDENTLY_REPRODUCED, SECURITY_TESTED, and RELEASE_ELIGIBLE.¶
REGISTERED means only that the subject and its digests are known. SPEC_VALIDATED means required specification preconditions and vector definitions are internally consistent. LOCAL_CONFORMANT means the declared local conformance suite passed in a characterized environment. INDEPENDENTLY_REPRODUCED requires a distinct producer and implementation to reproduce the registered result. SECURITY_TESTED additionally requires authorized penetration testing and fault injection. RELEASE_ELIGIBLE additionally requires signed provenance, no unresolved high-severity finding, and explicit human approval.¶
No stage implies a later stage. A relying party MUST NOT infer independent reproduction from a local PASS, or production readiness from independent reproduction.¶
Each required check has one outcome: PASS, SUBJECT_FAIL, SPEC_VECTOR_FAIL, INDETERMINATE, INTEGRITY_FAIL, or ENVIRONMENT_FAIL.¶
INDETERMINATE MUST NOT be interpreted as PASS. INTEGRITY_FAIL terminates evaluation of the affected receipt. SPEC_VECTOR_FAIL blocks conformance promotion of the subject.¶
A verifier that reports SPEC_VECTOR_FAIL has made a negative claim about the tested subject. If the defect is independently reproducible, the same event MAY be recorded as SPECIFICATION_DEFECT_DETECTED in the verifier's evidence ledger.¶
This rule prevents a useful failure from being flattened into a generic test failure. The subject remains blocked. The verifier gains only evidence of the specific demonstrated fault-detection capability. It does not gain independent-reproduction, security, release, or certification status.¶
Formally, SubjectState and VerifierEvidenceState are separate variables. A transition in one MUST NOT implicitly change the other.¶
A VPB receipt is a JSON object. Implementations MUST use RFC 8785 canonicalization before computing interoperable receipt digests [RFC8785]. SHA-256 MAY be used for content digests as specified in [RFC6234].¶
The receipt contains a profile identifier, receipt identifier, subject identifier and digest, verification-procedure digest, vector-set digest, environment digest, producer identifier, requested promotion stage, per-check outcomes, independence assertions, security-testing assertions, human approval, signed-provenance state, unresolved-high-severity count, and predecessor-receipt digests.¶
The JSON representation MUST conform to the companion schema for this profile. Unknown or omitted required evidence MUST fail closed for the requested promotion.¶
Validate the receipt syntax and canonical form.¶
If any integrity check fails, return INTEGRITY_FAIL and grant no promotion.¶
If required evidence is unknown, including an unknown environment, return INDETERMINATE and grant no promotion.¶
If any required check is SUBJECT_FAIL, SPEC_VECTOR_FAIL, or ENVIRONMENT_FAIL, block subject promotion. A SPEC_VECTOR_FAIL MAY additionally create verifier evidence as described in Section 6.¶
Grant LOCAL_CONFORMANT only if every required registered check is PASS.¶
Grant INDEPENDENTLY_REPRODUCED only when the reproducing producer and implementation are distinct from the original producer and implementation.¶
Grant SECURITY_TESTED only when both authorized penetration testing and fault injection are complete.¶
Grant RELEASE_ELIGIBLE only when signed provenance is complete, unresolved high-severity findings equal zero, and a human release authority explicitly approves.¶
A VPB implementation claiming conformance MUST reproduce the normative results in the companion test-vector set. The vectors include local PASS without independent reproduction, specification-vector failure, unknown environment, insufficient independence, missing fault injection, missing human approval, unresolved high-severity findings, and integrity failure.¶
The core falsifiers are direct. If a local PASS is promoted to INDEPENDENTLY_REPRODUCED without independent evidence, the implementation is non-conformant. If SPEC_VECTOR_FAIL is treated as subject conformance, it is non-conformant. If INDETERMINATE is promoted as PASS, it is non-conformant.¶
RFC 9943 defines a transparency architecture for signed statements and receipts [RFC9943]. VPB does not replace transparency services or receipt cryptography; it defines promotion semantics across verification stages.¶
The Correctover Runtime Verification Receipt Internet-Draft specifies a receipt for runtime verification of agent tool invocations [I-D.ccs]. VPB addresses a different lifecycle question: what evidence is sufficient to promote a subject from one verification stage to another.¶
Revocation-closure work defines when invalidated authority is no longer usable across declared paths [I-D.watts-closure]. VPB does not define revocation closure; it defines when verification evidence may support stronger assurance claims.¶
Expected outputs MUST NOT be generated solely by the implementation under test. Security-critical vectors SHOULD be derived or checked by an independent oracle or independent implementation.¶
Receipt integrity authenticates bytes, not truth. A signed receipt can preserve an incorrect conclusion. Consumers must evaluate the procedure, vector provenance, independence class, and environment.¶
This profile does not authorize penetration testing against third-party systems. Internet-Draft conformance is not IETF certification, standards adoption, patent validity, or production-security assurance.¶
This document does not assert patentability, priority, freedom to operate, or ownership of established algorithms. IETF participants remain responsible for applicable IPR disclosure obligations under BCP 79 [RFC8179]. Technical novelty and patentability analysis belongs outside the normative conformance result.¶
This document has no IANA actions.¶