Conformance Continuity: Verifiable Attestation Across Baseline Supersession, Jurisdictional Recognition and Subject Mutation
draft-hillier-conformance-continuity-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Joel Hillier | ||
| Last updated | 2026-09-27 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-hillier-conformance-continuity-00
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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785,
DOI 10.17487/RFC8785, June 2020,
<https://www.rfc-editor.org/info/rfc8785>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/info/rfc8615>.
[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,
<https://www.rfc-editor.org/info/rfc8126>.
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,
<https://doi.org/10.6028/NIST.FIPS.203>.
[FIPS204] National Institute of Standards and Technology, "Module-
Lattice-Based Digital Signature Standard", FIPS 204,
August 2024, <https://doi.org/10.6028/NIST.FIPS.204>.
[FIPS205] National Institute of Standards and Technology, "Stateless
Hash-Based Digital Signature Standard", FIPS 205, August
2024, <https://doi.org/10.6028/NIST.FIPS.205>.
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, <https://www.rfc-editor.org/info/rfc9334>.
[RFC9711] IETF RATS Working Group, "The Entity Attestation Token
(EAT)", RFC 9711, DOI 10.17487/RFC9711, April 2025,
<https://www.rfc-editor.org/info/rfc9711>.
[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate
Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162,
December 2021, <https://www.rfc-editor.org/info/rfc9162>.
[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,
<https://datatracker.ietf.org/doc/draft-ietf-scitt-
architecture/>.
[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, <https://datatracker.ietf.org/doc/draft-
ietf-cose-merkle-tree-proofs/>.
[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, <https://datatracker.ietf.org/doc/draft-ietf-cose-
dilithium/>.
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,
<https://datatracker.ietf.org/doc/draft-hillier-certisyn-
essential-eight-verified/>.
[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,
<https://datatracker.ietf.org/doc/draft-hillier-certisyn-
ai-governance-verified/>.
[I-D.hillier-scitt-arp]
Hillier, J. D., "Attestation Reconciliation Protocol",
Work in Progress, Internet-Draft, draft-hillier-scitt-arp,
2026, <https://datatracker.ietf.org/doc/draft-hillier-
scitt-arp/>.
[I-D.hillier-coverage-attestation]
Hillier, J. D., "The Coverage Attestation Profile (CAP-
1)", Work in Progress, Internet-Draft, draft-hillier-
coverage-attestation, 2026,
<https://datatracker.ietf.org/doc/draft-hillier-coverage-
attestation/>.
[IAF-TRANSITION]
International Accreditation Forum, "Will IAF and ILAC
Continue to Operate after 1 January 2026?", 2026,
<https://iaf.nu/en/faq/2-01-will-iaf-and-ilac-continue-to-
operate-after-1-january-2026/>.
[IAF-ILAC-A2]
International Accreditation Forum and International
Laboratory Accreditation Cooperation, "IAF/ILAC-A2: IAF/
ILAC Multilateral Mutual Recognition Arrangements", 2025,
<https://iaf.nu/iaf_system/uploads/documents/IAF-
ILAC_A2_09_2025.pdf>.
[ACSC-E8] Australian Signals Directorate, "Essential Eight Maturity
Model", 2024, <https://www.cyber.gov.au/business-
government/asds-cyber-security-frameworks/essential-eight/
essential-eight-maturity-model>.
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, <https://www.cyber.gov.au/
about-us/view-all-content/news/consultation-on-evolution-
of-essential-eight>.
[ASD-ISM] Australian Signals Directorate, "Information Security
Manual, September 2026 release", September 2026,
<https://www.cyber.gov.au/business-government/asds-cyber-
security-frameworks/ism>.
[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,
<https://doi.org/10.6028/NIST.CSWP.29>.
[CNSA2] National Security Agency, "Commercial National Security
Algorithm Suite 2.0", 2022,
<https://www.nsa.gov/Cybersecurity/Post-Quantum-
Cybersecurity-Resources/>.
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]