Network Working Group J. D. Hillier Internet-Draft Certisyn, Inc. Intended status: Informational 27 September 2026 Expires: 31 March 2027 Conformance Continuity: Verifiable Attestation Across Baseline Supersession, Jurisdictional Recognition and Subject Mutation draft-hillier-conformance-continuity-00 Abstract A conformance claim is a statement about a subject, made against a baseline, at a time. Each of those three terms moves. Baselines are superseded by their issuers. Subjects present the same posture across jurisdictions whose baselines differ. Subjects containing non-person entities mutate faster than the period any attestation covers. A conformance record that cannot be carried across those boundaries, and cannot state what it failed to carry, decays into an assertion. This document specifies the Continuity Binding: a single structure that carries a verified conformance claim across a boundary while preserving the provenance of the evidence beneath it, attributing every equivalence judgement to a named party, and enumerating the residual that did not carry. Three specialisations are defined. The Transition Binding carries a claim across supersession of the governing baseline. The Recognition Binding carries a claim between baselines of different issuers in concurrent force. The Mutation Binding carries a claim across change in the composition of the subject itself, which is the ordinary condition of an environment operating non-person entities. The document specifies Baseline Profiles, Provenance Classes, the verdict taxonomy, the Verification Reconciliation Object, cryptographic agility requirements for records whose reliance outlives any single hardness assumption, and the registries that make baselines issued by any authority in any jurisdiction verifiable under one interoperable structure. The evolution of the Australian Essential Eight Maturity Model into the Essentials series is used as the worked example throughout. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Hillier Expires 31 March 2027 [Page 1] Internet-Draft Conformance Continuity September 2026 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 31 March 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 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Three Moving Terms . . . . . . . . . . . . . . . . . . . 4 1.2. The Common Failure . . . . . . . . . . . . . . . . . . . 5 1.3. Relationship to Existing Recognition Practice . . . . . . 5 1.4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 6 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Components . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Reproducibility . . . . . . . . . . . . . . . . . . . . . 8 3.3. Relationship to Transparency and Attestation Architectures . . . . . . . . . . . . . . . . . . . . . . 9 4. Baseline Profiles . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Required Fields . . . . . . . . . . . . . . . . . . . . . 10 4.2. Evidence Categories . . . . . . . . . . . . . . . . . . . 11 4.3. Provenance Classes . . . . . . . . . . . . . . . . . . . 11 4.4. Registration . . . . . . . . . . . . . . . . . . . . . . 12 5. Verification . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Claim Construction . . . . . . . . . . . . . . . . . . . 12 5.2. Evidence Admission . . . . . . . . . . . . . . . . . . . 12 5.3. Verdicts . . . . . . . . . . . . . . . . . . . . . . . . 12 Hillier Expires 31 March 2027 [Page 2] Internet-Draft Conformance Continuity September 2026 5.4. Provenance Disclosure . . . . . . . . . . . . . . . . . . 13 6. Continuity Bindings . . . . . . . . . . . . . . . . . . . . . 13 6.1. The General Structure . . . . . . . . . . . . . . . . . . 13 6.2. Equivalence Assertions . . . . . . . . . . . . . . . . . 14 6.3. Carry Rules . . . . . . . . . . . . . . . . . . . . . . . 14 6.4. Transition Binding . . . . . . . . . . . . . . . . . . . 15 6.5. Recognition Binding . . . . . . . . . . . . . . . . . . . 16 6.6. Mutation Binding . . . . . . . . . . . . . . . . . . . . 16 7. Governance of Non-Person Entities . . . . . . . . . . . . . . 17 7.1. Delegation Chains . . . . . . . . . . . . . . . . . . . . 17 7.2. Governance Outcomes as Baseline Content . . . . . . . . . 17 7.3. The Inversion . . . . . . . . . . . . . . . . . . . . . . 18 8. Issuing Party Obligations . . . . . . . . . . . . . . . . . . 18 9. Cryptographic Continuity . . . . . . . . . . . . . . . . . . 19 10. Cryptographic Agility and Long-Lived Reliance . . . . . . . . 19 10.1. Reliance Lifetime . . . . . . . . . . . . . . . . . . . 19 10.2. Algorithm Classes . . . . . . . . . . . . . . . . . . . 20 10.3. Archival Multi-Family Signing . . . . . . . . . . . . . 21 10.4. Cryptographic Policy Statement . . . . . . . . . . . . . 21 11. Portability and Resolution . . . . . . . . . . . . . . . . . 21 12. Worked Example: Essential Eight to Essentials . . . . . . . . 22 12.1. The Source Profile . . . . . . . . . . . . . . . . . . . 22 12.2. Transition . . . . . . . . . . . . . . . . . . . . . . . 23 12.3. Recognition . . . . . . . . . . . . . . . . . . . . . . 23 12.4. Mutation . . . . . . . . . . . . . . . . . . . . . . . . 23 13. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 24 13.1. Verifier Conformance . . . . . . . . . . . . . . . . . . 24 13.2. Resolver Conformance . . . . . . . . . . . . . . . . . . 25 13.3. Relying Party Conformance . . . . . . . . . . . . . . . 25 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 14.1. Baseline Profile Registry . . . . . . . . . . . . . . . 25 14.2. Evidence Provenance Class Registry . . . . . . . . . . . 26 14.3. Equivalence Assertion Basis Registry . . . . . . . . . . 26 14.4. Well-Known URI Registration . . . . . . . . . . . . . . 26 15. Security Considerations . . . . . . . . . . . . . . . . . . . 26 15.1. Attestation Laundering . . . . . . . . . . . . . . . . . 27 15.2. Equivalence Assertion Abuse . . . . . . . . . . . . . . 27 15.3. Jurisdiction Shopping . . . . . . . . . . . . . . . . . 27 15.4. Mutation Concealment . . . . . . . . . . . . . . . . . . 28 15.5. Delegation Chain Forgery . . . . . . . . . . . . . . . . 28 15.6. Evidence Forgery . . . . . . . . . . . . . . . . . . . . 28 15.7. Issuing Party Conflict and Compromise . . . . . . . . . 29 15.8. Retroactive Conformance Forgery . . . . . . . . . . . . 29 15.9. Evidence Confidentiality . . . . . . . . . . . . . . . . 29 15.10. Key Compromise . . . . . . . . . . . . . . . . . . . . . 29 15.11. Denial of Resolution . . . . . . . . . . . . . . . . . . 30 15.12. Registry Poisoning . . . . . . . . . . . . . . . . . . . 30 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 Hillier Expires 31 March 2027 [Page 3] Internet-Draft Conformance Continuity September 2026 16.1. Normative References . . . . . . . . . . . . . . . . . . 30 16.2. Informative References . . . . . . . . . . . . . . . . . 31 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 33 1. Introduction 1.1. Three Moving Terms A conformance claim names a subject, a baseline and a period. Assurance practice treats the baseline as fixed, the subject as stable and the period as the only variable. None of the three assumptions holds. *Baselines are superseded.* On 15 June 2026 the Australian Signals Directorate opened consultation on the evolution of the Essential Eight Maturity Model into an Essentials series, published within its cyber security frameworks alongside the Information Security Manual [ASD-ESSENTIALS-CONSULT] [ASD-ISM]. Consultation closed on 12 July 2026. At the date of this document the issuer has published no Essentials chapter, which is the condition Section 6.4 governs and Section 12 works through. The European Union's NIS2 Directive, the Digital Operational Resilience Act, the Cyber Resilience Act and the AI Act have arrived within a three-year window, each carrying its own control expression. ISO/IEC 27001 [ISO27001] and its companion control set [ISO27002] moved in 2022. NIST rewrote its Cybersecurity Framework [NIST-CSF2] in 2024. Supersession is not an occasional event in this domain. It is the steady state. *Baselines are concurrent across jurisdictions.* A single vendor selling into the European Union now holds obligations under several regimes describing overlapping control territory in incompatible vocabulary. The same organisation selling into Australia, the United Kingdom and the United States holds three more. The controls it operates are one set; the regulatory views of that set are many. *Subjects mutate.* An environment operating non-person entities changes composition continuously. Agents are deployed, credentials are delegated, models are replaced and permissions widen, on a cadence measured in days against attestation periods measured in quarters. The subject an attestation describes is not the subject that exists when the attestation is relied upon. Hillier Expires 31 March 2027 [Page 4] Internet-Draft Conformance Continuity September 2026 1.2. The Common Failure Each of the three is treated today as a separate problem with a separate improvisation. Framework crosswalks address concurrency. Re-assessment addresses supersession. Shorter attestation periods address mutation. None produces an artefact that states what was carried, on whose judgement, and what did not carry. The absence has a name. Where a conformance record made against one baseline is presented as conformance to another, and the relying party has no structural means to detect the substitution, the result is *attestation laundering*. It is not usually deliberate. A subject enters it because the issuer has stated that existing investment remains relevant, which is true of controls and does not extend to attestations. This document specifies a single structure for all three boundaries, so that a claim which crosses one is distinguishable, by inspection, from a claim which was made directly. 1.3. Relationship to Existing Recognition Practice Cross-border acceptance of conformity assessment is established at the institutional level. The multilateral arrangements maintained by the International Accreditation Forum and the International Laboratory Accreditation Cooperation [IAF-ILAC-A2] commit signatories to accept certificates issued under peer-evaluated accreditation, on the principle of accreditation once, accepted everywhere. Those arrangements recognise *bodies*. This document specifies recognition of *artefacts*. The distinction is operative: an institutional arrangement establishes that an issuing body is competent, and says nothing machine-readable about which outcomes of a particular baseline a particular subject satisfied, on what evidence, or what remained unverified. The two are complementary. An implementation of this document operating under an institutional arrangement carries the arrangement as the basis of its Equivalence Assertions; an implementation operating outside one attributes the judgement to itself and says so. The institutional layer is itself in transition, which sharpens the point. The International Accreditation Forum ceased operations on 1 January 2026 and its functions passed to Global Accreditation Cooperation Incorporated [IAF-TRANSITION]. A recognition regime expressed only as institutional membership inherits the discontinuities of its institutions. A recognition regime expressed as an artefact does not. Hillier Expires 31 March 2027 [Page 5] Internet-Draft Conformance Continuity September 2026 1.4. Scope This document specifies how a conformance claim binds to an exact issued baseline version, how evidence provenance is classified and disclosed, how reconciliation produces a reproducible verdict, how the result is sealed and resolved, and how a verified claim is carried across a boundary of time, jurisdiction or subject composition. Baseline content remains with its issuer. A Baseline Profile references an issued text and asserts nothing about it. Registration confers no status on a baseline, implies no relationship with its issuer, and creates no obligation on any authority. Where this document and an issuer's own text differ on the content or meaning of that issuer's baseline, the issuer's text governs. This document specifies structure, obligations and semantics. Concrete encoding is out of scope and is expected to follow the signed-statement and receipt formats of [I-D.ietf-scitt-architecture] and [I-D.ietf-cose-merkle-tree-proofs]. Verification against the Essential Eight Maturity Model in isolation is specified in [I-D.hillier-certisyn-essential-eight-verified]. Verification of governance outcomes for non-person entities is specified in [I-D.hillier-certisyn-ai-governance-verified]. Both remain in force. Under this document each is a Baseline Profile, and this document supplies the continuity those documents assume. 2. Conventions and Definitions 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, as shown here. Subject: The organisation, and the environment it operates, whose conformance is verified. Baseline Issuer: The authority that publishes a baseline. External to this document and to every party operating under it. Baseline Profile: A versioned, digest-identified machine-readable reference to a baseline, sufficient to bind an Outcome Claim to an exact issued text. Outcome Statement: A single result asserted by a Baseline Profile, Hillier Expires 31 March 2027 [Page 6] Internet-Draft Conformance Continuity September 2026 expressed as a condition of the Subject's environment rather than as an implementation. Outcome Claim: An assertion that a stated Outcome Statement of a stated Baseline Profile holds over a stated Attestation Period. Evidence Artefact: A configuration snapshot, telemetry record, log extract, document, third-party attestation or external measurement offered in support of an Outcome Claim. Provenance Class: The registered classification of how an Evidence Artefact was obtained and of the party on whom its integrity depends. See Section 4.3. Verification Reconciliation Object (VRO): The reproducible, cryptographically sealed output of a conforming verification. Continuity Binding: The structure recording that a verified claim has been carried across a boundary, the evidence carried, the judgements authorising the carry, and the residual that did not carry. Specialised as Transition, Recognition and Mutation Bindings. Equivalence Assertion: An attributed statement that an Evidence Artefact admitted against one Outcome Statement is sufficient against another. Carry-Forward Set: The set of Evidence Artefacts carried across a boundary under Equivalence Assertions. Conformance Residual: The enumerated set of Outcome Statements of the target Baseline Profile that a Continuity Binding does not carry as Verified. Attestation Laundering: Presentation of a verification made against one Baseline Profile as conformance to another, absent a Continuity Binding. Non-Person Entity (NPE): A software agent or automated process acting within or upon the Subject's environment under delegated authority. Delegation Chain: The ordered record of authority conferred on a Non-Person Entity, from an accountable human or organisational principal through every intermediate grant. Continuity Horizon: The interval, stated in a VRO, over which its Hillier Expires 31 March 2027 [Page 7] Internet-Draft Conformance Continuity September 2026 verdicts remain relied upon given the observed mutation rate of the Subject. Issuing Party: A party designated within a deployment to collect evidence and co-issue VROs within a defined scope. Attestation Period: The contiguous interval over which a VRO asserts its verdicts, bounded by an Anchor Event at each terminus. Anchor Event: The operation binding a VRO to an append-only transparency service at issuance and at supersession. 3. Architecture 3.1. Components A conforming implementation comprises six components. Internal design, scoring methodology and calibration are out of scope. Baseline Profile Registry: Registered Baseline Profiles, their digests, version lineage and issuer-declared lifecycle status. Evidence Ingestion and Normalization Layer: Accepts Evidence Artefacts, records Provenance Class and collection metadata, produces canonical inputs. Reconciliation Confidence Engine: Reconciles Outcome Claims against normalised evidence and emits a reproducible verdict per Outcome Statement. Continuity Engine: Constructs and validates Continuity Bindings, computes the Conformance Residual, and refuses a carry that violates Section 6.3. Verification State Machine: Maintains VRO lifecycle through intake, ingestion, reconciliation, binding, anchoring, issuance, supersession and revocation. Attestation Protocol: Produces the VRO, performs the Anchor Event, registers the artefact for resolution, and binds Issuing Party identity. 3.2. Reproducibility Given identical Outcome Claims, identical Evidence Artefacts, identical Baseline Profile versions and an identical protocol version, a conforming implementation SHALL produce an identical Reconciliation Result. Hillier Expires 31 March 2027 [Page 8] Internet-Draft Conformance Continuity September 2026 The Reconciliation Result is the reproducible content of a VRO. It comprises every Outcome Claim, every admitted Evidence Artefact digest and Provenance Class, every verdict, every recorded deficiency, every Equivalence Assertion and the Conformance Residual. It excludes issuance-time metadata, which does not reproduce: issuance timestamp, VRO identifier, signature value, key identifier, Anchor Event reference and any nonce. A conforming implementation SHALL compute a Reconciliation Digest over the Reconciliation Result, canonicalised under [RFC8785], and SHALL carry that digest in the VRO. Two VROs bearing the same Reconciliation Digest assert the same thing about the same subject under the same policy, whatever their issuance metadata. This is the property that makes independent replay meaningful and makes a Continuity Binding checkable against its predecessor. 3.3. Relationship to Transparency and Attestation Architectures [RFC9334] establishes the remote attestation roles of Attester, Verifier and Relying Party for evidence about a computing environment. This document applies that separation to an organisational conformance claim: the Subject is the Attester, a conforming implementation is the Verifier, and the VRO is the Attestation Result. [RFC9711] supplies the token conventions for entity attestation claims where a VRO is conveyed to a constrained relying party. [I-D.ietf-scitt-architecture] establishes registration of signed statements on an append-only transparency service with receipts, and [I-D.ietf-cose-merkle-tree-proofs] specifies the receipt structure. A VRO is a Signed Statement in that model; an Anchor Event is registration on a Transparency Service; the resolution requirements of Section 11 are satisfied by a receipt. [RFC9162] supplies the append-only log construction those services build on. [I-D.hillier-scitt-arp] specifies reconciliation of attestations that disagree, which is the operation the Reconciliation Confidence Engine performs across evidence from independent sources. [I-D.hillier-coverage-attestation] specifies how an attestation states the extent of the environment its collection reached, which a VRO carries alongside its verdicts and which bounds the Continuity Horizon of Section 6.6. 4. Baseline Profiles Hillier Expires 31 March 2027 [Page 9] Internet-Draft Conformance Continuity September 2026 4.1. Required Fields A Baseline Profile exists so that an Outcome Claim names precisely what it is a claim about. Conformance to "the Essential Eight", "NIS2" or "the AI Act" without a version is outside the scope of this document. A Baseline Profile SHALL carry: profile_id: A stable identifier, unique within the Baseline Profile Registry. issuer: The identity of the Baseline Issuer and a resolvable reference to the issued text. jurisdiction: The jurisdiction or jurisdictions in which the issuer asserts the baseline applies, or the value "none" where the issuer asserts no territorial scope. version: The issuer's own version designation, verbatim. Where the issuer publishes none, the publication date SHALL be used and the substitution recorded. source_digest: A SHA-256 digest over the octets of the issued text exactly as retrieved, with the retrieval URI, timestamp and media type. The digest is over retrieved octets. This document specifies no canonicalisation of external documents, and a conforming implementation SHALL NOT transform an issued text before digesting it. Republication at the same URI with different octets is a new Baseline Profile. effective_from, effective_until: The interval over which the issuer states the text applies. effective_until SHALL be absent where the issuer has stated no end. lifecycle_status: One of "current", "deprecated" or "retired", reflecting the issuer's own published statement. A profile SHALL NOT carry a status the issuer has not stated. Absent a statement, the status is "current". supersedes, superseded_by: References to other profile_id values, populated only where the issuer has stated the relationship. outcome_statements: An ordered set, each carrying a stable outcome_id, the issuer's text verbatim, and evidence categories per Section 4.2. assessment_scale: One of "binary", "ordinal" or "graded". Where ordinal or graded, levels SHALL be enumerated using the issuer's own designations. Hillier Expires 31 March 2027 [Page 10] Internet-Draft Conformance Continuity September 2026 registrant_kind: Either "issuer" or "third_party", recording whether the Baseline Issuer registered the profile. 4.2. Evidence Categories Each Outcome Statement SHALL enumerate the categories of Evidence Artefact admissible against it, and each category SHALL declare its Provenance Class. Many outcomes are not observable from outside a Subject's administrative boundary by any party. Endpoint application control, administrative privilege restriction, backup restoration testing and macro configuration are among them. A regime that reports evidence obtained independently and evidence supplied by the Subject as a single undifferentiated body reports what it was told in a form that reads as though it checked. Declaring Provenance Class at profile level makes the distinction structural rather than editorial. 4.3. Provenance Classes This document establishes the following classes, registered per Section 14.2. Each names the party on whom integrity depends. external-observation: Obtained by a party other than the Subject, from a vantage point the Subject does not control, without reliance on the Subject's cooperation. independent-instrument: Obtained by an instrument within the Subject's boundary under the control of another party, where the Subject cannot alter the record without detection. collected-in-boundary: Collected within the Subject's boundary by an Issuing Party under a documented procedure, where integrity depends on that procedure. agent-attested: Produced by a Non-Person Entity acting under delegated authority, where integrity depends jointly on the Delegation Chain and on the governance state of the attesting entity. An Evidence Artefact of this class SHALL carry a reference to the Delegation Chain under which it was produced. subject-supplied: Supplied by the Subject, where integrity depends on the Subject. third-party-attested: An attestation issued by an identified third party about the Subject, where integrity depends on that third party and on the binding between the attestation and the Subject. Hillier Expires 31 March 2027 [Page 11] Internet-Draft Conformance Continuity September 2026 An Evidence Artefact whose Provenance Class cannot be determined SHALL NOT be admitted. The classes are ordered by the independence of the party on whom integrity depends, in the order listed. That ordering is normative and is the ordering referenced by the promotion prohibition in Section 6.3. 4.4. Registration A Baseline Profile SHALL be registered before use in a conforming VRO. Registration records the reference and its digest. See Section 14.1. 5. Verification 5.1. Claim Construction An Outcome Claim SHALL identify the Subject, the profile_id and version, the outcome_id, the asserted level where the scale is ordinal or graded, and the Attestation Period. A VRO MAY carry Outcome Claims against more than one Baseline Profile. Each claim SHALL remain individually bound to its own profile and version, and the VRO SHALL NOT present an aggregate verdict spanning profiles. 5.2. Evidence Admission Each admitted Evidence Artefact SHALL carry its Provenance Class, its collection timestamp, the identity of the collecting party, a SHA-256 content digest, the outcome_id values against which it is offered, and where its class is agent-attested, its Delegation Chain reference. 5.3. Verdicts Each Outcome Claim SHALL resolve to exactly one verdict. Verified: Evidence sufficient under the profile's stated categories was admitted and reconciled without unresolved contradiction, and continuity across the Attestation Period was established. Provisionally Verified: Evidence was admitted and reconciled without unresolved contradiction, and one or more of continuity, independence or completeness was not established. The deficiency SHALL be recorded. Hillier Expires 31 March 2027 [Page 12] Internet-Draft Conformance Continuity September 2026 Not Verified: Evidence was insufficient, or reconciliation surfaced a contradiction that was not resolved. Indeterminate: A collection or reconciliation step did not complete. Indeterminate SHALL NOT be reported as, converted to, or aggregated with Verified or Provisionally Verified. Indeterminate exists as a terminal verdict because a detector that did not run has not returned a pass, and an upper bound is not a measurement. An implementation that resolves incomplete collection to a favourable verdict does not conform to this document. 5.4. Provenance Disclosure A VRO SHALL state, per Outcome Claim, the count of admitted Evidence Artefacts in each Provenance Class. A VRO resting wholly on subject- supplied evidence is conforming and issuable. A VRO that omits the disclosure is not. 6. Continuity Bindings 6.1. The General Structure A Continuity Binding records that a verified claim has been carried across a boundary. It SHALL record: 1. the boundary kind, being one of "transition", "recognition" or "mutation"; 2. the source Baseline Profile and version, and the target Baseline Profile and version, which are equal where the boundary kind is "mutation"; 3. the predecessor VRO and its Reconciliation Digest; 4. the Carry-Forward Set, by Evidence Artefact digest; 5. every Equivalence Assertion authorising the carry; 6. the Conformance Residual; and 7. the basis on which the boundary was declared. Hillier Expires 31 March 2027 [Page 13] Internet-Draft Conformance Continuity September 2026 A verified claim that has crossed a boundary without a Continuity Binding is not a conforming claim. The structure exists so that a relying party distinguishes a claim made directly from a claim carried, by inspection of the artefact and without recourse to the parties. 6.2. Equivalence Assertions An Equivalence Assertion SHALL record the source profile_id, version and outcome_id; the target profile_id, version and outcome_id; the digest of each Evidence Artefact carried; the identity of the asserting party; the assertion date; and the basis, which SHALL be one of: issuer-stated: A Baseline Issuer has published a statement of equivalence. The assertion SHALL cite it. This basis SHALL NOT be recorded absent such a statement. arrangement-stated: A recognition arrangement between authorities or accreditation bodies establishes acceptance. The assertion SHALL cite the arrangement and the signatory status relied upon. assessor-determined: An Issuing Party has determined equivalence on stated reasoning. subject-asserted: The Subject asserts equivalence. An Equivalence Assertion of basis assessor-determined or subject- asserted SHALL carry an expiry, and SHALL NOT be relied upon after it. An assertion of basis issuer-stated or arrangement-stated remains effective while the cited statement or arrangement remains in force, and SHALL cease to be effective when it does not. Judgement decays and published statements do not. An equivalence determined by an assessor rests on a comparison of two texts at a moment; the texts move, the environment moves, and the comparison is not renewed by the passage of time. Requiring the weaker bases to expire places the cost of staleness on the party that asserted it. 6.3. Carry Rules The following apply to every Continuity Binding regardless of boundary kind. Carried evidence SHALL retain its original collection timestamp and Provenance Class. A carry SHALL NOT refresh a collection timestamp. Hillier Expires 31 March 2027 [Page 14] Internet-Draft Conformance Continuity September 2026 A carry SHALL NOT promote an Evidence Artefact to a Provenance Class of greater independence in the ordering of Section 4.3. Evidence that was subject-supplied at collection remains subject-supplied wherever it is subsequently relied upon. A Continuity Binding SHALL enumerate the Conformance Residual: every Outcome Statement of the target Baseline Profile that the binding does not carry as Verified, with its verdict. An Outcome Statement against which no claim was made SHALL be recorded as Not Verified with the deficiency "no claim made". Silence about a target Outcome Statement does not conform to this document. A verification against a source Baseline Profile SHALL NOT be presented, rendered, summarised or resolved as conformance to a target Baseline Profile absent a Continuity Binding. A Continuity Binding SHALL NOT be chained beyond a depth the implementation publishes. Each carry compounds the judgement of the last, and an unbounded chain of assessor-determined equivalences reaches an assertion no party has examined. 6.4. Transition Binding A Transition Binding carries a claim across supersession of the governing baseline. It SHALL record the issuer statement of supersession relied upon, and SHALL NOT be declared absent a published issuer statement. Where a successor baseline is announced and its text is unpublished, no successor Baseline Profile exists, no Transition Binding is constructible, and no Outcome Claim against the successor is verifiable under this document. A conforming implementation SHALL refuse such a claim rather than admit it provisionally. During the interval in which both profiles are in force a Subject MAY hold verified claims against each. A VRO recording both SHALL keep the two sets of verdicts separately addressable and SHALL NOT present a single conformance statement spanning them. A VRO bound to a profile whose lifecycle_status is "retired" remains valid as a record of what was verified and SHALL continue to resolve as such. It SHALL NOT be rendered as a current conformance statement, and any resolution SHALL surface the retired status and retirement date alongside the verdicts. Hillier Expires 31 March 2027 [Page 15] Internet-Draft Conformance Continuity September 2026 6.5. Recognition Binding A Recognition Binding carries a claim between Baseline Profiles of different issuers in concurrent force. It SHALL record the jurisdiction of each profile and the recognition basis relied upon. A Recognition Binding SHALL NOT assert that the source and target baselines are equivalent. It asserts that specified evidence admitted against specified source Outcome Statements is sufficient against specified target Outcome Statements, and enumerates every target Outcome Statement for which that is not asserted. The distinction is the whole of the construct: baselines drafted by different authorities for different purposes are not equivalent, and a regime that claims they are produces a conclusion no relying party can act on. Where an Equivalence Assertion within a Recognition Binding carries the basis arrangement-stated, the implementation SHALL record the arrangement's identity and the signatory status relied upon at the assertion date, and SHALL treat lapse of that status as expiry of the assertion. 6.6. Mutation Binding A Mutation Binding carries a claim across change in the composition of the Subject under a stable Baseline Profile. The source and target profiles are the same; the Subject is not. An environment operating Non-Person Entities mutates on a cadence shorter than the Attestation Period of any practical assurance regime. Agents are deployed and retired, authority is delegated and widened, and models are replaced, between one attestation and the next. A verdict issued over such an environment describes a composition that has already changed. A VRO over a Subject operating Non-Person Entities SHALL state a Continuity Horizon: the interval over which its verdicts are offered for reliance, derived from the observed mutation rate of the Subject and bounded by the coverage the collection achieved. The Continuity Horizon SHALL NOT exceed the Attestation Period, and MAY be shorter. A Mutation Binding SHALL record the mutation events that occurred between the predecessor VRO and itself, classified as: additive: A Non-Person Entity or capability was introduced. Evidence carried forward does not extend to it, and every Outcome Statement whose verification depended on enumeration of the environment enters the Conformance Residual. Hillier Expires 31 March 2027 [Page 16] Internet-Draft Conformance Continuity September 2026 reductive: A Non-Person Entity or capability was withdrawn. Evidence carried forward remains sufficient, and the withdrawal is recorded. substitutive: A Non-Person Entity was replaced by another under the same Delegation Chain. Carry-forward requires an Equivalence Assertion naming both entities. authority-widening: The authority of an existing Non-Person Entity was extended. Evidence carried forward does not extend to the widened authority, and this SHALL be treated as additive for the purpose of the Conformance Residual. An additive or authority-widening mutation SHALL NOT be carried under an Equivalence Assertion of basis subject-asserted. The Subject is the party that made the change and is not the party that establishes it did not disturb the verdict. 7. Governance of Non-Person Entities 7.1. Delegation Chains A Non-Person Entity acts under authority it did not originate. A conformance claim over an environment containing such entities is unverifiable unless that authority is traceable to an accountable principal. A Delegation Chain SHALL record, for each grant in order: the granting principal, the receiving entity, the scope of authority conferred, the interval over which it is conferred, and the mechanism by which it may be withdrawn. The first grant in the chain SHALL name a human or organisational principal. An Evidence Artefact of Provenance Class agent-attested SHALL reference the Delegation Chain in force at its collection. Where the chain cannot be resolved, the artefact SHALL NOT be admitted, and the Outcome Statements it was offered against resolve to Indeterminate rather than Not Verified: an unresolvable chain is a failure of collection, not a finding about the Subject. 7.2. Governance Outcomes as Baseline Content Baselines addressing Non-Person Entities are Baseline Profiles in the ordinary way. Where an issuer publishes a chapter, annex or instrument governing agentic systems, it registers under Section 14.1 without extension to this document, and claims against it are verified, carried and resolved by the same mechanisms. Hillier Expires 31 March 2027 [Page 17] Internet-Draft Conformance Continuity September 2026 Verification of governance outcomes for such entities is specified in [I-D.hillier-certisyn-ai-governance-verified]. Management-system requirements for artificial intelligence are published as [ISO42001]. Both are registrable Baseline Profiles. 7.3. The Inversion Classical assurance assumes a stable subject observed against a moving baseline. Agentic environments invert it: the baseline is stable and the subject moves continuously. The two conditions have been treated as unrelated problems. They are the same problem observed from opposite ends. In both, a verified claim must cross a boundary between the state that was examined and the state that is relied upon, and in both the requirement is identical: name what carried, attribute the judgement that carried it, preserve the provenance of the evidence beneath it, and enumerate what did not carry. A regime that solves one and improvises the other will meet the third case, jurisdictional concurrency, with no structure at all. 8. Issuing Party Obligations An Issuing Party collects evidence within a defined scope and co- issues VROs. An Issuing Party SHALL: * hold a designation that is individually revocable and publicly resolvable; * be identified in every VRO it co-issues, so the artefact names who collected the evidence; * declare, per engagement, every interest in the Subject beyond the verification itself, including advisory, implementation, remediation and resale relationships; * collect evidence of Provenance Class collected-in-boundary under a documented procedure sufficient for a later reviewer to determine what was collected, from whom and when; * record each Equivalence Assertion under the basis that is accurate, and record issuer-stated or arrangement-stated only against a citation; * retain collected evidence and reconciliation inputs, and surrender them on request for reproduction of any VRO it co-issued. Hillier Expires 31 March 2027 [Page 18] Internet-Draft Conformance Continuity September 2026 Declaration of an implementation or remediation relationship is a requirement and not a disqualification. Where one party both implements and verifies, that fact bears on reliance and belongs on the artefact. 9. Cryptographic Continuity A VRO SHALL carry the identifier of every signature applied to it, the class of each signing algorithm under Section 10.2, and the key identifier for each. Signing keys SHALL be published, with a key index and an append-only log recording issuance, rotation and supersession, at an address resolving without authentication. A VRO SHALL be bound by an Anchor Event at issuance and at supersession. The anchoring service SHALL be append-only and independently verifiable without reference to the issuing implementation. A Transparency Service conforming to [I-D.ietf-scitt-architecture], or a log conforming to [RFC9162], satisfies this, and the resulting receipt SHOULD be carried in the VRO. A VRO SHALL reference its immediate predecessor for the same Subject where one exists, forming a chain a reviewer walks without possessing any intermediate artefact. Where the predecessor is reached through a Continuity Binding, the binding SHALL be part of that chain. Verification SHALL remain possible after expiry, rotation or compromise of the key in force at issuance, by reference to the key log and the Anchor Event. 10. Cryptographic Agility and Long-Lived Reliance 10.1. Reliance Lifetime A conformance record is relied upon for as long as the decision it supported remains open to challenge. For procurement, insurance underwriting, regulatory filing and supply-chain assurance that period runs to years and frequently to decades, which exceeds the remaining safe life of the classical signature algorithms in general use. The threat is distinct from the confidentiality threat that dominates post-quantum planning. An adversary holding a cryptographically relevant quantum computer has no need to decrypt a conformance record. It forges one. A signature forged against a historical key produces a conformance statement appearing to have been issued years Hillier Expires 31 March 2027 [Page 19] Internet-Draft Conformance Continuity September 2026 earlier, for a period beyond independent recollection, indistinguishable from a genuine record. This document names that *retroactive conformance forgery*. Anchoring bounds it and does not remove it. A transparency service establishes that an artefact existed at a point in time; it does not establish that the signature over that artefact remains unforgeable. 10.2. Algorithm Classes An implementation SHALL classify every cryptographic primitive it applies into exactly one of five classes. approved: A quantum-resistant primitive standardised for the purpose. ML-KEM [FIPS203], ML-DSA [FIPS204] and SLH-DSA [FIPS205] are in this class, as are AES-256, SHA-384 and above, and the corresponding HMAC and HKDF constructions. approved-hybrid: A classical primitive permitted only as the classical component of a hybrid paired with a quantum-resistant primitive. transition: A classical primitive permitted during migration and scheduled for retirement. Ed25519 [RFC8032] and SHA-256 are in this class. A deployment serving national security systems classifies against [CNSA2]. deprecated: Not on the approved list and not permitted on a protected surface pending review. forbidden: Below the applicable security floor, or classically broken. RSA and finite-field Diffie-Hellman are in this class at every parameter size, as are hash and symmetric primitives below the 128-bit floor. Every primitive of class approved-hybrid and every primitive of class transition is vulnerable to Shor's algorithm, Ed25519 among them. The classification states what a deployment may apply and under what constraint; it does not state that a primitive is quantum-resistant. Section 10.3 states the constraint that governs long-lived reliance. Classification is a property of a primitive at a point in time and moves as standards and cryptanalysis move. An implementation SHALL record, in each VRO, the class it assigned to each primitive at issuance, so a relying party evaluating a historical VRO determines what the issuer considered sufficient when it issued rather than inferring it. Hillier Expires 31 March 2027 [Page 20] Internet-Draft Conformance Continuity September 2026 An implementation SHALL NOT apply a primitive of class deprecated or forbidden to a VRO, and SHALL NOT apply a primitive of class transition as the sole signature over a VRO offered for reliance beyond the retirement date it has published for that class. 10.3. Archival Multi-Family Signing A VRO offered for long-lived reliance SHOULD carry signatures from at least two distinct cryptographic hardness families, and every signature so carried MUST verify for the VRO to be treated as valid. The recommended pairing is a lattice-based signature with a hash- based signature: ML-DSA [FIPS204] with SLH-DSA [FIPS205]. Their security rests on unrelated assumptions, so an advance against structured lattices does not compromise the hash-based signature and an advance against the hash function does not compromise the lattice signature. A third signature of class transition MAY be carried for interoperability with verifiers that do not yet implement the quantum-resistant families. Requiring every carried signature to verify, rather than any one, is deliberate. A verifier accepting the first signature it recognises reduces the construction to the strength of its weakest family, inverting the property the construction exists to provide. Where the encoding of [I-D.ietf-cose-merkle-tree-proofs] is used, quantum-resistant signature representation follows [I-D.ietf-cose-dilithium]. 10.4. Cryptographic Policy Statement A resolver SHALL publish, within the descriptor required by Section 11, the classification it applies to each primitive it uses, the retirement date it has published for the transition class, and the signature suites it applies at each reliance horizon. Publication makes the policy checkable rather than asserted. A relying party confirms that the classification in force at issuance matches the classification the issuer published at that time, and a change of policy becomes a dated, observable event rather than a silent substitution. 11. Portability and Resolution Every VRO and every certificate rendered from one SHALL carry a resolution address and a code resolving at that address to the verification record. Hillier Expires 31 March 2027 [Page 21] Internet-Draft Conformance Continuity September 2026 A resolver SHALL publish a machine-readable descriptor at the well- known URI "verification-registry" [RFC8615], registered per Section 14.4. The descriptor SHALL declare the resolver's refusal semantics, the code forms it accepts, the resolution address for each, the Continuity Binding chain depth it permits, and the Cryptographic Policy Statement required by Section 10.4. A resolver MAY serve additional descriptors at implementation-specific well- known URIs. A code that does not resolve is a refusal and SHALL NOT be interpreted as a clearance. The descriptor SHALL state this, and any human-readable rendering of a non-resolving code SHALL state it. Resolution of a VRO carrying a Continuity Binding SHALL surface the boundary kind, the source profile and its lifecycle_status, and the Conformance Residual, alongside the verdicts. A rendering that shows carried verdicts without the residual does not conform. A resolver SHOULD operate independently of the issuing implementation's application infrastructure, so that resolution survives an outage of that infrastructure. 12. Worked Example: Essential Eight to Essentials This section is non-normative and illustrates all three boundary kinds against a single transition in progress. 12.1. The Source Profile The ACSC Essential Eight Maturity Model [ACSC-E8] registers with assessment_scale "ordinal", levels One, Two and Three as designated by the issuer, jurisdiction "AU", and eight Outcome Statements. Evidence categories follow [I-D.hillier-certisyn-essential-eight-verified]. Of the eight, patch currency and multi-factor authentication admit evidence of Provenance Class external-observation at the network boundary. Application control, macro configuration, user application hardening, administrative privilege restriction and backup practice admit evidence of class collected-in-boundary or independent- instrument. A Subject presenting a VRO over this profile therefore discloses that the majority of its verdicts rest on evidence its own boundary produced, which is the accurate position and one no self- assessment states. Hillier Expires 31 March 2027 [Page 22] Internet-Draft Conformance Continuity September 2026 12.2. Transition On publication of an Essentials chapter and an issuer statement of supersession, a successor Baseline Profile registers and a Transition Binding becomes constructible. Before publication neither exists, and a conforming implementation refuses a claim against the successor under Section 6.4. Patch-currency evidence collected against the source profile carries forward under an Equivalence Assertion. Where the issuer has published a mapping, the basis is issuer-stated and the assertion does not expire. Where it has not, the basis is assessor-determined, the assertion carries an expiry, and the Conformance Residual enumerates every successor Outcome Statement not carried. A relying party reading the artefact sees which verdicts were tested against the successor and which were inherited. 12.3. Recognition The same Subject sells into the European Union and holds obligations under regimes describing overlapping control territory in different vocabulary. A Recognition Binding carries specified evidence from the Australian profile against specified Outcome Statements of a European profile, records the jurisdiction of each, and enumerates every European Outcome Statement for which sufficiency is not asserted. The binding does not assert that the two baselines are equivalent, because they are not. It asserts that identified evidence is sufficient against identified outcomes, which is a statement a relying party can act on and a claim of equivalence is not. 12.4. Mutation The Subject deploys agents that hold credentials and act on its systems. Each deployment is an additive mutation and each widening of an agent's authority is an authority-widening mutation. Under Section 6.6 the Outcome Statements whose verification depended on enumeration of the environment enter the Conformance Residual, and neither mutation carries under a subject-asserted Equivalence Assertion. The VRO states a Continuity Horizon shorter than its Attestation Period, because the environment changes faster than the period. That is the accurate position for an agentic environment, and it is a position the fixed-period attestation regimes in general use have no field to express. Hillier Expires 31 March 2027 [Page 23] Internet-Draft Conformance Continuity September 2026 13. Conformance 13.1. Verifier Conformance An implementation conforms as a Verifier if and only if it: 1. binds every Outcome Claim to a registered Baseline Profile identified by profile_id, version and source_digest; 2. records the Provenance Class of every admitted Evidence Artefact and refuses admission where it is undetermined; 3. refuses an Evidence Artefact of class agent-attested whose Delegation Chain does not resolve, and reports the affected Outcome Statements as Indeterminate; 4. reports Indeterminate as a terminal verdict; 5. discloses admitted artefact counts by Provenance Class per Outcome Claim; 6. refuses an Outcome Claim against an announced and unpublished baseline; 7. records a Continuity Binding, with attributed Equivalence Assertions and an enumerated Conformance Residual, for every carry across a boundary of any kind; 8. enforces the carry rules of Section 6.3, including the prohibition on Provenance Class promotion and the published chain-depth limit; 9. states a Continuity Horizon on every VRO over a Subject operating Non-Person Entities; 10. computes and carries a Reconciliation Digest, and reproduces the Reconciliation Result of any VRO it issued from its recorded inputs; 11. classifies every primitive it applies per Section 10.2, records the class assigned at issuance, and applies no primitive of class deprecated or forbidden; 12. signs and anchors per Section 9. Hillier Expires 31 March 2027 [Page 24] Internet-Draft Conformance Continuity September 2026 13.2. Resolver Conformance An implementation conforms as a Resolver if and only if it publishes the descriptor required by Section 11, resolves issued codes to verification records, declares refusal semantics, surfaces retired lifecycle_status on any resolution of a VRO bound to a retired profile, and surfaces boundary kind and Conformance Residual on any resolution of a VRO carrying a Continuity Binding. 13.3. Relying Party Conformance A Relying Party conforms if and only if it treats a non-resolving code as a refusal, treats Indeterminate as distinct from every other verdict, does not treat a VRO bound to one Baseline Profile as conformance to another absent a Continuity Binding, reads the Conformance Residual before relying on carried verdicts, and does not rely on a VRO beyond its stated Continuity Horizon. 14. IANA Considerations 14.1. Baseline Profile Registry IANA is requested to create the "Baseline Profiles" registry. The registration policy is Specification Required [RFC8126]. Each registration records profile_id, issuer, jurisdiction, a resolvable reference to the issued text, version, source_digest, lifecycle_status, supersedes and superseded_by where stated by the issuer, registrant_kind, and a reference. Designated experts are directed to confirm that the reference resolves to a published text, that source_digest is stated over retrieved octets, and that lifecycle_status reflects a published issuer statement. Designated experts are directed not to evaluate the merit of a baseline. Registration by a party other than the Baseline Issuer is permitted and recorded as registrant_kind "third_party". Registration records a reference to an external document. It confers no status on that document and represents no relationship with its issuer. Hillier Expires 31 March 2027 [Page 25] Internet-Draft Conformance Continuity September 2026 14.2. Evidence Provenance Class Registry IANA is requested to create the "Evidence Provenance Classes" registry, with a registration policy of Specification Required [RFC8126]. Each registration records the class name, a description of how evidence in the class is obtained, the party on whom its integrity depends, its position in the independence ordering, and a reference. The initial contents are the six classes defined in Section 4.3, each referencing this document. Designated experts are directed to confirm that a proposed class names a distinct party on whom integrity depends, to place it in the independence ordering, and to reject classes duplicating an existing class under a different name. 14.3. Equivalence Assertion Basis Registry IANA is requested to create the "Equivalence Assertion Bases" registry, with a registration policy of Specification Required [RFC8126]. Each registration records the basis name, the party whose judgement it represents, whether assertions on that basis expire, and a reference. The initial contents are the four bases defined in Section 6.2. Designated experts are directed to reject a proposed basis that does not identify a party accountable for the judgement. 14.4. Well-Known URI Registration IANA is requested to register the following in the "Well-Known URIs" registry [RFC8615]. URI suffix: verification-registry Change controller: IETF Specification document: This document, Section 11 Status: permanent Related information: Declares resolver refusal semantics, continuity chain depth and cryptographic policy for verification record resolution. 15. Security Considerations Hillier Expires 31 March 2027 [Page 26] Internet-Draft Conformance Continuity September 2026 15.1. Attestation Laundering The principal threat is presentation of a verification made against one baseline as conformance to another. It is cheap to attempt, plausible where an issuer has stated that existing investment remains relevant, and difficult to detect because baselines drafted for related purposes share vocabulary. The mitigations are the mandatory Continuity Binding, the prohibition in Section 6.3, mandatory residual enumeration, the requirement that resolution surface boundary kind and residual, and the published chain-depth limit. A Relying Party conforming to Section 13.3 detects the attack by inspection of the artefact alone. 15.2. Equivalence Assertion Abuse An Equivalence Assertion is a judgement, and the party best placed to make it frequently has an interest in making it loosely. The mitigations are mandatory attribution to a named party, the four- value basis separating a published issuer statement and a recognition arrangement from an assessor's determination and from the Subject's own claim, the prohibition on recording the stronger bases without a citation, and mandatory expiry on the weaker two. A relying party discounts by basis. 15.3. Jurisdiction Shopping A Recognition Binding permits a Subject to seek verification under the least demanding available baseline and carry it toward the most demanding. The mitigations are the enumerated Conformance Residual, which makes the uncarried portion explicit rather than absent; the recorded jurisdiction of each profile; and the prohibition on asserting equivalence between baselines, which confines the claim to identified evidence against identified outcomes. A relying party that reads the residual sees precisely which of its own requirements were never tested. A second mitigation operates across engagements rather than within one. Where verdicts on Outcome Statements linked by an Equivalence Assertion disagree, two conditions produce the disagreement and they carry opposite implications. The baselines may differ materially on the outcome, in which case the assertion is defective and every Subject relying on it is affected. Or the baselines may agree and the Subject presented differently to each authority, in which case that Subject alone is affected. Hillier Expires 31 March 2027 [Page 27] Internet-Draft Conformance Continuity September 2026 An implementation SHOULD compute, for each Equivalence Assertion it has recorded, the rate at which carries under that assertion produce contradictory verdicts across the Subjects relying on it. A contradiction rate stable across that population indicates a defective assertion. A contradiction confined to one Subject while others under the same assertion reconcile indicates a divergent Subject. An implementation SHOULD suspend further carries under an Equivalence Assertion whose contradiction rate exceeds a threshold it publishes. The computation is available only because Equivalence Assertions are attributed and individually identified under Section 6.2. A regime that relates baselines without recording which assertion authorised a given carry has no population over which to compute the rate, and cannot separate a defective relation from a divergent Subject. 15.4. Mutation Concealment A Subject controlling its own environment can deploy or widen the authority of a Non-Person Entity and omit the event from a Mutation Binding. The mitigations are the prohibition on carrying additive and authority-widening mutations under subject-asserted assertions, the requirement that agent-attested evidence reference a resolvable Delegation Chain, and the Continuity Horizon, which bounds reliance independently of what the Subject discloses. Coverage attestation under [I-D.hillier-coverage-attestation] bounds the claim to the extent collection actually reached. 15.5. Delegation Chain Forgery An adversary controlling a Non-Person Entity may present a fabricated Delegation Chain to have agent-attested evidence admitted. Requiring the first grant to name a human or organisational principal bounds the fabrication to parties who can be held accountable, and reporting an unresolvable chain as Indeterminate rather than Not Verified prevents an adversary from converting a collection failure into a finding about a competitor. 15.6. Evidence Forgery Evidence of class subject-supplied, collected-in-boundary or agent- attested can be fabricated by a Subject with sufficient access to its own systems. No document at this layer prevents that. The requirement is that the artefact never conceal the dependency: counts by Provenance Class are disclosed per claim, and a relying party prices the residual risk rather than assuming it away. Hillier Expires 31 March 2027 [Page 28] Internet-Draft Conformance Continuity September 2026 15.7. Issuing Party Conflict and Compromise An Issuing Party that also implements or remediates for a Subject has an interest in a favourable verdict. Mandatory declaration, individually revocable and publicly resolvable designation, and the obligation to surrender inputs for reproduction make the conflict visible and the verdict checkable. A compromised Issuing Party is bounded by revocation and by reproducibility, which permits re- derivation of every VRO it co-issued. 15.8. Retroactive Conformance Forgery An adversary that breaks a signature algorithm forges conformance records appearing to have been issued while that algorithm was in good standing. The target is not a current attestation, which a relying party can re-request, but a historical one supporting a decision now closed to re-examination. The mitigations are archival multi-family signing under Section 10.3, which requires two unrelated hardness assumptions to be broken rather than one; the requirement that every carried signature verify; anchoring, which bounds the insertion window; and the recorded algorithm class, which lets a relying party identify records issued under primitives since reclassified and re-verify selectively rather than discarding a corpus. 15.9. Evidence Confidentiality Evidence Artefacts frequently contain configuration detail whose disclosure assists an attacker. A VRO is designed to be publicly resolvable while the evidence beneath it is not. An implementation SHALL NOT place Evidence Artefact content in a publicly resolvable record, and SHALL publish digests in place of content. A verdict is itself a signal, and a Conformance Residual is a precise one: it enumerates what was not verified. A Subject controls disclosure by controlling distribution of the code, and a deployment SHOULD support resolution scoped to a presented code rather than enumeration of a Subject's history. 15.10. Key Compromise Compromise of a signing key permits forgery of VROs bearing that key. The key log and Anchor Event requirements bound the damage by making the set of legitimately issued artefacts enumerable and the compromise window determinable after the fact. Hillier Expires 31 March 2027 [Page 29] Internet-Draft Conformance Continuity September 2026 15.11. Denial of Resolution An adversary able to suppress resolution causes a valid verification to appear invalid when relied upon. Independent operation of the resolver is a mitigation. A relying party requiring high assurance retains the VRO and its receipt rather than depending on resolution at time of need. 15.12. Registry Poisoning Third-party registration permits an adversary to register a Baseline Profile referencing a text of its choosing. The mitigations are source_digest over retrieved octets, which binds the profile to specific content; registrant_kind, which discloses that the issuer did not register it; and the requirement that an Outcome Claim name profile_id, version and source_digest together. 16. References 16.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . Hillier Expires 31 March 2027 [Page 30] Internet-Draft Conformance Continuity September 2026 [FIPS203] National Institute of Standards and Technology, "Module- Lattice-Based Key-Encapsulation Mechanism Standard", FIPS 203, August 2024, . [FIPS204] National Institute of Standards and Technology, "Module- Lattice-Based Digital Signature Standard", FIPS 204, August 2024, . [FIPS205] National Institute of Standards and Technology, "Stateless Hash-Based Digital Signature Standard", FIPS 205, August 2024, . 16.2. Informative References [RFC9334] Birkholz, H., Thaler, D., Wallace, M., Pan, W., and N. Cam-Winget, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . [RFC9711] IETF RATS Working Group, "The Entity Attestation Token (EAT)", RFC 9711, DOI 10.17487/RFC9711, April 2025, . [RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, December 2021, . [I-D.ietf-scitt-architecture] IETF SCITT Working Group, "An Architecture for Trustworthy and Transparent Digital Supply Chains", Work in Progress, Internet-Draft, draft-ietf-scitt-architecture, 2026, . [I-D.ietf-cose-merkle-tree-proofs] IETF COSE Working Group, "COSE Receipts", Work in Progress, Internet-Draft, draft-ietf-cose-merkle-tree- proofs, 2026, . [I-D.ietf-cose-dilithium] IETF COSE Working Group, "ML-DSA for JOSE and COSE", Work in Progress, Internet-Draft, draft-ietf-cose-dilithium, 2026, . Hillier Expires 31 March 2027 [Page 31] Internet-Draft Conformance Continuity September 2026 [I-D.hillier-certisyn-essential-eight-verified] Hillier, J. D., "Essential Eight Verified - A Cryptographic Verification Standard for the ACSC Essential Eight Maturity Model", Work in Progress, Internet-Draft, draft-hillier-certisyn-essential-eight-verified, 2026, . [I-D.hillier-certisyn-ai-governance-verified] Hillier, J. D., "AI Governance Verified - A Cryptographic Verification Standard for Agentic AI Governance in Regulated Industries", Work in Progress, Internet-Draft, draft-hillier-certisyn-ai-governance-verified, 2026, . [I-D.hillier-scitt-arp] Hillier, J. D., "Attestation Reconciliation Protocol", Work in Progress, Internet-Draft, draft-hillier-scitt-arp, 2026, . [I-D.hillier-coverage-attestation] Hillier, J. D., "The Coverage Attestation Profile (CAP- 1)", Work in Progress, Internet-Draft, draft-hillier- coverage-attestation, 2026, . [IAF-TRANSITION] International Accreditation Forum, "Will IAF and ILAC Continue to Operate after 1 January 2026?", 2026, . [IAF-ILAC-A2] International Accreditation Forum and International Laboratory Accreditation Cooperation, "IAF/ILAC-A2: IAF/ ILAC Multilateral Mutual Recognition Arrangements", 2025, . [ACSC-E8] Australian Signals Directorate, "Essential Eight Maturity Model", 2024, . Hillier Expires 31 March 2027 [Page 32] Internet-Draft Conformance Continuity September 2026 [ASD-ESSENTIALS-CONSULT] Australian Signals Directorate, "Consultation on evolution of Essential Eight", June 2026, . [ASD-ISM] Australian Signals Directorate, "Information Security Manual, September 2026 release", September 2026, . [ISO27001] International Organization for Standardization, "ISO/IEC 27001:2022 Information security, cybersecurity and privacy protection - Information security management systems - Requirements", 2022. [ISO27002] International Organization for Standardization, "ISO/IEC 27002:2022 Information security, cybersecurity and privacy protection - Information security controls", 2022. [ISO42001] International Organization for Standardization, "ISO/IEC 42001:2023 Information technology - Artificial intelligence - Management system", 2023. [NIST-CSF2] National Institute of Standards and Technology, "The NIST Cybersecurity Framework (CSF) 2.0", NIST CSWP 29, 2024, . [CNSA2] National Security Agency, "Commercial National Security Algorithm Suite 2.0", 2022, . Author's Address Joel David Hillier Certisyn, Inc. Ogden, Utah 84401 United States Email: jhillier@certisyn.com URI: https://certisyn.com/ Hillier Expires 31 March 2027 [Page 33]