Network Working Group D. O. Watts Internet-Draft GoodShyt Group Inc. Intended status: Informational 14 October 2026 Expires: 17 April 2027 Government-Oriented Verification Promotion Boundaries for Agentic Assurance Profiles draft-watts-gov-verification-promotion-boundaries-00 Abstract Government and critical-infrastructure relying parties require explicit boundaries between successive assurance claims. This document defines Verification Promotion Boundaries (VPB) as a protocol-neutral profile that prevents verification evidence obtained at one stage from being silently promoted to a stronger claim. The stages are REGISTERED, SPEC_VALIDATED, LOCAL_CONFORMANT, INDEPENDENTLY_REPRODUCED, SECURITY_TESTED, and RELEASE_ELIGIBLE. A local PASS does not imply independent reproduction; an independent reproduction does not imply security testing; and no stage implies endorsement by any standards body or government agency. The profile further distinguishes subject evidence (negative findings against the tested artifact) from verifier evidence (positive findings that the verification system correctly detected defects). Arithmetic and protocol preconditions, including on-curve validation before metamorphic fixtures, are mandatory before any promotion. This document is intended for high-assurance government deployments and is not a U.S. Government standard. 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). 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. Watts Expires 17 April 2027 [Page 1] Internet-Draft Gov Verification Promotion Boundaries October 2026 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 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Assurance Stages and Promotion Boundaries . . . . . . . . . . 3 4. Dual Evidence Semantics . . . . . . . . . . . . . . . . . . . 4 5. Mandatory Preconditions . . . . . . . . . . . . . . . . . . . 4 6. Promotion Receipt . . . . . . . . . . . . . . . . . . . . . . 4 7. Government Deployment Considerations . . . . . . . . . . . . 5 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 10. Normative References . . . . . . . . . . . . . . . . . . . . 5 11. Informative References . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction Agentic systems present a verification problem distinct from conventional software: successful execution of one test suite can be misread as evidence of readiness for a higher assurance claim. Government relying parties operating under zero-trust principles and high-impact AI policies require that each promotion step be explicit, independently attested, and fail-closed. This document formalizes Verification Promotion Boundaries. The central invariant is that verification evidence at level L_i does not authorize a claim at level L_{i+1}. In particular, detection of a specification defect by a verifier constitutes negative evidence for the tested subject and positive evidence for the verifier. This dual semantics is essential for government audit and accountability. Watts Expires 17 April 2027 [Page 2] Internet-Draft Gov Verification Promotion Boundaries October 2026 The profile is designed to compose with existing identity, authorization, evidence, and revocation mechanisms. It does not replace them. It constrains the claims that may be made from their outputs. 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. Assurance Stages and Promotion Boundaries A conforming relying party MUST maintain the following ordered stages. Promotion from one stage to the next requires an independent attestation that the required predicates for the higher stage have been satisfied. No stage may be skipped. 1. REGISTERED: The specification, schema, and initial test corpus are published with digests. 2. SPEC_VALIDATED: The specification is syntactically valid and free of known internal contradictions (including arithmetic counter- examples). 3. LOCAL_CONFORMANT: An implementation passes the published positive and negative vectors under a controlled environment. The implementation under test MUST NOT generate its own expected results. 4. INDEPENDENTLY_REPRODUCED: A second party, using an independent implementation or clean-room environment, reproduces the LOCAL_CONFORMANT result and records the environment digest. 5. SECURITY_TESTED: Authorized penetration testing, fault injection, and adversarial evaluation have been completed and their findings incorporated or accepted with residual risk. 6. RELEASE_ELIGIBLE: All prior stages are satisfied, provenance is signed, and a human approval authority independent of the implementation authors has recorded acceptance. A local PASS MUST NOT be treated as satisfying an INDEPENDENTLY_REPRODUCED or SECURITY_TESTED requirement. An UNKNOWN or INDETERMINATE result at any required predicate MUST prevent promotion. Watts Expires 17 April 2027 [Page 3] Internet-Draft Gov Verification Promotion Boundaries October 2026 4. Dual Evidence Semantics When a verifier detects a defect in a published specification or test vector (for example, an elliptic-curve point that does not satisfy the declared curve equation), the resulting evidence record MUST be classified as: * Negative evidence against the tested subject (the draft or implementation that published the invalid vector). * Positive evidence for the verifier (the verification system correctly rejected the invalid input). This classification prevents a successful defect detection from being collapsed into a claim that the subject has passed, and it provides an auditable record for government oversight. 5. Mandatory Preconditions Before any metamorphic or higher-order fixture is executed, the following preconditions MUST hold and be recorded: 1. All published elliptic-curve parameters have a non-zero discriminant. 2. Every published affine point satisfies the curve equation over the declared field. 3. Negative vectors (off-curve points, wrong field, singular curve) are present and cause rejection. 4. The implementation under test does not supply the expected outputs for the vectors it is being tested against. Failure of any precondition MUST result in INDETERMINATE for the current stage and MUST prevent promotion. 6. Promotion Receipt A Promotion Receipt is an integrity-protected, non-bearer record that binds the source stage, target stage, evidence digests, environment digest, independent observer identifiers, and the decision (PROMOTED or BLOCKED). Possession of a Promotion Receipt MUST NOT be treated as authorization to execute any action outside the declared assurance claim. Watts Expires 17 April 2027 [Page 4] Internet-Draft Gov Verification Promotion Boundaries October 2026 7. Government Deployment Considerations This profile is vendor-neutral and may be used by agencies implementing zero-trust architecture, high-impact AI risk management, or secure software development frameworks. It does not constitute a U.S. Government standard or imply endorsement by any agency. Deployments SHOULD pin the applicable policy identifiers (for example, current OMB memoranda or NIST publications) outside the protocol core so that policy updates do not require protocol changes. For high-impact agent actions, a relying party SHOULD require at least INDEPENDENTLY_REPRODUCED before production admission and SECURITY_TESTED before high-consequence authorization. 8. Security Considerations Threats include circular testing (implementation generates its own expected values), silent promotion of local results, suppression of negative evidence, and treatment of a Promotion Receipt as a bearer credential. The independent observer and human approval roles MUST be distinct from the authors of the implementation under test. Arithmetic preconditions are security-relevant because an off-curve point can invalidate all subsequent group-law claims. 9. IANA Considerations This document has no IANA actions. 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", RFC 8174, May 2017, . 11. Informative References [NIST800207] Rose, S., "Zero Trust Architecture", NIST SP 800-207, August 2020, . [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, February 2011, . Watts Expires 17 April 2027 [Page 5] Internet-Draft Gov Verification Promotion Boundaries October 2026 Author's Address Deonte O'dell Watts GoodShyt Group Inc. San Francisco, CA United States of America Email: deonte@goodshyt.fun URI: https://orcid.org/0009-0005-8586-3650 Watts Expires 17 April 2027 [Page 6]