Network Working Group D. O. Watts Internet-Draft GoodShyt Group Inc. Intended status: Informational 14 October 2026 Expires: 14 April 2027 Verification Promotion Boundaries for Protocol Implementations draft-watts-verification-promotion-boundaries-00 Abstract 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. 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. Table of Contents 1. Introduction 2. Requirements Language 3. Terminology 4. Promotion Stages 5. Verification Outcomes 6. Dual Subject and Verifier Evidence 7. VPB Receipt 8. Promotion Algorithm 9. Conformance and Falsification 10. Relationship to Existing Work 11. Security Considerations 12. IPR and Research Claims 13. IANA Considerations 14. References Author's Address 1. Introduction 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. 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals. 3. Terminology Subject: The specification, implementation, vector set, build, or release candidate being evaluated. Verifier: The implementation that executes a declared verification procedure. Promotion: A transition to a stronger assurance stage. Specification Vector Failure: A reproducible finding that a published expected value or normative test input is inconsistent with the specification it is intended to represent. Independent Reproduction: A reproduction performed by a producer and implementation distinct from the producer and implementation whose local result is being reproduced. 4. Promotion Stages 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. 5. Verification Outcomes 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. 6. Dual Subject and Verifier Evidence 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. 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. SubjectState and VerifierEvidenceState are separate variables. A transition in one MUST NOT implicitly change the other. 7. VPB Receipt 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. 8. Promotion Algorithm 1. Validate the receipt syntax and canonical form. 2. If any integrity check fails, return INTEGRITY_FAIL and grant no promotion. 3. If required evidence is unknown, including an unknown environment, return INDETERMINATE and grant no promotion. 4. If any required check is SUBJECT_FAIL, SPEC_VECTOR_FAIL, or ENVIRONMENT_FAIL, block subject promotion. 5. Grant LOCAL_CONFORMANT only if every required registered check is PASS. 6. Grant INDEPENDENTLY_REPRODUCED only when the reproducing producer and implementation are distinct from the original producer and implementation. 7. Grant SECURITY_TESTED only when both authorized penetration testing and fault injection are complete. 8. Grant RELEASE_ELIGIBLE only when signed provenance is complete, unresolved high-severity findings equal zero, and a human release authority explicitly approves. 9. Conformance and Falsification 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. 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. 10. Relationship to Existing Work 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. 11. Security Considerations 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. 12. IPR and Research Claims 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. 13. IANA Considerations This document has no IANA actions. 14. References 14.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. Erlandsson, "JSON Canonicalization Scheme (JCS)", RFC 8785, June 2020. [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 14.2. Informative References [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, February 2011. [RFC8179] Bradner, S. and J. Contreras, "Intellectual Property Rights in IETF Technology", BCP 79, RFC 8179, May 2017. [RFC9943] Birkholz, H., "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, June 2026. [I-D.ccs] Wang, G. and G. Wang, "A Runtime Verification Receipt Format for Agent Auditing", draft-wang-ccs-runtime-verification-00, Work in Progress, August 2026. [I-D.watts-closure] Watts, D., "Revocation Closure for Agentic Authorization Systems", draft-watts-oauth-agent-revocation-closure-01, Work in Progress, October 2026. Author's Address Deonte O'dell Watts GoodShyt Group Inc. San Francisco, CA, US Email: deonte@goodshyt.fun ORCID: 0009-0005-8586-3650