# Annex H #### H.1 Attestation model and terminology (evidence, claims, appraisal, endorsements) H.1.1 **Purpose.** This Annex defines the attestation model used by NXOSI to bind high-impact compliance and integrity claims to measured system state. Attestation is treated as a verification primitive, not a narrative assertion. It is used to reduce ambiguity, detect drift/compromise, and enable repeatable verification across parties without re-audit. H.1.2 **Core objects.** The attestation model is expressed as a chain of objects, each with mandatory linkage to NXOSI artefacts (CRR/PR) when attestation is required by profile or reliance tier. H.1.2.1 **Evidence (EVD).** Raw or derived measurement outputs obtained from a measurement agent or trusted subsystem (e.g., runtime measurements, firmware hashes, workload identity evidence, configuration digests). Evidence MUST be time-bound and provenance-marked. H.1.2.2 **Claims (CLM).** Structured statements about a target and its execution environment derived from evidence (e.g., “this workload runs this binary digest under this policy and this kernel state”). Claims MUST explicitly declare scope, time binding, and measurement basis. H.1.2.3 **Appraisal Policy (APP).** The rules used to interpret claims and determine acceptability (freshness windows, required measurements, acceptable values, revocation sources, and failure behavior). Appraisal policies MUST be versioned, signed, and treated as governed normative inputs when used for higher reliance tiers. H.1.2.4 **Appraisal Result (APR).** The outcome of evaluating claims under an appraisal policy (pass/fail/conditional) plus reasons, constraints, and expiry semantics. Appraisal results MUST be linkable to CRR and/or PR and MUST be preserved for audit replay per handling class rules. H.1.2.5 **Endorsements (END).** Third-party statements about measurement agents, keys, roots of trust, or trusted environments (e.g., manufacturer endorsement, platform attestation trust anchor). Endorsements MUST be verifiable, revocable, and versioned. H.1.2.6 **Target of Attestation (TOA).** The subject being attested: a build pipeline, deployment artifact, runtime service, host, enclave, device, inference endpoint, data access broker, or policy runtime instance. The TOA MUST be identified by canonical identifiers aligned to the ontology fabric. H.1.3 **Attestation event semantics.** Every attestation used for NXOSI reliance MUST emit an attestation event that is linkable to: (i) the enforcement point, (ii) the relevant control IDs, (iii) the CRR, and (iv) the resulting PR where issued. H.1.4 **Handling discipline.** Evidence and raw measurement artifacts are typically Controlled or Restricted. Receipts may remain Public/Controlled depending on profile and lawful basis. NXOSI MUST support receipt-only verification without exposing evidence by default. *** #### H.2 Attestation tiers and when each tier is required H.2.1 **Purpose of tiers.** Attestation tiers define when measured-state binding is mandatory and how strong the required measurement and appraisal must be, based on risk class, hazard profile, and reliance tier. H.2.2 **Tier taxonomy (baseline).** Implementations MAY add stronger tiers, but MUST meet or exceed the baseline semantics below. H.2.2.1 **AT-0 — No Attestation (Not Attested).** Allowed only where the profile explicitly permits it and reliance is informational, or where the enforcement point is not technically capable. Use MUST be explicitly declared in CRR/PR as “unattested.” H.2.2.2 **AT-1 — Identity-Bound Attestation (Basic).** Attestation binds the check run to an authenticated workload/service identity and a time window; measurements are minimal and often limited to platform identity and software version digests. H.2.2.3 **AT-2 — Integrity-Bound Attestation (Measured).** Attestation includes measured boot and/or equivalent integrity measurements for the environment plus workload digests and policy digests. Appraisal policy enforces minimum claim sets and freshness. H.2.2.4 **AT-3 — Policy-Enforced Attestation (Strong).** Attestation demonstrates not only measured state but also enforced policy boundaries (e.g., allowed tool invocations, data access controls, segmentation policy), with explicit failure behavior and revocation integration. H.2.2.5 **AT-4 — Sovereign/High-Consequence Attestation (Highest).** Attestation is mandatory, frequent, and bound to sovereign-zone trust anchors. Appraisal includes strict endorsement and revocation sources, controlled disclosure, and replayable audit evidence. Required for supervisory-grade reliance in high-impact contexts. H.2.3 **When tiers are required (normative).** Profiles MUST specify attestation requirements per control class and enforcement point. At minimum: H.2.3.1 **High-impact claims.** Any receipt intended to support audit-grade or supervisory-grade reliance for high-consequence contexts MUST be AT-2 or higher; AT-3+ is strongly expected for AI/agentic tool use, privileged runtime access, and critical infrastructure control loops. H.2.3.2 **Sensitive enforcement points.** Build signing, release publication, key operations, policy runtime execution, inference endpoint authorization, and evidence disclosure gates SHOULD require AT-3 or AT-4. H.2.3.3 **Degraded/offline conditions.** If live attestation is unavailable, NXOSI MUST downgrade reliance tier or require delayed appraisal (H.6) with explicit clocks and docketing. H.2.3.4 **Exception usage.** Any waiver allowing lower-tier attestation MUST be time-bound, justified, and recorded as a governed exception object linked to the CRR and docket. *** #### H.3 Minimum claims and measurement sets (by enforcement point and risk class) H.3.1 **Purpose.** Minimum claim sets ensure attestation is comparable across vendors and environments. Profiles MAY add requirements, but MUST include baseline claims for each enforcement point when attestation is required. H.3.2 **Claim categories (baseline).**\ H.3.2.1 **Identity claims.** Workload identity, service identity, issuer authorization, role constraints.\ H.3.2.2 **Integrity claims.** Measured boot state, kernel/firmware integrity, runtime integrity posture, configuration digests.\ H.3.2.3 **Artifact claims.** Build artifact digests, container/image digests, SBOM/provenance references.\ H.3.2.4 **Policy claims.** Policy/runtime version, policy digest, allowlist digest, enforcement mode.\ H.3.2.5 **Environment claims.** Zone/SDZ identifier, enclave identifier (if applicable), network boundary class, time source class.\ H.3.2.6 **Freshness claims.** Timestamp, nonce/challenge binding, expiry, replay constraints.\ H.3.2.7 **Revocation context.** Endorsement chain references and revocation list pointers used for appraisal. H.3.3 **Minimum measurement sets by enforcement point (baseline examples).** H.3.3.1 **Build-time gates (CI/CD).** * Build pipeline identity and runner integrity posture * Source reference and commit digest * Build recipe / build definition digest * Output artifact digest * SBOM and provenance pointers * Signing key usage proof (where applicable) * Appraisal result for build integrity policy H.3.3.2 **Deploy-time gates (infrastructure and configuration).** * Deployment controller identity * Artifact digest and signature verification result * Configuration baseline digest * Segmentation policy digest / boundary class * Secrets handling posture (without disclosing secrets) * Appraisal result under deploy policy H.3.3.3 **Runtime gates (services, data access, agentic tool invocation).** * Workload identity + runtime integrity posture * Policy runtime digest and enforcement mode * Allowlist/tool policy digest (for agents) * Data access broker identity and policy digest * Zone/handling constraints enforcement indicator * Appraisal result and expiry H.3.3.4 **Procurement/vendor gates.** * Vendor evidence acceptance decision bound to validated receipts and status resolution * Vendor endpoint attestation (if connected systems) * Overlay compatibility claims * Proof that checks were run under required profile versions H.3.3.5 **Incident and retest gates.** * Restoration environment integrity posture * Patch/version digests and configuration deltas * Retest execution identity and attestation freshness * Evidence pack pointers for incident artifacts retained in-zone * Appraisal result and retest closure constraints H.3.4 **Risk class scaling.** Higher risk classes MUST require broader claim sets (integrity + policy + environment claims) and tighter freshness windows. Lower risk classes MAY allow reduced sets but MUST still provide identity and time binding at minimum. *** #### H.4 Freshness windows, expiry, and replay protection H.4.1 **Purpose.** Freshness and anti-replay controls prevent stale attestations from being reused out of context and ensure that measured state corresponds to the check run and the time window claimed. H.4.2 **Freshness windows (baseline).**\ H.4.2.1 Profiles MUST define acceptable freshness windows by tier and enforcement point.\ H.4.2.2 AT-2+ attestations MUST include an expiry; AT-3/AT-4 MUST include challenge-based freshness (nonce/challenge binding) when online.\ H.4.2.3 Offline environments MUST use bounded “freshness envelopes” with explicit downgrade rules and docketed delayed appraisal (H.6). H.4.3 **Replay protection (normative).**\ H.4.3.1 Attestations MUST bind to a unique challenge or equivalent anti-replay mechanism.\ H.4.3.2 Attestations MUST bind to the intended TOA and must not be valid for a different subject, different zone, or different policy runtime instance.\ H.4.3.3 NXOSI MUST record anti-replay identifiers (nonces/challenges) in CRR to prevent reuse within forbidden intervals. H.4.4 **Expiry and invalidation.**\ H.4.4.1 Attestation results MUST be invalidated when endorsement chains are revoked, when trust anchors are rotated, or when compromise response is activated (H.7).\ H.4.4.2 Receipts relying on attestations MUST point to status semantics that reflect these invalidations where required by reliance tier. *** #### H.5 Attestation binding to CRR and PR (required linkages) H.5.1 **Binding principle.** If a control requires attestation, the Check Run Record (CRR) MUST include sufficient linkage to prove that the check executed in the measured environment and under the intended policy. H.5.2 **CRR linkage requirements (normative).**\ H.5.2.1 CRR MUST reference the Attestation Bundle Identifier (or equivalent) and appraisal result identifier.\ H.5.2.2 CRR MUST include: attestation tier, TOA identity, policy digest, freshness/expiry, and appraisal policy version.\ H.5.2.3 CRR MUST capture attestation failure outcomes explicitly (deny/degrade/quarantine/escalate) and must open or update a docket where required. H.5.3 **PR linkage requirements (normative).**\ H.5.3.1 When a PR asserts a high-impact claim, PR MUST include a pointer to the attestation appraisal result (or commitment to it) and MUST declare the attestation tier used.\ H.5.3.2 PR MUST constrain permitted inference to what is supported by the attestation tier and appraisal policy.\ H.5.3.3 If attestation is missing where required, PR MUST either not be issued or MUST be issued at a downgraded reliance tier with explicit limitations. H.5.4 **Ontology linkage.** Attestation events SHOULD update the ontology fabric with: TOA state assertions, appraisal outcome, expiry, and relevant provenance pointers, subject to handling constraints. *** #### H.6 Offline and constrained-device attestation patterns H.6.1 **Objective.** Support sovereign, OT, edge, and air-gapped deployments where live attestation and continuous connectivity are not feasible, without collapsing trust or hiding uncertainty. H.6.2 **Patterns (baseline).** H.6.2.1 **Delayed appraisal pattern.** Devices produce signed evidence in-zone; appraisal occurs later when endorsement and revocation inputs are available. NXOSI MUST record the appraisal delay and constrain reliance until appraisal is complete. H.6.2.2 **Cached endorsement pattern.** Endorsements and trust anchors are periodically imported into the zone via controlled channels. Appraisal uses cached materials, with explicit staleness bounds. H.6.2.3 **Store-and-forward attestation events.** Evidence and attestation events are queued and delivered when connectivity returns. Time binding MUST be preserved; replay protection MUST prevent backdated misuse. H.6.2.4 **Gateway-mediated pattern.** Constrained devices attest to a local gateway; the gateway attests to higher layers. This pattern MUST clearly separate device-level and gateway-level claims to avoid overclaiming. H.6.2.5 **Air-gapped verification bundle pattern (SDZ-4).** Appraisal and verification operate against offline snapshots and bundled revocation lists. Updates occur through controlled ingress; reliance rules must reflect snapshot age. H.6.3 **Degraded reliance rules.** When online freshness cannot be guaranteed, NXOSI MUST apply: (i) reduced reliance tier, (ii) shorter validity windows, (iii) docketed retest clocks, or (iv) controlled disclosure for higher-tier reliance. *** #### H.7 Attestation compromise response (re-baseline, re-key, invalidate) H.7.1 **Purpose.** Attestation compromise response ensures that the system can recover trust after a root-of-trust compromise, key leak, malicious firmware, or measurement-agent compromise. H.7.2 **Compromise triggers (baseline).**\ H.7.2.1 Trust anchor/key compromise\ H.7.2.2 Endorsement chain compromise or malicious endorsements\ H.7.2.3 Measurement agent compromise or tampering\ H.7.2.4 Systemic vulnerability affecting measurement correctness H.7.3 **Mandatory response actions.**\ H.7.3.1 **Invalidate.** Publish status actions that invalidate affected attestation appraisal results and any dependent receipts as required by reliance tier.\ H.7.3.2 **Freeze.** Activate emergency freeze controls for affected profiles/enforcement points where continued issuance would be unsafe.\ H.7.3.3 **Re-key.** Rotate keys and revoke compromised credentials.\ H.7.3.4 **Re-baseline.** Establish new trusted baselines; update appraisal policies and endorsements accordingly.\ H.7.3.5 **Re-issue.** Where appropriate, re-run checks and issue new receipts bound to post-remediation attestations. H.7.4 **Audit and publication discipline.** Compromise response MUST create docket entries, correction objects where applicable, and publish public-safe summaries consistent with handling rules. No silent remediation is permitted for compromise events affecting reliance. *** #### H.8 Attestation conformance tests and vectors H.8.1 **Purpose.** Define conformance tests that ensure implementations produce verifiable, comparable attestation behaviors and that relying parties can validate attestation-bound proofs. H.8.2 **Test categories (baseline).** H.8.2.1 **Schema and linkage tests.** Validate required fields, identifiers, and CRR/PR linkage semantics for each attestation tier. H.8.2.2 **Freshness and replay tests.** * Positive tests: valid challenge/nonce binding, valid expiry handling * Negative tests: reused nonces, expired attestations, time-skew beyond allowed bounds H.8.2.3 **Endorsement and revocation tests.** * Positive: valid endorsement chain evaluation * Negative: revoked endorsement; missing revocation inputs; stale cached endorsements beyond policy bounds H.8.2.4 **Compromise drills.** Simulate key compromise or endorsement compromise and verify required behavior: freeze, invalidation via status semantics, and re-baselining steps. H.8.2.5 **Offline/degraded tests.** Verify delayed appraisal, store-and-forward correctness, snapshot age constraints, and reliance downgrade enforcement. H.8.2.6 **Cross-vendor interoperability tests.** Validate that one vendor’s attestation bundles can be appraised and verified by another vendor’s verifier when both claim NXOSI compliance, within the defined conformance surfaces. H.8.3 **Vectors and fixtures.** Conformance suites MUST provide: (i) gold vectors for each tier, (ii) negative vectors, (iii) adversarial vectors (tampered measurements, forged claims), and (iv) performance/resilience vectors for constrained environments. H.8.4 **Output evidence.** Passing conformance MUST produce signed test reports and, where applicable, test receipts that demonstrate verifier behavior, status resolution behavior, and correct reliance downgrades under failure conditions. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.therisk.global/organization/standardization/nexus-osi/annexes/annex-h.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.