Internet Engineering Task Force T. Sato Internet-Draft MyAuberge K.K. Intended Status: Standards Track 4 September 2026 Expires: 4 March 2027 Kernel Identity and Attestation for Governing Enforcement Components draft-sato-soos-kia-06 Abstract This document specifies the Kernel Identity and Attestation (KIA) protocol for the Sovereign Object OS (SOOS) governance architecture. KIA defines the cryptographic identity of the GEC, the trust chain anchoring kernel authority from hardware root through operator root keypair to every signed Event Log entry, the GEC Manifest schema for runtime state attestation, and the Revocation Registry maintenance requirements. KIA is the Layer 0 signing and attestation component on which the audit trail guarantees of draft-sato-soos-gar, the mandate enforcement guarantees of draft-sato-soos-mjwt, and the multi-agent delegation chain of draft-sato-soos-mad all depend. Version -03 adds FROST threshold signing for high-availability GEC keypair deployments, the Cross-Principal Identifier (XPID) for cross-instance federation audit correlation, the XPID cross- instance trust model, and four new Security Considerations addressing FROST nonce reuse, XPID revocation gap, identity takeover via claimed identifier (CVE-2025-13609 class), and attestation channel binding (CVE-2026-33697 class). This document is the reference specification for the KIA RATS WG presentation at IETF 126 Vienna. The XPID primitive and the CVE-2026-33697 attestation channel binding defense are the primary novel contributions presented to the RATS WG. Version -04 corrects a registry-format mismatch identified by IANA early review (#1456067): the IANA Considerations request to register XPID_DERIVED and XPID_VERIFICATION_FAILED into the GAR Authority Lifecycle Event Types Registry the GAR draft defines now uses that registry's actual column set (Event Type, Class, Reference) and assigns both entries the newly-defined Class ID (Identity/ Federation event). No new event types, fields, or normative behavior are introduced in -04; this is a registration-format correction only. Version -05 discloses a known open issue found by a WIMSE security review checklist dry-run against -03 (DR-MJWT-KIA-CHECKLIST-01, Finding 4): the Cross-Instance Trust Model verifies an XPID but does not restrict which federation participants can see the underlying Evidence in the first place. This is named as OQ-KIA-EVIDENCE-VIS, following the same acknowledge-rather-than- silently-omit pattern this document already uses for OQ-S-XPID-REV. No mechanism is specified in -05; resolution is deferred, consistent with how OQ-S-XPID-REV is treated. Version -06 closes out a full WIMSE Security Review checklist pass (Stage 0 through Stage 2) run against -05. It restores seven GEC Manifest fields silently absent since -03 despite -03's text claiming the -02 schema was carried forward in full, including attestation_certificate; mints a dedicated XPID namespace UUID in place of the reused DNS namespace UUID; updates the FROST reference from the CFRG working draft to RFC 9591 and corrects the nonce-generation section citations; resolves a genuine bootstrapping contradiction between the quorum-failure signing prohibition and the quorum-failure alerting requirement (new CONF-KIA-24); tightens Security Considerations wording describing the XPID derivation input; adds a new Denial of Service Security Considerations entry for the quorum-isolation availability asymmetry; and adds a Privacy Considerations section addressing XPID's by-design stability and cross-context linkability. No prior conformance requirement is weakened by this revision. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 4 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. Table of Contents 1. Introduction 2. Terminology 3. Trust Chain Architecture 3.1. Chain Overview 3.2. Hardware Root 3.3. Operator Root Keypair 3.4. GEC Attestation Certificate 3.5. The Kernel Is Below Cedar 4. KIA Responsibilities 4.1. Keypair Generation and Management (UPDATED in -03) 4.2. GEC Manifest Issuance 4.3. Event Log Signing 4.4. Revocation Registry Maintenance 4.5. Agent-Kernel Mutual Authentication 4.6. Federation Attestation 5. GEC Manifest (UPDATED in -03) 5.1. Purpose 5.2. Schema (UPDATED in -03; RESTORED in -06) 5.3. Issuance Triggers 5.4. Staleness 5.5. PTD Consistency Requirement 6. XPID: Cross-Principal Identifier (NEW in -03) 6.1. Purpose and Design 6.2. Derivation Procedure 6.3. Cross-Instance Trust Model 6.4. Revocation Gap (OQ-S-XPID-REV) 6.5. CAEP Propagation for Revocation 6.6. Evidence Visibility to Unintended Verifiers (OQ-KIA-EVIDENCE-VIS) (NEW in -05) 7. Event Log Signing (INV-9) 7.1. Scope 7.2. Canonical Form 7.3. Signed Event Classes 8. Revocation Registry (INV-11) 8.1. Structure 8.2. Rebuild on Restart 8.3. Revocation Authority 8.4. Agent Revocation Prohibition 9. Policy Change Attestation (INV-10) 10. Federation and Cross-Instance Verification 11. GEC as RATS Attester 12. Relationship to WIMSE 13. Conformance 14. Open Issues 14.1. OQ-S-18: Deployment Topology 14.2. OQ-S-19: Agent Runtime Attestation Profile 14.3. OQ-S-XPID-REV: XPID Revocation Gap (NEW in -03) 14.4. OQ-KIA-EVIDENCE-VIS: Evidence Visibility to Unintended Verifiers (NEW in -05) 15. Security Considerations 15.1. Private Key Extraction 15.2. GEC Manifest Forgery 15.3. Policy Hash Manipulation 15.4. Revocation Registry Incompleteness 15.5. Cascade Revocation Race 15.6. Implementation Degradation 15.7. Agent Session Revocation 15.8. FROST Nonce Reuse Risk (NEW in -03) 15.9. XPID Revocation Gap (Known Open Issue) (NEW in -03) 15.10. Identity Takeover via Claimed Identifier -- CVE-2025-13609 Class Defense (NEW in -03) 15.11. Attestation Channel Binding -- CVE-2026-33697 Class Defense (NEW in -03) 15.12. Evidence Visibility to Unintended Verifiers (Known Open Issue) (NEW in -05) 15.13. Denial of Service via Quorum Isolation (NEW in -06) 16. Privacy Considerations (NEW in -06) 16.1. XPID Linkability 16.2. Access Scoping 16.3. Rotation vs. Correlation Tradeoff 17. IANA Considerations (UPDATED in -04) 18. Normative References (UPDATED in -03) 19. Informative References (UPDATED in -03) Appendix B. Related Work B.1. RATS Architecture (RFC 9334) B.2. WIMSE B.3. SPIFFE / SPIRE B.4. SCITT B.5. TCG TPM and Hardware Attestation B.6. SOOS Companion Drafts (UPDATED in -03) Appendix C. Vibe Coding Assets (UPDATED in -06) Appendix D. Changes from Previous Versions (NEW in -04) Acknowledgements Author's Address 1. Introduction Every GEC event -- every state transition, every mandate revocation, every human escalation and resolution, every session boundary -- is signed by the GEC keypair. Without this signing, there is no audit trail integrity: any party with write access to the Event Log could inject or modify events without detection. Without the trust chain anchoring that keypair to a hardware root and operator identity, there is no basis for a verifying party to trust the signed entries. A Governing Enforcement Component (GEC) is the enforcement kernel in a governed agentic AI system: the component that evaluates Cedar policies, executes XState state machines, and commits every state transition to an append-only, signed Event Log. The GEC is the enforcement physics of the system. KIA defines what it means for a GEC to have a verifiable cryptographic identity. The Sovereign Object OS (SOOS) is the reference implementation of the GEC pattern; all normative examples in this document use SOOS terminology. Any implementation conforming to the Cedar + XState + append-only Event Log pattern MAY claim KIA conformance. This document specifies three things: (1) The KIA trust chain: from hardware root to operator root keypair to GEC Attestation Certificate to GEC keypair to Event Log signatures. (2) The GEC Manifest: a signed attestation of the GEC's runtime state, issued at deployment and reissued on every policy change (INV-10). (3) The Revocation Registry maintenance requirements (INV-11): the kernel-maintained index of revoked mandate JWT IDs. The GEC is a RATS Attester as defined in [RFC9334]. This is a normative declaration: KIA implements the RATS Attester role for governance execution kernels. The GEC Manifest is RATS Evidence extended with SOOS-specific fields (Section 5.2). A critical architectural principle governs KIA's position in the SOOS stack: the GEC is not above Cedar -- it is below Cedar. Cedar is one of the tools the kernel uses. KIA grounds the kernel's identity anchor in the operator root keypair and the hardware attestation layer beneath it. Version -02 completed the GEC Manifest schema with five RATS Evidence extension fields, the PTD Consistency Requirement (CONF-KIA-15), and the PTD endpoint discovery mechanism. Version -03 adds FROST threshold signing for high-availability GEC keypair deployments (Section 4.1); the Cross-Principal Identifier (XPID) for cross-instance federation audit correlation (Section 6); the XPID cross-instance trust model including the revocation gap open issue OQ-S-XPID-REV (Section 6.4); and four new Security Considerations (Sections 15.8 through 15.11): FROST nonce reuse risk, XPID revocation gap, CVE-2025-13609 class defense (identity takeover via claimed identifier), and CVE-2026-33697 class defense (attestation channel binding). This document is the reference specification for the KIA presentation to the RATS WG at IETF 126 Vienna (July 18-24, 2026). The XPID primitive (Section 6) and the CVE-2026-33697 attestation channel binding defense (Section 15.11) are the primary novel contributions presented. The RATS WG speaking request references this document as the SOOS KIA + GAR architecture overview (coordination with Ned Smith). Further information: https://soosproject.ai/drafts/kia 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. 2. Terminology Attester An entity that produces Evidence about its own trustworthiness, as defined in [RFC9334]. In SOOS, the GEC is the Attester. This is a normative claim: KIA implements the RATS Attester role. Endorser An entity that vouches for the Attester by producing Endorsements, as defined in [RFC9334]. In SOOS, the operator root keypair holder is the Endorser. The GEC Attestation Certificate (Section 3.4) is the RATS Endorsement. Evidence The signed claims produced by an Attester, as defined in [RFC9334]. In SOOS, the GEC Manifest is the Evidence, extended with SOOS governance-specific fields (Section 5.2). Relying Party An entity that consumes Attestation Results and makes trust decisions, as defined in [RFC9334]. In SOOS: agents verifying kernel authenticity before submitting mandates; external audit consumers; federated kernel instances. Verifier An entity that appraises Evidence and produces Attestation Results, as defined in [RFC9334]. In the standard SOOS model, verification is performed inline by the Relying Party directly against the GEC Manifest. A separate Verifier service is not required but MAY be deployed for high-assurance environments. KIA Kernel Identity and Attestation. The Layer 0 SOOS component that generates and manages the GEC keypair, issues Kernel Manifests, signs all Event Log entries, and maintains the Revocation Registry. Kernel Keypair An Ed25519 [RFC8037] keypair generated by KIA at deployment initialisation. The private key MUST remain inside the secure element for the kernel's operational lifetime. The public key is published in the GEC Manifest and GEC Attestation Certificate. GEC Manifest A signed document issued by KIA declaring the GEC's current runtime state: SOOS conformance version, keypair fingerprint, loaded Cedar policy set hashes, SO Type Registry hash, XState definition hashes, and RATS Evidence extension fields (Section 5.2). GEC Attestation Certificate A certificate issued by the operator root keypair over the kernel keypair fingerprint, binding the GEC's cryptographic identity to the operator's identity at deployment time. Operator Root Keypair A human-held, hardware-backed Ed25519 keypair held by the operator. The private key MUST never be held by the kernel process. This keypair signs the GEC Attestation Certificate and is the human authority anchor for the SOOS deployment. Revocation Registry A kernel-maintained in-memory index of all revoked mandate JWT IDs (jti values), rebuilt from the Event Log on kernel restart. Policy Governance Kernel The kernel subsystem responsible for committing Cedar policy set changes to the GEC runtime. A policy set change by the Policy Governance Kernel is the trigger for GEC Manifest reissuance (INV-10). Secure Element A hardware security module (HSM), Trusted Platform Module (TPM), or equivalent hardware-backed key storage device from which private key material cannot be exported. FROST: Flexible Round-Optimized Schnorr Threshold Signatures [FROST]. A threshold signing protocol that allows a cluster of t-of-n participants to produce an Ed25519-compatible Schnorr signature without any single participant holding the full private key. In SOOS, FROST enables high-availability GEC deployments where no single node holds the complete GEC signing key. XPID (Cross-Principal Identifier): A UUID-v5 value derived deterministically from the GEC's kernel_keypair_fingerprint (the SHA-256 fingerprint of the GEC's Ed25519 public key, or of the FROST threshold public key in FROST deployments -- see Section 6.2) and the agent's Party Registry entry. The XPID is a stable, globally unique identifier for an agent across multiple GEC instances in a federation. It enables bilateral audit correlation across trust boundaries without a trusted third party. See Section 6. Threshold Keypair: In FROST deployments, the GEC signing key is held as t-of-n secret shares distributed across a signing cluster. No single node holds the full private key. The corresponding public key is a single Ed25519-compatible point. All existing SOOS signing requirements apply to the threshold keypair; the distinction is in how the private key is held, not how signatures are produced or verified. Signing Cluster: The set of n GEC signing participants that collectively hold the threshold keypair. The signing cluster must reach quorum (t participants) to produce a valid signature. 3. Trust Chain Architecture 3.1. Chain Overview The KIA trust chain is a directed sequence of signing relationships. Each layer is signed by or derives authority from the layer above it. The chain is: Hardware root (TPM / HSM) | v Operator root keypair (human-held, hardware-backed RECOMMENDED) | v GEC Attestation Certificate (operator signs GEC keypair fingerprint at deployment) | v GEC Manifest (kernel signs its own runtime state: Cedar hashes, SO Type Registry hash, XState definition hashes) | v Event Log entries (kernel signs each event with the GEC keypair -- INV-9) | v Cedar evaluations (kernel evaluates every transition; Cedar is below the signing layer and above the state machine) | v Sovereign Objects (kernel governs all state transitions on all SOs) | v Agents (mandate JWTs issued under Party Registry authority; mandate validity checked at Step 1 of every transition) The critical invariant is that no signing relationship flows upward. An agent cannot sign on behalf of the kernel; the kernel cannot sign on behalf of the operator root; the operator root cannot sign on behalf of the hardware root. Compromise at any layer is detectable by verifying the chain from above. (UPDATED in -03) The FROST threshold keypair (Section 4.1) fits within this chain at the "Operator root keypair -> GEC Attestation Certificate -> GEC keypair" link: in FROST deployments, the "GEC keypair" is the threshold public key derived from the FROST signing cluster. The trust chain structure above is otherwise unchanged; Section 4.1 specifies how the GEC keypair layer is realized as a threshold keypair. 3.2. Hardware Root The hardware root is a TPM 2.0-compliant device, HSM, or equivalent hardware security device providing: (a) Non-exportable key generation and storage. (b) Platform measurement (PCR values or equivalent) establishing that the GEC software is running in an expected state. (c) Attestation of the hardware-backed status of the operator root keypair and the GEC keypair. Where the deployment environment does not support hardware-backed key storage, the implementation MUST document this as a deployment constraint in the GEC Manifest (Section 5.2) and SHOULD surface this as a conformance warning to operators. 3.3. Operator Root Keypair The operator root keypair is the human authority anchor of the SOOS deployment. It is held by the operator, not by the GEC process. Requirements: (a) The operator root private key MUST NOT be accessible to the kernel process. (b) The operator root private key SHOULD be held in a hardware- backed secure element. (c) The operator root keypair is used for exactly two purposes: (i) Signing the GEC Attestation Certificate at deployment. (ii) Issuing MANDATE_REVOKED events (INV-11). (d) The operator root public key fingerprint MUST appear in the GEC Manifest (Section 5.2) as the operator_identity field. 3.4. GEC Attestation Certificate The GEC Attestation Certificate is issued by the operator root keypair at kernel deployment time. It binds the GEC's cryptographic identity to the operator's identity. The GEC Attestation Certificate MUST contain: kernel_keypair_fingerprint SHA-256 of the Ed25519 public key generated by KIA at deployment. operator_identity The operator root public key fingerprint. deployment_timestamp ISO-8601 timestamp of issuance. soos_version The SOOS conformance version the kernel is attesting to. hardware_backed Boolean: TRUE if the GEC keypair is stored in a hardware secure element; FALSE otherwise. operator_signature Ed25519 signature over the canonical JSON of the above fields, by the operator root keypair. The GEC Attestation Certificate is embedded in the GEC Manifest (Section 5.2, attestation_certificate field). 3.5. The Kernel Is Below Cedar A core architectural principle of KIA is that the GEC's identity and authority do not depend on Cedar. Cedar evaluates policies that the kernel enforces. KIA grounds the GEC's identity in the hardware root and operator keypair, both of which are established before Cedar policy evaluation begins. This means: (a) Cedar DENY on a proposed transition does not prevent the kernel from signing a CEDAR_DENY Event Log entry. The signing happens regardless of the Cedar result. INV-9 is unconditional. (b) A Cedar policy change does not invalidate historical Event Log entries. The GEC Manifest reissuance (INV-10) records the policy change; historical entries carry the cedar_policy_ref field identifying which policy set was active at evaluation time. (c) A compromised Cedar policy set cannot forge kernel signatures. The GEC keypair is independent of the Cedar policy layer. 4. KIA Responsibilities 4.1. Keypair Generation and Management (UPDATED in -03) Standard (non-FROST) deployments: At deployment initialisation, KIA MUST: (a) Generate an Ed25519 keypair. (b) Store the private key in a hardware secure element where available. The private key MUST NOT be exported from the secure element under any circumstances. (c) Register the public key fingerprint (SHA-256) with the operator for inclusion in the GEC Attestation Certificate. (d) Issue the initial GEC Manifest once the GEC Attestation Certificate has been received from the operator. FROST threshold deployments (HA option): (NEW in -03) As an alternative to single-keypair deployments, KIA-03 normatively supports FROST threshold signing [FROST] for high- availability (HA) deployments where the GEC keypair must survive individual signing node failures. In a FROST deployment: (a) A FROST key generation ceremony MUST be conducted by the n signing cluster participants. The ceremony produces n secret shares (one per participant) and a single threshold public key. No single participant, including the ceremony coordinator, learns the full private key. (b) Each participant's secret share MUST be stored in a hardware secure element on that participant's signing node. Secret shares MUST NOT be exported from their respective secure elements. (c) The threshold public key is registered with the operator as the GEC keypair. The GEC Attestation Certificate is issued over the threshold public key fingerprint, not over any individual share. (d) The GEC Manifest is signed by the FROST threshold signing cluster. The resulting signature is a single Ed25519- compatible Schnorr signature verifiable against the threshold public key. External verifiers are not required to know whether the deployment is FROST or single-key. FROST nonce generation requirements: CONF-KIA-16: In FROST deployments, each signing participant MUST generate a fresh cryptographically secure nonce for every signing operation. Nonces MUST NOT be reused across signing operations. CONF-KIA-17: Implementations using FROST MUST comply with the nonce generation procedure specified in Section 5.1 (Round One -- Commitment) and the nonce_generate helper function in Section 4.1 of [FROST]. Implementations MUST NOT cache or pre-generate nonce sets for batch signing. Quorum failure behavior: CONF-KIA-18: If the FROST signing cluster falls below quorum (fewer than t participants are available), the GEC MUST refuse to sign any Event Log entry, GEC Manifest, or other KIA artifact. The GEC MUST NOT degrade to single-signer operation. CONF-KIA-19: When a quorum failure occurs, the GEC MUST emit a KERNEL_AUDIT_ANOMALY alert in the GAR system and MUST surface the quorum failure condition to the operator through the designated notification channel. CONF-KIA-24: (NEW in -06) CONF-KIA-18 and CONF-KIA-19 interact at the exact moment of a quorum failure: CONF-KIA-18 forbids signing any KIA artifact below quorum, while CONF-KIA-19 requires emitting a KERNEL_AUDIT_ANOMALY alert -- and every other KIA artifact type is GEC-signed as a matter of course. Read together without qualification, these two requirements are unsatisfiable in combination: the alert meant to report "I cannot currently sign" would itself need to be signed. This is resolved as follows. The KERNEL_AUDIT_ANOMALY alert required by CONF-KIA-19 is a named, narrow exception to CONF-KIA-18: it MUST be signed by whatever subset of the signing cluster is available at the time of the quorum failure, even when that subset is below the threshold t. A below-threshold signature on a KERNEL_AUDIT_ANOMALY alert is not a violation of CONF-KIA-18's single-signer prohibition, is valid only for this one artifact type, and MUST NOT be treated by any verifier as authorizing any other KIA artifact. If fewer than two participants are available (so that no signature of any kind, threshold or otherwise, can be produced), the alert MUST instead be delivered unsigned through the "designated notification channel" of CONF-KIA-19, which is understood to be distinct from -- and does not require signing through -- the GAR system. This is structurally analogous to [SOOS-GAR]'s R-8 external-signing carve-out ("a compromised kernel cannot self-attest its own recovery"): the artifact that reports an inability to meet the normal signing bar is itself exempted from that bar. CONF-KIA-20: A reduced quorum resulting from signing cluster partial failure MUST NOT reduce the threshold parameter (t) below the value established at the initial FROST key generation ceremony. Threshold reduction requires a new key generation ceremony and a new GEC Attestation Certificate. XPID derivation in FROST deployments: In FROST deployments, the XPID (Section 6.2) is derived from the threshold public key fingerprint, not from any individual participant's share. This ensures that the XPID is stable across signing cluster membership changes within the same threshold keypair lifecycle. GEC Manifest declaration for FROST: FROST deployments MUST declare their threshold configuration in the deployment_constraints[] field of the GEC Manifest (Section 5.2): "frost:t-of-n:-" where t is the signing threshold and n is the total number of participants. Example: "frost:t-of-n:3-5" declares a 3-of-5 FROST signing cluster. The hardware_backed field MUST be true if all n participants' secret shares are stored in hardware secure elements. If any participant uses software key storage, hardware_backed MUST be false. 4.2. GEC Manifest Issuance KIA MUST issue a GEC Manifest: (a) At deployment initialisation, after receiving the Kernel Attestation Certificate from the operator. (b) On every policy set change committed by the Policy Governance Kernel (INV-10). (c) On GEC keypair rotation. The GEC Manifest schema is specified in Section 5.2. 4.3. Event Log Signing KIA MUST sign every Event Log entry with the GEC keypair (INV-9). This requirement applies without exception to all event types. An Event Log entry that does not carry a valid kernel_signature field MUST be treated as invalid by any verifying party. An invalid entry MUST NOT be used as evidence in audit, federation, or dispute resolution. The signing procedure is specified in Section 7. 4.4. Revocation Registry Maintenance KIA MUST maintain the Revocation Registry: an in-memory index of all mandate JWT IDs (jti values) that appear in any MANDATE_REVOKED event in the Event Log (INV-11). KIA MUST rebuild the Revocation Registry from the Event Log on kernel restart before processing any mandate presentations. KIA MUST check the Revocation Registry at Step 1 of every kernel execution sequence. A mandate whose jti appears in the Revocation Registry MUST be REJECTED. The Revocation Registry is specified in Section 8. 4.5. Agent-Kernel Mutual Authentication KIA SHOULD support an agent-kernel mutual authentication handshake before mandate presentation. The handshake allows the agent to verify the GEC's identity (via the GEC Manifest) and the kernel to verify the agent's identity (via the agent's Party Registry keypair) before the agent submits a mandate JWT. For Class 2 and Class 3 agents (as defined in draft-sato-soos-idp-05 Section 6.4), this handshake SHOULD be performed at session initialisation. For Class 1 agents, the handshake is OPTIONAL. The mutual authentication handshake protocol is: (1) Agent requests the current GEC Manifest from the kernel API endpoint. (2) Agent verifies the GEC Manifest signature against the kernel public key fingerprint it holds (obtained via operator provisioning or prior GEC Manifest). (3) Agent verifies the attestation_certificate in the GEC Manifest against the operator root public key. (4) Kernel verifies the agent's Ed25519 public key against the Party Registry. (5) Both parties proceed to mandate presentation. This handshake does not replace mandate validation at Step 1 of the kernel execution sequence. It is an optional pre-validation step that allows well-behaved Class 2 and Class 3 agents to abort before mandate presentation if the GEC's attestation state is unexpected (e.g., stale GEC Manifest, unexpected Cedar policy set hashes). 4.6. Federation Attestation When a GEC instance presents Event Log entries or claims to a second GEC instance, the receiving kernel MUST verify the presenting kernel's identity and attestation state before accepting cross-instance events. The verification protocol is: (1) The receiving kernel requests the presenting kernel's current GEC Manifest. (2) The receiving kernel verifies the GEC Manifest signature against the presenting kernel's public key fingerprint. (3) The receiving kernel verifies the attestation_certificate in the GEC Manifest against the presenting operator's root public key (obtained via operator-to-operator provisioning). (4) The receiving kernel checks that the soos_conformance_version in the presenting kernel's GEC Manifest is compatible with the receiving kernel's version. (5) If all checks pass, the receiving kernel MAY accept signed Event Log entries from the presenting kernel for cross-instance audit and federation purposes. The cross-instance federation protocol (what is exchanged and under what conditions) is out of scope for this document. This section specifies only the KIA attestation requirements that federation depends on. 5. GEC Manifest 5.1. Purpose The GEC Manifest is the primary attestation document of a SOOS kernel instance. It serves three purposes: (a) Agent trust establishment: an agent verifies the GEC Manifest before submitting mandates to establish that it is communicating with a genuine, conforming GEC. (b) Operator auditability: the GEC Manifest records which Cedar policy sets and XState definitions are loaded, enabling operators to verify that the GEC is running the expected governance configuration at any point in time. (c) Federation: a receiving kernel instance verifies the presenting kernel's GEC Manifest before accepting cross-instance events (Section 4.6). (d) PTD anchor: the GEC Manifest carries the ptd_endpoint field and the cedar_policy_hash that enable external parties to discover and verify the GEC's Policy Transparency Disclosure (PTD) per [SOOS-CAP] Section 12a. The GEC Manifest is the authoritative discovery mechanism for PTD endpoint location (OQ-PTD-01 resolved). 5.2. Schema (UPDATED in -03; RESTORED in -06 -- see below) (RESTORED in -06) Seven fields present in -02's schema -- manifest_version, manifest_id, issued_at, soos_conformance_version, cedar_policy_set_hashes[], so_type_registry_hash, and xstate_definition_hashes[] -- along with attestation_certificate, were silently absent from -03 through -05 despite -03's text claiming the -02 schema was "carried forward in full." This pass restores them. attestation_certificate in particular is load-bearing for Section 15.11's CVE-2026-33697 defense, which already assumed its presence. See Appendix D.1 for the full account. GecManifest { manifest_version The schema version of this GEC Manifest document. Fixed at "1.0" for this specification. manifest_id UUID v4, kernel-assigned. Unique per issuance event. issued_at ISO-8601 timestamp of GEC Manifest issuance. soos_conformance_version The SOOS specification version this kernel is conforming to. Implementations MUST populate this field. kernel_keypair_fingerprint SHA-256 of the GEC's Ed25519 public key (non-FROST) or FROST threshold public key (FROST deployments). This field is the primary GEC instance identifier used by: (a) MJWT aud claim binding: the MJWT aud claim MUST equal this fingerprint. External systems constructing MJWTs MUST retrieve this value from the GEC Manifest via the kernel API endpoint. (b) XPID derivation (Section 6.2): the XPID is derived from this fingerprint concatenated with the agent's Party Registry entry hash. (c) Event Log signing verification: verifiers of Event Log entries use this field as the key fingerprint against which kernel_signature fields are verified. (d) GAR audit record correlation: every GAR audit record entry carries this fingerprint as the soos.governance. kernel_id attribute, enabling cross-session audit record assembly. (CLARIFIED in -03; unchanged in -06) operator_identity SHA-256 fingerprint of the operator root Ed25519 public key. cedar_policy_set_hashes[] An array of objects, one per loaded Cedar policy set: { policy_set_id, version, sha256 }. The sha256 is computed over the canonical serialisation of the policy set. This field changes on every policy set change, triggering INV-10 GEC Manifest reissuance. so_type_registry_hash SHA-256 of the current SO Type Registry content. Changes when SO Type definitions are added, updated, or deprecated. xstate_definition_hashes[] An array of objects, one per loaded XState definition: { so_type_id, sha256 }. The sha256 is computed over the canonical serialisation of the XState definition. deployment_timestamp ISO-8601 timestamp of kernel deployment initialisation. Immutable across GEC Manifest reissuances for the same deployment lifetime. hardware_backed Boolean. TRUE if the GEC keypair is stored in a hardware secure element. FALSE if software key storage is used. MUST be set accurately; false attestation is a conformance violation. attestation_certificate The GEC Attestation Certificate (Section 3.4), embedded in full. This binds the GEC keypair fingerprint to the operator identity. ptd_endpoint URI at which the GEC's Policy Transparency Disclosure (PTD) is available. REQUIRED. Resolves OQ-PTD-01: PTD endpoint discovery is via this field in the GEC Manifest. External parties -- regulators, auditors, Verified External Auditors -- MUST use this endpoint to retrieve the current signed PTD for this GEC instance. The URI SHOULD use the HTTPS scheme. The endpoint MUST serve a response conforming to [SOOS-CAP] Section 12a.4. ptd_current_version String. The version string of the PTD currently served at ptd_endpoint. This field is distinct from ptd_version in the PTD itself: ptd_current_version in the GEC Manifest is the Manifest's record of the current PTD version, enabling Relying Parties to detect PTD staleness without fetching the full PTD document. REQUIRED when ptd_endpoint is present. loaded_policy_ids[] Array of cmr:// URIs. CAP-RRS Regulation Record IDs currently active in the GEC's CMR evaluation set. MUST be populated; empty array is valid for deployments with no active CAP-RRS Regulation Records. RATS Evidence extension field (Section 11). cedar_policy_hash SHA-256 string. Single digest over the full compiled Cedar policy set. Summary field complementing the per-set cedar_policy_set_hashes[] array. Relying Parties performing policy-state comparison SHOULD use this field for a fast equality check before inspecting per-set hashes. RATS Evidence extension field (Section 11). kernel_version String (semver). SOOS KernelSpec implementation version (e.g., "3.0.0"). Distinct from soos_conformance_version, which identifies the specification version; kernel_version identifies the implementation version. Relying Parties performing version-gating SHOULD check this field. RATS Evidence extension field (Section 11). attestation_timestamp ISO-8601 UTC timestamp. Moment of GEC Manifest issuance. Relying Parties SHOULD verify freshness; the recommended maximum staleness for production deployments is 86400 seconds (24 hours), per Section 5.4. RATS Evidence extension field (Section 11). deployment_constraints[] Array of strings. OPTIONAL; absent (not null) when no constraints apply. An absent field and an empty array are semantically equivalent; implementations SHOULD omit the field rather than include an empty array. Informative. Records deployment constraints that affect KIA security properties; does not affect conformance. RATS Evidence extension field (Section 11). Recommended values: "vtpm:azure-confidential-vm" "vtpm:aws-nitro-enclave" "vtpm:gcp-confidential-compute" "software-key-storage" "shared-keypair:multi-region" "frost:t-of-n:-" (NEW in -03 -- FROST deployment marker, Section 4.1) xpid_derivation_version (NEW in -03; value set updated in -06) String (semver). The version of the XPID derivation algorithm (Section 6.2) implemented by this GEC instance. REQUIRED. Current normative value: "1.1". "1.0" remains a valid declared value for GECs deriving XPIDs against the superseded standard-DNS-namespace procedure, for backward compatibility with pre-(-06) audit history (Section 6.2). External parties computing the XPID for federation or audit correlation MUST use the algorithm version declared in this field. A GEC that does not implement XPID MUST set this field to "none". manifest_signature Ed25519 signature over the canonical JSON of all preceding fields, including ptd_endpoint, ptd_current_version, the RATS Evidence extension fields (loaded_policy_ids[], cedar_policy_hash, kernel_version, attestation_timestamp), deployment_constraints[] if present, and xpid_derivation_version, computed by the GEC keypair. } 5.3. Issuance Triggers A new GEC Manifest MUST be issued on each of the following events: (a) Deployment initialisation (initial manifest). (b) Policy Governance Kernel commits a Cedar policy set change. The new GEC Manifest MUST carry the updated cedar_policy_set_hashes[] and cedar_policy_hash reflecting the new policy set. (INV-10) (c) SO Type Registry update (addition, modification, or deprecation of an SO Type definition). (d) XState definition update for any loaded SO Type. (e) Kernel keypair rotation. 5.4. Staleness INV-10: A stale GEC Manifest constitutes a KIA attestation failure. A GEC Manifest is stale if the Policy Governance Kernel has committed a policy set change and the GEC Manifest has not been reissued with the updated cedar_policy_set_hashes[]. The GEC MUST reissue the GEC Manifest before processing any kernel.transition() calls that would be governed by the new policy set. A kernel that processes transitions under a new Cedar policy set before reissuing the GEC Manifest is non-conforming. Note: staleness is a liveness property of the GEC Manifest, not a security property of the Event Log. Event Log entries signed before a policy change remain valid under the prior cedar_policy_ref field. The recommended maximum staleness for production deployments, measured against attestation_timestamp, is 86400 seconds (24 hours) -- see MANIFEST_STALENESS_LIMIT_SECONDS in the reference implementation and Section 6.4(c) for the federation-gating use of this limit. 5.5. PTD Consistency Requirement The cedar_policy_hash in the GEC Manifest and the cedar_policy_hash in the PTD served at ptd_endpoint MUST be identical at any given moment. This consistency requirement is the cryptographic anchor that makes the PTD verifiable. A Relying Party performing a PTD consistency check MUST: (a) Retrieve the current GEC Manifest. (b) Retrieve the current PTD from ptd_endpoint. (c) Verify that cedar_policy_hash in the GEC Manifest equals cedar_policy_hash in the PTD. (d) Verify the PTD's ptd_signature against the GEC keypair fingerprint from the GEC Manifest. If step (c) fails, the PTD is inconsistent with the GEC Manifest. The GEC MUST generate CAP_TRANSPARENCY_VIOLATION [SOOS-CAP] Section 12a.6 if this condition is detected by the kernel's own self-consistency check. The gec_instance_id field in the PTD is equal to the kernel_keypair_fingerprint in the GEC Manifest. Relying Parties MUST verify this equality as part of the PTD consistency check to confirm the PTD was issued by the GEC whose Manifest they hold. Note on terminology: ptd_version (in the PTD) is the PTD document's own monotonically increasing version. ptd_current_version (in the GEC Manifest) is the Manifest's record of that version. These are intentionally distinct fields: one is the PTD's self-declaration; the other is the Manifest's pointer. Both MUST reflect the same PTD generation event. CONF-KIA-15 (see Section 13) enforces this requirement normatively. 6. XPID: Cross-Principal Identifier (NEW in -03) 6.1. Purpose and Design The Cross-Principal Identifier (XPID) is a UUID-v5 value that provides a stable, cross-instance identifier for an agent within a KIA-governed federation. The XPID solves the following problem: When an agent with a valid mandate operates across multiple GEC instances -- for example, in a federated deployment where an agent session migrates from one kernel instance to another, or where a monitoring kernel and an execution kernel both govern the same agent -- the agent's identity needs to be correlated across kernel boundaries without requiring direct inter-kernel communication or a trusted third party. The XPID provides this correlation. It is derived deterministically from inputs available to any GEC instance that has verified the agent's Party Registry entry and the GEC's own identity. Design properties: (a) Deterministic: any GEC with the inputs can compute the XPID. No coordination between GEC instances is required. (b) Stable: the XPID does not change within the lifetime of the agent's Party Registry entry and the GEC deployment's keypair. (c) Immutable: once derived, the XPID cannot be modified by the agent, by the operator, or by any external party without invalidating the derivation. (d) Non-forgeable without key material: an attacker cannot construct a valid XPID for an agent without possessing either the GEC's FROST key shares or the agent's Party Registry private key. See Section 15.10 for the CVE-2025-13609 class defense analysis. The XPID is recorded in GAR audit entries as the soos.governance. xpid attribute. It enables regulators and auditors to follow an agent's governance trail across GEC instance boundaries without requiring the kernel to expose the full Session Audit Record to cross-instance parties. 6.2. Derivation Procedure XPID derivation version 1.1 uses UUID version 5 (name-based, SHA-1 namespace) as defined in [RFC9562] Section 5.5. The derivation inputs are: (a) namespace: the KIA XPID namespace UUID: "447994dc-9ddf-578f-a851-3a77d8f7ae42". This is a dedicated namespace UUID minted for KIA, itself computed as UUID5(NAMESPACE_URL, "https://soosproject.ai/drafts/kia/ xpid-namespace") per [RFC9562] Section 6.5's guidance that new applications mint a dedicated namespace UUID rather than reuse one of the predefined namespaces (DNS, URL, OID, X.500) for an unrelated purpose. (UPDATED in -06: derivation version 1.0, defined in -03 through -05, reused the standard DNS UUID namespace ("6ba7b814-9dad-11d1-80b4-00c04fd430c8") for a name string that was not itself a DNS name. That reuse is a theoretical but avoidable identifier-space collision surface with unrelated UUID5(DNS_NAMESPACE, ...) computations; it does not weaken the security properties in Section 6.1, but implementations SHOULD move to version 1.1. A GEC MAY continue to compute version 1.0 XPIDs for backward-compatible correlation against pre-(-06) audit history, but MUST declare "1.0" rather than "1.1" in xpid_derivation_version when doing so.) (b) name: the concatenation of: - kernel_keypair_fingerprint (the GEC's Ed25519 or FROST threshold public key SHA-256 fingerprint, as a hex string) - ":" (separator) - party_registry_entry_hash (SHA-256 of the agent's canonical Party Registry entry, as a hex string) Procedure: XPID = UUID5(namespace, kernel_keypair_fingerprint + ":" + party_registry_entry_hash) The party_registry_entry_hash is computed over the canonical JSON of the agent's Party Registry entry, using the same canonical JSON rules as for Event Log signing (Section 7.2). CONF-KIA-21: A GEC MUST derive the XPID using the procedure specified in this section. Implementations MUST NOT accept a client-supplied XPID as authoritative. The XPID MUST be derived or verified by the issuing GEC's signing layer. CONF-KIA-22: A GEC MUST record the XPID in every GAR audit entry for the agent session for which it was derived. The XPID MUST appear as the soos.governance.xpid attribute in every governance span. 6.3. Cross-Instance Trust Model When a receiving GEC instance encounters a GAR audit entry carrying an XPID from a presenting GEC instance: (a) The receiving GEC MUST obtain the presenting GEC's kernel_ keypair_fingerprint from the presenting GEC's verified GEC Manifest (per Section 4.6 federation attestation). (b) The receiving GEC MUST obtain the agent's Party Registry entry from the presenting GEC's Party Registry (via the operator-provisioned federation channel) or from a shared Party Registry if one is deployed. (c) The receiving GEC MUST recompute the XPID using the procedure in Section 6.2 and verify that the result matches the XPID in the received GAR audit entry. (d) A XPID that does not verify MUST be treated as an invalid audit entry. The receiving GEC MUST log XPID_VERIFICATION_FAILED in its own Event Log. CONF-KIA-23: Federated kernels MUST validate the mandate JWT jti against their local Revocation Registry (not solely the XPID) before accepting cross-instance agent events. The XPID is a correlation identifier, not a trust assertion: a valid XPID does not imply a non-revoked mandate. 6.4. Revocation Gap (OQ-S-XPID-REV) (NEW in -03) A known open issue exists regarding XPID revocation. When an agent's mandate is revoked via the MAD session revocation procedure [SOOS-MAD], the XPID value itself is not invalidated -- only the mandate JWT jti is added to the Revocation Registry (Section 8). In a multi-kernel federation where XPID values are shared across kernel boundaries, a revoked agent's XPID may still be presented to a receiving kernel that has not yet received the revocation signal. This gap is acknowledged as a known open issue (OQ-S-XPID-REV). See also Section 14.3 and Section 15.9. Interim mitigations available in the current architecture: (a) Revocation Registry precedence. Federated kernels MUST validate the mandate JWT jti against their local Revocation Registry before accepting any cross-instance agent events. A stale XPID from a revoked agent carries a revoked jti; the jti check catches the revocation even if the XPID check cannot. CONF-KIA-23 enforces this requirement. (b) CAEP revocation stream subscription. Federated kernels SHOULD subscribe to the originating kernel's CAEP revocation signal stream [SOOS-MAD] to receive propagated revocation events in near-real time. Section 6.5 specifies the CAEP propagation model. (c) GEC Manifest staleness bounds. GEC Manifest staleness limits (Section 5.4, recommended maximum staleness 86400 seconds) bound the window during which a stale cross- instance trust relationship can be exploited. A receiving kernel MUST NOT accept federation events from a presenting kernel whose GEC Manifest has exceeded the staleness limit. Resolution of OQ-S-XPID-REV is deferred to a KIA successor document addressing the federated revocation protocol. 6.5. CAEP Propagation for Revocation When a mandate revocation event occurs on a presenting GEC instance, the presenting GEC SHOULD propagate the revocation signal to all subscribed receiving GEC instances via the Continuous Access Evaluation Protocol (CAEP) [CAEP] over the Shared Signals Framework (SSF) [RFC9672]. The CAEP revocation event for XPID-bearing mandates MUST include: { "event_type": "mandate_revoked", "subject": { "format": "xpid", "xpid": "" }, "jti_revoked": "", "revocation_type": "direct" | "cascade", "cascade_root_mandate_id": "", "originating_kernel": "", "revoked_at": "" } Field names use lowercase per the external-facing SSF/CAEP wire convention (this event travels the same transport family as the Mandate Lifecycle Events (MLE) profile's own mandate-revoked event, and uses matching field names -- revocation_type, cascade_root_mandate_id -- so a receiving party already consuming MLE recognizes the shape). This is distinct from Section 8.1's internal RevocationRecord, which uses the Event Log's own uppercase convention (DIRECT/CASCADE) matching [SOOS-MJWT] Section 7.3 -- the same underlying fact travels under two conventions depending on whether it stays inside the kernel or crosses the wire, not two different facts. Receiving kernels that subscribe to the CAEP stream MUST process mandate_revoked events immediately and add the revoked jti to their local Revocation Registry. 6.6. Evidence Visibility to Unintended Verifiers (OQ-KIA-EVIDENCE-VIS) (NEW in -05) Section 6.3 specifies how a receiving GEC verifies an XPID it receives, but says nothing about which federation participants are able to see the underlying Evidence in the first place. In a multi-verifier federation topology -- for example, a Lead verifier that aggregates and forwards Evidence from several presenting kernels to other, downstream verifiers -- a participant may end up with structural visibility into Evidence it is not itself authorized to appraise, independent of whether the XPID binding itself is sound. `draft-ritz-seat-proxies` names this concern directly for multi-verifier RATS topologies generally; it applies to KIA's federation model without modification. This gap is acknowledged as a known open issue (OQ-KIA-EVIDENCE-VIS). See also Section 14.4 and Section 15.12. No mitigation is specified in this version. A candidate direction -- encrypting Evidence to the specific intended verifier's key, following the SEAT-proxies pattern, rather than relying solely on transport-level access control -- is noted here for a future revision, not adopted. Resolution is deferred to a KIA successor document, the same disposition as OQ-S-XPID-REV (Section 6.4). (NEW in -06) This is the same root gap as [SOOS-GAR]'s Merkle Audit Path visibility finding, surfacing independently at two different layers of the same suite: GAR's Session Block Merkle tree structure, and KIA's federation Evidence transport here. Both name `draft-ritz-seat-proxies` as the general pattern. A single cross-cutting fix addressing both instances, rather than two separate layer-specific ones, is a candidate direction for whichever KIA or GAR successor document resolves this first. 7. Event Log Signing (INV-9) 7.1. Scope INV-9: Every Event Log entry MUST be signed by the GEC keypair (KIA). An unsigned entry is not a valid Event Log entry. INV-9 applies without exception. The following table lists all event types defined across the SOOS specification suite that MUST carry a kernel_signature field: Core kernel events: STATE_TRANSITION MANDATE_REVOKED CREATE_SOVEREIGN_OBJECT SOVEREIGN_OBJECT_ARCHIVED GDPR_ERASURE_EXECUTED AEP session events: AEP_SENSE_DELIVERED AEP_SESSION_CLOSED HEM events: HEM_INVOKED HEM_RESOLVED HEM_TIMEOUT MAD cluster events (draft-sato-soos-mad): CLUSTER_DECLARED CLUSTER_MEMBER_ADDED CLUSTER_MEMBER_REMOVED CLUSTER_MERGED CLUSTER_SPLIT CLUSTER_DISSOLVED SO lifecycle events (draft-sato-soos-sov): SOVEREIGN_OBJECT_TYPE_MIGRATED SO_TYPE_VERSION_COMMITTED SO_TYPE_INHERITANCE_REGISTERED SO_TYPE_CHILD_REVALIDATION_REQUIRED XPID events (NEW in -04, registered Section 17): XPID_DERIVED XPID_VERIFICATION_FAILED 7.2. Canonical Form The kernel_signature field MUST be an Ed25519 signature over the canonical JSON form of the event. Canonical JSON is defined as: (a) All object keys sorted lexicographically. (b) No insignificant whitespace. (c) String values encoded as UTF-8. (d) The kernel_signature field excluded from the signed content (the signature is over the event object prior to the addition of the kernel_signature field). Implementations MUST use this canonical form for both signing and verification. Non-canonical signing is a conformance violation. The same canonical JSON rule is reused for XPID's party_registry_entry_hash computation (Section 6.2) and for GEC Manifest signing (Section 5.2) -- one canonicalization procedure is shared across every KIA artifact. 7.3. Signed Event Classes For clarity, this section notes the significance of INV-9 across three event classes: State transitions (STATE_TRANSITION): The kernel_signature makes every state transition on every Sovereign Object a non-repudiable, tamper-evident record. A verifier can check the full Event Log history of any SO using only the GEC public key fingerprint from the GEC Manifest. HEM events (HEM_INVOKED, HEM_RESOLVED, HEM_TIMEOUT): The HEM Escalation Request embedded in HEM_INVOKED includes the principal_signature of the deciding human principal (for HEM_RESOLVED) under the human's own Party Registry keypair. The kernel_signature wraps this: the HEM record is therefore doubly signed -- by the deciding human's keypair (authentication of the decision) and by the GEC keypair (authentication of the record). MANDATE_REVOKED: This event carries both an authority_signature (the human operator principal's signature over the revocation decision) and a kernel_signature (the GEC's signature over the complete event including the authority_signature). The double-signing ensures that neither the revocation decision nor its kernel recording can be forged independently. 8. Revocation Registry (INV-11) 8.1. Structure INV-11: A revoked mandate MUST NOT be accepted at Step 1 of the kernel execution sequence. A mandate is revoked if its jti appears in any MANDATE_REVOKED event committed to the Event Log with a valid authority_signature. The Revocation Registry is a kernel-maintained in-memory index: RevocationRegistry { revoked_jtis: Map } RevocationRecord { revoked_jti: , revocation_event_id: , revoked_at: , revocation_type: "DIRECT" | "CASCADE", cascade_root_jti: , transaction_disposition: "COMPLETE_SAFE" | "SUSPEND_ALL" | "ROLLBACK_AVAILABLE" } Field names and enum values above match [SOOS-MJWT] Section 7.3's MANDATE_REVOKED Event Stream entry exactly -- this registry and MJWT's are the same registry (Section 8's own cross-reference; see also [SOOS-MJWT] Section 7.1), so the two documents MUST use one shared vocabulary for it, not two independently-drifted ones. The Revocation Registry contains one RevocationRecord per MANDATE_REVOKED event in the Event Log. A CASCADE-type revocation does not carry an array of affected jtis on a single event; per [SOOS-MJWT] Section 7.2(b), the GEC traverses the mandate issuance tree rooted at the directly-revoked jti and writes a separate MANDATE_REVOKED entry (revocation_type: CASCADE, cascade_root_jti pointing back to the direct revocation) for each descendant. The registry is therefore populated by many events, one per affected mandate, not by expanding an array on one event. 8.2. Rebuild on Restart The Revocation Registry MUST be rebuilt from the Event Log on every kernel restart, before the GEC processes any mandate presentations. The rebuild procedure is: (1) Scan the Event Log in append order from genesis. (2) For each MANDATE_REVOKED event with a valid authority_signature and kernel_signature, add its revoked_jti to the Revocation Registry as a RevocationRecord. Because cascade expansion already happened at revocation time (each descendant mandate has its own MANDATE_REVOKED entry per Section 8.1's rebuild note), no tree traversal is needed here -- every affected jti already has a direct event to read. (3) The Revocation Registry is complete when the Event Log has been fully scanned. This follows the same rebuild pattern as the Cluster Registry defined in draft-sato-soos-mad Section 5.4. Both registries are performance projections over the Event Log, not second sources of truth. INV-7 (the Event Log is the single source of truth) applies to both. 8.3. Revocation Authority Only a human-held Party Registry principal may issue MANDATE_REVOKED events. The authority_signature field MUST be an Ed25519 signature by the revoking principal's keypair, over the canonical JSON of the revocation event (excluding the kernel_signature field). The GEC MUST verify the authority_signature field against the revoking principal's public key in the Party Registry before committing the MANDATE_REVOKED event to the Event Log. An authority_signature that does not verify MUST cause the kernel to REJECT the revocation attempt without writing any Event Log entry. 8.4. Agent Revocation Prohibition An agent MUST NOT issue MANDATE_REVOKED events. This prohibition is enforced by the Party Registry principal type check: only principals flagged as human-held in the Party Registry may sign revocation events. This prohibition is absolute. No mandate, Cedar policy, or operator configuration may grant an agent the authority to revoke mandates. Mandate revocation is a human-authority operation. (NEW in -03) The XPID does not replace jti-based revocation. CONF-KIA-23 (Section 6.3) requires that federated kernels validate the mandate jti against the local Revocation Registry independently of XPID verification. This requirement is an interim mitigation for OQ-S-XPID-REV (Section 6.4) and is normative. 9. Policy Change Attestation (INV-10) INV-10: The kernel's GEC Manifest MUST be reissued whenever the Policy Governance Kernel commits a policy set change. A stale GEC Manifest constitutes a KIA attestation failure. The policy change sequence is: (1) The operator or Policy Governance Kernel prepares a new Cedar policy set. (2) The Policy Governance Kernel commits the new policy set to the kernel runtime. (3) KIA immediately issues a new GEC Manifest with updated cedar_policy_set_hashes[] and cedar_policy_hash reflecting the new set. (4) The new GEC Manifest is published to the kernel API endpoint. (5) Subsequent kernel.transition() calls are evaluated under the new policy set, with the new cedar_policy_ref field in the STATE_TRANSITION event. Steps 3 and 5 MUST be atomic with respect to each other: the kernel MUST NOT evaluate transitions under the new policy set before issuing the new GEC Manifest, and MUST NOT issue the new GEC Manifest before the new policy set is committed. The prior GEC Manifest remains valid for verification of Event Log entries signed before the policy change. Historical entries carry the cedar_policy_ref from the policy set active at evaluation time; verifiers MUST use the manifest whose cedar_policy_set_hashes[] contains the matching policy_set_id and version. 10. Federation and Cross-Instance Verification SOOS deployments may federate: a receiving kernel instance accepts and verifies Event Log entries produced by a presenting kernel instance. KIA provides the cryptographic foundation for this verification. The receiving kernel MUST: (a) Obtain the presenting kernel's current GEC Manifest via the presenting kernel's API endpoint or an operator- provisioned out-of-band channel. (b) Verify the GEC Manifest signature against the presenting kernel's public key fingerprint. (c) Verify the attestation_certificate in the GEC Manifest against the presenting operator's root public key (obtained via operator-to-operator trust establishment). (d) Check that the soos_conformance_version is compatible. (e) For each presented Event Log entry, verify the kernel_signature against the kernel_keypair_fingerprint from the verified GEC Manifest. (f) Verify that the cedar_policy_ref in each presented entry matches a policy_set_id and version recorded in the GEC Manifest that was current at the entry's timestamp. The cross-instance trust establishment protocol (how operators exchange root public keys and negotiate federation terms) is out of scope for this document and is deferred to a successor specification. (UPDATED in -03) The XPID cross-instance verification procedure in Section 6.3 supplements but does not replace the federation attestation requirements above. 11. GEC as RATS Attester KIA declares the GEC as a RATS Attester as defined in [RFC9334]. The complete role mapping is: +------------------+------------------------------------------------+ | RATS Role | KIA / SOOS Equivalent | +------------------+------------------------------------------------+ | Attester | GEC instance (via KIA subsystem) | | Evidence | GEC Manifest (Section 5.2) | | Endorser | Operator root keypair holder | | Endorsement | GEC Attestation Certificate (Section 3.4) | | Verifier | Inline by Relying Party (standard); separate | | | KIA Verification Service (high-assurance) | | Relying Party | Agents submitting mandates; external audit | | | consumers; federated kernel instances | | Reference Values | SOOS KernelSpec conformance version string; | | | expected cedar_policy_set_hashes[] per | | | deployment | +------------------+------------------------------------------------+ The GEC Manifest is RATS Evidence extended with SOOS governance- specific fields. The extension fields are defined in Section 5.2 and MUST be included in every GEC Manifest (CONF-KIA-13). These fields enable a Relying Party to verify not only the GEC's identity but also its active policy configuration -- the governance-critical property that generic RATS Evidence does not specify. In the standard SOOS deployment model, no separate Verifier service is required. Relying Parties verify the GEC Manifest inline against the operator-provisioned operator root public key. A deployment MAY provision a separate RATS Verifier service; this is RECOMMENDED for high-assurance deployments subject to regulatory audit requirements. Implementation note: Operators MAY use CoRIM [RATS-CORIM] to distribute Reference Values for appraisal of GEC Manifests. This use is informative and does not affect KIA conformance requirements. RATS WG Note (Vienna presentation): (NEW in -03) KIA-03 presents two novel RATS contributions at IETF 126 Vienna: (a) XPID (Section 6): a derivation-based cross-instance identifier that extends the RATS Attester identity model to multi-kernel federation without requiring a trusted third party. The XPID addresses the gap identified in the RATS architecture where no standard mechanism exists for correlating Attester-signed artifacts across federation boundaries when the Relying Party domain changes. (b) Attestation channel binding defense (Section 15.11): demonstration that KIA's architecture structurally prevents the CVE-2026-33697 class of relay attack (attestation evidence bound to transport key rather than durable identity anchor) through the GEC keypair independence property. This is presented as a concrete case study for the RATS WG of how the attester architecture can defend against attestation relay. 12. Relationship to WIMSE WIMSE (Workload Identity in Multi-Service Environments) [WIMSE-ARCH] addresses workload-side identity for workload-to-workload and workload-to-service authentication. KIA is the governance-kernel- side complement: WIMSE establishes the identity credential the GEC presents to external services; KIA attests the policy state the GEC is running. The division of responsibility is: WIMSE: Answers "who is this GEC?" -- the identity credential presented by the GEC process to agents and services. KIA: Answers "what is this GEC running?" -- the policy configuration attestation that makes identity meaningful for governance. Implementations SHOULD use WIMSE tokens as the identity credential format for GEC-to-GEC and GEC-to-service authentication, with KIA attestation (the GEC Manifest) as the policy-state proof layered above the WIMSE identity assertion. A receiving kernel that accepts a WIMSE token from a presenting kernel SHOULD also request and verify the presenting kernel's current GEC Manifest before accepting cross- instance Event Log entries (see Section 4.6 and CONF-KIA-12). SPIFFE SVIDs [SPIFFE-ID] MAY be used as the agent-side identity credential at Step 0 of the kernel execution sequence, providing a URI-based workload identity (spiffe://trust-domain/path) verifiable against a SPIFFE trust domain configured for the operator. SPIFFE SVIDs and WIMSE tokens are complementary agent-side identity formats; KIA's GEC Manifest is the kernel-side attestation that neither replaces. Note on scope: OQ-S-19 (Agent Runtime Attestation Profile, Section 14.2) addresses whether agents SHOULD provide WIMSE-based or RATS-based runtime attestation to the GEC. WIMSE is the primary candidate framework for resolving OQ-S-19. That resolution is deferred to a KIA successor document. WIMSE Note (Vienna): (NEW in -03) The XPID (Section 6) addresses a WIMSE gap: no existing WIMSE specification provides a mechanism for correlating workload identity claims across independent trust domains where no shared identity provider exists. The XPID provides this correlation using only the KIA identity infrastructure already present in both kernels. This is a natural WIMSE WG discussion point. 12.1. Relationship to WISE and MLE (NEW in -06, internal reference only) This section addresses architecture; it does not cover the specific SSF event profiles WISE (openid-wise) and Mandate Lifecycle Events (MLE, a SOOS-adjacent companion profile, not yet submitted). The mechanical binding -- which KIA operations (GEC Manifest issuance, keypair rotation, the Revocation Registry) become which WISE/MLE Transmitter events, and at which call sites -- is maintained separately in the internal, GitHub-only reference document soos-wise-mle-binding-00.md, not normatively in this document. One convention from that binding work is recorded here because it affects this document's own text, not just the binding doc's: where a KIA-internal field and a WISE or MLE public field describe the same concept, KIA MUST use the public field's name (adjusted only for KIA's own internal-vs-external casing convention, per Section 8.1/6.5) rather than an independently-invented one. MLE's naming is treated as the tie-breaker in a naming conflict, since it has already had to survive review against [SOOS-MJWT] directly. Section 8.1's RevocationRecord schema and Section 6.5's CAEP propagation event were both corrected under this rule in this revision (previously revocation_scope/THIS_MANDATE_ONLY/CASCADE_TO_DESCENDANTS, an independently-drifted name for the same concept MLE and [SOOS-MJWT] both call revocation_type/direct/cascade). 13. Conformance A conforming KIA implementation MUST satisfy all of the following requirements. CONF-KIA-01: The GEC MUST generate an Ed25519 keypair at deployment initialisation. The private key MUST NOT be exported from the secure element. CONF-KIA-02: The GEC MUST issue a GEC Manifest at deployment, after receiving the GEC Attestation Certificate. CONF-KIA-03: The GEC MUST reissue the GEC Manifest on every Cedar policy set change committed by the Policy Governance Kernel, before processing any transition governed by the new policy set. (INV-10) CONF-KIA-04: Every Event Log entry MUST carry a kernel_signature field containing an Ed25519 signature over the canonical JSON of the event (excluding the kernel_signature field itself), signed by the GEC keypair. (INV-9) CONF-KIA-05: An Event Log entry without a valid kernel_signature MUST be treated as invalid by any verifying party and MUST NOT be used as evidence in audit, federation, or dispute resolution. CONF-KIA-06: The Revocation Registry MUST be rebuilt from the Event Log on kernel restart before processing any mandate presentations. (INV-11) CONF-KIA-07: The GEC MUST check the Revocation Registry at Step 1 of every kernel execution sequence. A mandate whose jti appears in the Revocation Registry MUST be REJECTED. (INV-11) CONF-KIA-08: Only a human-held Party Registry principal may issue MANDATE_REVOKED events. An agent MUST NOT be permitted to issue mandate revocations under any mandate, Cedar policy, or operator configuration. CONF-KIA-09: The GEC MUST verify the authority_signature on MANDATE_REVOKED events before committing them to the Event Log. An invalid authority_signature MUST cause the kernel to REJECT the revocation without writing any Event Log entry. CONF-KIA-10: HEM_INVOKED, HEM_RESOLVED, and HEM_TIMEOUT events MUST be signed by the KIA keypair (INV-9). The HEM Escalation Request embedded in HEM_INVOKED is part of the permanent signed audit record. CONF-KIA-11: The hardware_backed field in the GEC Manifest MUST accurately reflect whether the GEC keypair is stored in a hardware secure element. False attestation is a conformance violation. CONF-KIA-12: For federation, the receiving kernel MUST verify the presenting kernel's GEC Manifest signature and attestation_certificate before accepting cross-instance Event Log entries. CONF-KIA-13: Every GEC Manifest MUST include the five RATS Evidence extension fields defined in Section 5.2: loaded_policy_ids[], cedar_policy_hash, kernel_version, attestation_timestamp, and deployment_constraints[] (absent when no constraints apply). A GEC Manifest missing loaded_policy_ids[], cedar_policy_hash, kernel_version, or attestation_timestamp is non-conforming. CONF-KIA-14: Implementations SHOULD use WIMSE tokens [WIMSE-ARCH] as the identity credential format for GEC-to-GEC authentication, with the GEC Manifest as the policy-state attestation layered above the WIMSE identity credential. Where WIMSE is not available, implementations MAY use SPIFFE SVIDs [SPIFFE-ID] or operator- provisioned Ed25519 public key fingerprints as the GEC identity credential. CONF-KIA-15: The cedar_policy_hash in the GEC Manifest and the cedar_policy_hash in the PTD served at ptd_endpoint MUST be identical. The GEC MUST regenerate the PTD atomically with every GEC Manifest reissuance triggered by a Cedar policy set change (Section 5.3(b)). A GEC Manifest and PTD with differing cedar_policy_hash values is non-conforming. A non-conforming state MUST generate CAP_TRANSPARENCY_VIOLATION per [SOOS-CAP] Section 12a.6. See Section 5.5. The following conformance requirements are added in -03: CONF-KIA-16: In FROST deployments, each signing participant MUST generate a fresh cryptographically secure nonce for every signing operation. Nonces MUST NOT be reused across signing operations. (Section 4.1) CONF-KIA-17: FROST implementations MUST comply with the nonce generation procedure in Section 5.1 of [FROST]. Implementations MUST NOT cache or pre-generate nonce sets for batch signing. CONF-KIA-18: If the FROST signing cluster falls below quorum, the GEC MUST refuse to sign any KIA artifact. The GEC MUST NOT degrade to single-signer operation. CONF-KIA-19: On quorum failure, the GEC MUST emit a KERNEL_AUDIT_ANOMALY alert and notify the operator. CONF-KIA-20: FROST threshold reduction below the initial t parameter MUST NOT occur without a new key generation ceremony and new GEC Attestation Certificate. CONF-KIA-21: A GEC MUST derive the XPID using the procedure in Section 6.2. Implementations MUST NOT accept a client- supplied XPID as authoritative. CONF-KIA-22: A GEC MUST record the XPID in every GAR audit entry for the governed agent session, as the soos.governance.xpid attribute. CONF-KIA-23: Federated kernels MUST validate the mandate JWT jti against their local Revocation Registry before accepting any cross-instance agent events, independently of XPID verification. CONF-KIA-24: (NEW in -06) The KERNEL_AUDIT_ANOMALY alert required by CONF-KIA-19 on quorum failure is a named, narrow exception to CONF-KIA-18: it MUST be signed by whatever subset of the signing cluster is available, even below threshold t, or delivered unsigned through the out-of-band notification channel if fewer than two participants remain. A below-threshold alert signature is valid for this artifact type only and MUST NOT be treated as authorizing any other KIA artifact. See Section 4.1. 14. Open Issues 14.1. OQ-S-18: Deployment Topology How KIA behaves in non-standard deployment topologies -- in particular, cloud-native deployments without hardware TPM access, multi-region deployments where the GEC keypair must be shared or sharded across availability zones, and containerised deployments where the secure element is a software HSM -- is unresolved. The current specification requires hardware backing RECOMMENDED (not MUST) precisely to accommodate cloud-native deployments. A deployment topology profile document is required to specify the acceptable attestation architectures for each deployment class and the GEC Manifest declarations required for each. OQ-S-18 is tracked as MEDIUM priority. It does not block single- instance deployments with hardware HSM backing. 14.2. OQ-S-19: Agent Runtime Attestation Profile KIA specifies how the GEC attests to agents and verifiers (the downward-facing direction in the trust chain). The upward- facing direction -- how agents attest their own runtime state to the GEC -- is unresolved. Specifically: when a Class 2 or Class 3 agent presents a mandate JWT, should the GEC require accompanying attestation evidence about the agent's runtime environment (e.g., that the agent is running in a TEE, that the agent's model weights are a known and approved hash, that the agent process has not been modified since mandate issuance)? This is a genuine architectural open question. Requiring agent runtime attestation closes a significant threat: a compromised agent runtime that holds a valid mandate. But it imposes attestation infrastructure requirements on all agent providers, which may be disproportionate for Class 1 scenarios. OQ-S-19 is tracked as HIGH priority. It is the primary item for resolution in a KIA successor document. The RATS architecture (RFC 9334) and WIMSE workload attestation models are the primary inputs for OQ-S-19 resolution. 14.3. OQ-S-XPID-REV: XPID Revocation Gap (NEW in -03) When an agent's mandate is revoked, the XPID derived from that agent's Party Registry entry is not invalidated -- only the jti is added to the Revocation Registry. In multi-kernel federation, a revoked agent's XPID may be presented to a receiving kernel that has not yet received the revocation signal. Three interim mitigations are specified in Section 6.4. A normative federated revocation protocol that invalidates XPID values on mandate revocation is deferred to a KIA successor document. OQ-S-XPID-REV is tracked as HIGH priority for the KIA-04 or successor document. The CAEP-based propagation model in Section 6.5 is the current candidate mechanism. 14.4. OQ-KIA-EVIDENCE-VIS: Evidence Visibility to Unintended Verifiers (NEW in -05) Section 6.3's Cross-Instance Trust Model has no stated mitigation for a federation participant obtaining structural visibility into Evidence it is not authorized to appraise -- e.g. a Lead or intermediate verifier in a multi-verifier topology. See Section 6.6 for the full discussion and `draft-ritz-seat-proxies` for the general pattern this instance of the gap follows. No mitigation is specified in this document. Resolution -- candidate direction: encryption of Evidence to the intended verifier's key -- is deferred to a KIA successor document, tracked at MEDIUM priority (lower than OQ-S-XPID-REV, which has a known active exploitation path via mandate revocation; this issue requires a specific multi-verifier topology to be present). 15. Security Considerations 15.1. Private Key Extraction The security of the entire SOOS audit trail depends on the kernel keypair private key remaining inside the secure element. An attacker who extracts the private key can forge any Event Log entry for any SO. Implementations MUST use hardware-backed key storage wherever available and MUST document the absence of hardware backing as a deployment constraint. In FROST deployments (Section 4.1), the private key is distributed as t-of-n secret shares. An attacker must extract shares from at least t participants to forge signatures. The security of the FROST deployment is therefore bounded by the security of the t weakest participants' secure elements. Operators MUST ensure that all n participants' secure elements meet the same hardware security standard. 15.2. GEC Manifest Forgery A forged GEC Manifest with an attacker-controlled keypair fingerprint would cause agents to trust a fraudulent kernel. The GEC Attestation Certificate (operator-signed) binds the GEC keypair to the operator identity. A verifier that skips attestation_certificate verification is vulnerable to GEC Manifest forgery. Implementations MUST verify the attestation_certificate as part of any GEC Manifest verification procedure. 15.3. Policy Hash Manipulation The cedar_policy_set_hashes[] in the GEC Manifest commits the kernel to a specific set of Cedar policies. An attacker who can modify Cedar policies at runtime without triggering a GEC Manifest reissuance can cause the GEC to evaluate transitions under an unattested policy set while presenting a stale GEC Manifest. INV-10 prevents this: the GEC Manifest MUST be reissued before the new policy set governs any transition. Implementations MUST enforce the atomicity of policy commit and GEC Manifest reissuance. 15.4. Revocation Registry Incompleteness If the Revocation Registry rebuild on restart is incomplete (e.g., due to Event Log corruption or a truncated scan), revoked mandates may be accepted at Step 1. Implementations MUST complete the full Event Log scan before accepting any mandate presentations after a restart. Partial Revocation Registry rebuilds MUST NOT result in an operational kernel. 15.5. Cascade Revocation Race In a CASCADE-type revocation, the GEC writes one MANDATE_REVOKED entry per descendant mandate (Section 8.1), not a single event covering all of them. This creates a real atomicity window: a non-atomic implementation that writes descendant entries one at a time risks a period where the root mandate is revoked but some descendants are not yet reflected in the Revocation Registry. Implementations MUST treat the full set of MANDATE_REVOKED writes for one cascade (the direct revocation plus every descendant) as a single atomic unit with respect to Step 1 mandate acceptance: no session MUST be permitted to present any mandate from the affected tree while a cascade revocation is partially written. 15.6. Implementation Degradation KIA's security guarantees depend on the GEC keypair being stored in a hardware secure element (Sections 3.2, 4.1). In environments without hardware TPM or HSM access -- virtual machines, containers, cloud functions -- the GEC keypair may fall back to software key storage. This is a conformance-permitted degradation (hardware_backed: false) but constitutes a security degradation relative to the hardware-backed baseline. Threat: Silent degradation. A deployment that silently falls back to software key storage without surfacing this to operators or Relying Parties provides false assurance. An operator who believes the GEC keypair is hardware-backed when it is not has a misleading audit trail. Mitigation requirements: (a) The GEC Manifest MUST set hardware_backed: false accurately. False attestation is a conformance violation (CONF-KIA-11). (b) The GEC SHOULD surface a persistent operator notification at startup if hardware-backed key storage is not available. The notification MUST include the deployment constraint and its implication. (c) Relying Parties consuming a GEC Manifest with hardware_backed: false SHOULD treat Event Log entries with reduced trust. Deployments subject to regulatory audit requirements SHOULD document this as a known risk. (d) Deployments using vTPM SHOULD set hardware_backed: true and MUST record the vTPM type in deployment_constraints[] (Section 5.2). A Relying Party SHOULD inspect deployment_constraints[] even when hardware_backed: true, as a vTPM entry signals weaker isolation guarantees than a physical HSM. (e) A deployment that does not meet hardware_backed: true MUST document this in operational runbooks and MUST NOT represent the deployment as fully KIA-conformant without qualification. See also CONF-KIA-11 (false attestation prohibition) and Section 15.1 (private key extraction). Additional consideration for FROST deployments: FROST cluster degradation is a distinct form of implementation degradation. A signing cluster that has lost participants may attempt to operate with a reduced quorum by re-running a FROST threshold reduction. Section 4.1 (CONF-KIA-20) prohibits this: threshold reduction requires a new key generation ceremony. Operators SHOULD monitor signing cluster participant count and alert before quorum failure becomes imminent. See also Section 15.13 for the availability-blast-radius asymmetry this creates. 15.7. Agent Session Revocation KIA operates within the SOOS session lifecycle model. When an agent session is revoked -- by operator action, CAEP signal, or CAP constitutional violation -- KIA's mandate validation responsibilities (Sections 4.4, 8) are superseded by the MAD session revocation procedure [SOOS-MAD]. Implementations MUST NOT continue accepting mandate JWTs after receiving a session revocation signal. All Revocation Registry entries generated during the revocation event MUST be written with completion_state PARTIAL or CLEAN per the MAD session revocation lifecycle specification. 15.8. FROST Nonce Reuse Risk (NEW in -03) KIA-03 introduces FROST threshold signing (Section 4.1) for high- availability GEC keypair deployments. FROST threshold signatures require each signing participant to generate a fresh nonce for every signing operation. Nonce reuse in FROST is a critical security failure: two signing operations using the same nonce value from the same participant expose that participant's secret share, enabling an attacker to reconstruct the private key share. If an attacker reconstructs t secret shares, they can forge threshold signatures. Attack vector: An implementation that caches nonces for performance (pre- generating nonce batches to avoid cryptographic overhead per signing operation) creates a systematic nonce reuse risk. If the nonce cache is not consumed atomically -- for example, if the signing process crashes mid-batch and the nonce state is restored from a checkpoint -- the same nonce may be reused in a subsequent signing operation. Normative defense requirements: CONF-KIA-16 (no nonce reuse) and CONF-KIA-17 (FROST nonce procedure compliance) address the protocol-level requirement. The following implementation requirements also apply: (a) Nonce generation state MUST NOT be checkpointed or persisted to storage. Nonces MUST be generated fresh at signing time, not loaded from stored state. (b) Each FROST signing participant MUST independently generate its own nonce. Nonces MUST NOT be generated centrally and distributed to participants. (c) Signing operations MUST be serialized within each participant to prevent concurrent nonce generation paths that could produce collisions. (d) If a signing participant crashes during an operation and restarts, the restart MUST NOT resume with any in-progress nonce state. The participant MUST generate a new nonce for any resumed signing operation. Residual risk: Hardware-level nonce generation failures (entropy exhaustion in the secure element's RNG) cannot be fully prevented by protocol requirements. Implementations SHOULD monitor RNG health in FROST signing nodes and alert before entropy exhaustion. The normative reference for FROST nonce generation requirements is Section 5.1 of [FROST]; Section 7.3 of [FROST] ("Nonce Reuse Attacks") documents the underlying attack this section addresses. Implementations MUST comply with the nonce generation procedure specified therein. In deployment environments where the FROST signing cluster experiences partial failure and falls back to a reduced quorum, implementations MUST NOT reduce the threshold below the security parameter (t) established at deployment (CONF-KIA-20). A signing cluster that cannot meet the quorum threshold MUST refuse to sign and MUST emit a KERNEL_AUDIT_ANOMALY alert (CONF-KIA-18, CONF-KIA-19) rather than degrade to single-signer operation. 15.9. XPID Revocation Gap (Known Open Issue) (NEW in -03) The Cross-Principal Identifier (XPID) introduced in Section 6 is a UUID-v5 value derived deterministically from the issuing GEC's kernel_keypair_fingerprint (Section 6.2) -- the SHA-256 fingerprint of the GEC's Ed25519 public key, or of the FROST threshold public key in FROST deployments -- and the agent's Party Registry entry. (CLARIFIED in -06: not the FROST threshold key material itself, which never appears in the derivation; the XPID is safe to record in every GAR audit entry, per CONF-KIA-22, precisely because it derives only from public, hashed material.) An XPID issued to an agent is bound to that agent's Party Registry entry for the operational lifetime of the mandate. A known open issue exists regarding XPID revocation: when an agent's mandate is revoked via the MAD session revocation procedure [SOOS-MAD], the XPID value itself is not invalidated -- only the mandate JWT jti is added to the Revocation Registry (Section 8). In a multi-kernel federation where XPID values are shared across kernel boundaries (Section 6.3), a revoked agent's XPID may still be presented to a receiving kernel that has not yet received the revocation signal. This gap is acknowledged as a known open issue (OQ-S-XPID-REV, Section 14.3). Mitigations available in the current architecture: (a) Federated kernels MUST validate the mandate JWT jti against their local Revocation Registry, not solely the XPID, before accepting cross-instance agent events (CONF-KIA-23). (b) Federated kernels SHOULD subscribe to the originating kernel's CAEP revocation signal stream [SOOS-MAD] to receive propagated revocation events in near-real time (Section 6.5). (c) GEC Manifest staleness limits (Section 5.4) bound the window during which a stale cross-instance trust relationship can be exploited. Resolution of this open issue is deferred to a KIA successor document addressing the federated revocation protocol. 15.10. Identity Takeover via Claimed Identifier -- CVE-2025-13609 Class Defense (NEW in -03) Systems that accept agent identity via self-asserted identifiers are vulnerable to identity takeover through duplicate registration, a class demonstrated by [CVE-2025-13609] (CVSS 8.2, High) in which an attacker registered a new agent using a different TPM device while claiming an existing agent's UUID, overwriting the legitimate agent's identity and enabling impersonation. KIA's XPID design structurally prevents this attack class. The XPID is not an asserted value -- it is derived deterministically from the GEC's kernel_keypair_fingerprint (Section 6.2) and the agent's Party Registry entry. An attacker cannot claim an existing XPID without: (a) Possessing the original FROST key shares used to derive it (specifically, the threshold public key whose fingerprint is the kernel_keypair_fingerprint used in the derivation), OR (b) Compromising the Party Registry entry to which the XPID is bound (substituting a different party_registry_entry_hash in the derivation would produce a different XPID). Either condition requires a more fundamental compromise than duplicate identifier registration. The structural prevention holds because: (i) The XPID derivation inputs (kernel_keypair_fingerprint and party_registry_entry_hash) are both verifiable by any party with access to the GEC Manifest and the Party Registry. (ii) An attacker who presents a fabricated XPID that does not match the derivation from the verified inputs is immediately detectable by any receiving kernel performing XPID verification (Section 6.3). (iii) The GEC Manifest signature (over kernel_keypair_fingerprint) is hardware-rooted and operator-certified. Substituting a different kernel_keypair_fingerprint requires forging the GEC Manifest -- which requires the operator root keypair or the GEC's signing key. Implementations MUST NOT accept a client-supplied XPID as authoritative (CONF-KIA-21). The XPID MUST be derived or verified by the issuing GEC's signing layer, not taken from agent-supplied metadata. This structural property is the positive differentiator KIA provides over attestation systems that validate identity at registration time but do not cryptographically bind the identifier to the hardware or key material that generated it. 15.11. Attestation Channel Binding -- CVE-2026-33697 Class Defense (NEW in -03) Attestation systems that bind attestation evidence to a transport key rather than to a durable identity anchor are vulnerable to relay attacks when the transport key can be extracted. [CVE-2026-33697] (Cocos AI, High) demonstrated this class: attestation evidence was bound to an ephemeral TLS key but not to the TLS channel itself, enabling an attacker who could extract the ephemeral key to relay or divert the attested TLS session while impersonating the legitimate attested service. KIA prevents this attack class structurally. KIA identity is anchored to the GEC's Ed25519 keypair (or FROST threshold keypair) held in the secure element -- not to any transport-layer key. The GEC Manifest carries the kernel_keypair_fingerprint as a durable, hardware-backed identity anchor. An attacker who intercepts a transport session cannot forge the kernel_signature on Event Log entries, because that signature is produced by the secure-element-held GEC keypair, not by any key material visible at the transport layer. Specifically: (a) All Event Log entries are signed by the GEC keypair (INV-9), which is independent of any TLS or transport session. Event Log integrity does not depend on transport channel integrity. (b) The GEC Manifest is signed by the GEC keypair and carries the attestation_certificate issued by the operator root keypair. Verifiers authenticate the GEC Manifest through the operator trust chain (Section 3), not through the transport session. A relay attacker who intercepts the GEC Manifest delivery cannot produce a valid manifest_signature over a modified manifest without the GEC keypair. (c) In FROST deployments (Section 4.1), the identity anchor is the FROST signing cluster's threshold public key -- a distributed secret across n participants' secure elements. A relay attacker would need to extract t-of-n secret shares to forge the identity anchor. (d) The XPID (Section 6.2) is derived from the kernel_keypair_ fingerprint -- itself a hash of the hardware-backed public key. An attacker cannot forge a valid XPID for a session without the GEC keypair. Implementations MUST NOT use transport-layer keys (TLS session keys, ephemeral ECDH values) as the binding for attestation evidence. Attestation MUST be anchored to the hardware-backed GEC keypair through the KIA trust chain (Section 3). This is the structural defense that KIA's design provides against the CVE-2026-33697 attack class. KIA-03 presents this as a concrete case study for the RATS WG of how the attester architecture can defend against attestation relay attacks when the identity anchor is hardware-rooted and transport-independent. 15.12. Evidence Visibility to Unintended Verifiers (Known Open Issue) (NEW in -05) Section 6.3's Cross-Instance Trust Model verifies that a presented XPID is authentic; it does not restrict which federation participants can see the Evidence carrying that XPID in the first place. A Lead or intermediate verifier in a multi-verifier topology can therefore end up with structural visibility into Evidence it is not authorized to appraise, a concern named directly by `draft-ritz-seat-proxies` for multi-verifier RATS topologies generally and applicable here without modification. This gap is acknowledged as a known open issue (OQ-KIA-EVIDENCE-VIS, Section 14.4). See Section 6.6 for the full discussion. No mitigation is specified in this document; a candidate direction (encrypting Evidence to the intended verifier's key) is noted for a future revision, not adopted. 15.13. Denial of Service via Quorum Isolation (NEW in -06) RFC 3552 / BCP 72 requires Security Considerations sections to address Denial of Service explicitly. This document did not previously do so. CONF-KIA-18 requires the GEC to refuse to sign any Event Log entry, GEC Manifest, or other KIA artifact whenever the FROST signing cluster falls below quorum, and forbids degrading to single-signer operation under any circumstance. Because KIA is the Layer 0 signing and attestation component on which GAR, MJWT, MAD, HEM, AEP, and CAP all depend (Appendix B.6), a quorum failure does not merely create an audit gap: it halts the governed system's ability to record -- and, per the "commit before action executes" pattern used elsewhere in the SOOS suite, likely to take -- any action at all for as long as the failure persists. This produces a structural asymmetry between the confidentiality/ integrity guarantee and the availability guarantee of a FROST deployment. Breaking confidentiality or integrity requires an attacker to compromise t participants' secret shares. Breaking availability requires only isolating, disabling, or otherwise preventing a response from n - t + 1 participants -- a meaningfully easier bar, and one that gets easier, not harder, as operators choose t closer to n for stronger security. In the document's own worked example, a 3-of-5 deployment chosen for a reasonably strong security margin needs only 3 of 5 participants disabled (a bar lower than compromising even a bare majority) to halt all governed activity system-wide. This tension between the FROST security parameter and the availability blast radius it creates is not otherwise discussed in this document. It does not indicate a flaw in CONF-KIA-18's refuse-rather-than-degrade design -- silently degrading to single-signer operation under attack would be a worse outcome, trading an availability failure for an undetectable integrity one -- but operators MUST account for it in signing cluster topology and participant placement. Recommendations: (a) Signing cluster participants SHOULD be placed to minimize the likelihood that a single network partition, facility outage, or targeted resource-exhaustion attack can isolate more than n - t participants simultaneously (e.g., geographic and provider diversity across participants). (b) Operators SHOULD monitor signing cluster participant availability continuously and alert as availability approaches the n - t + 1 threshold, not only after quorum is actually lost (Section 15.6). (c) CONF-KIA-24 (Section 4.1, Section 13) ensures that a quorum failure is itself observable via a signed or out-of-band KERNEL_AUDIT_ANOMALY alert; operators MUST treat sustained quorum-failure alerts as an active availability incident, not merely a logged anomaly. The choice of t relative to n is therefore a security/ availability tradeoff, not a security-only parameter, and SHOULD be documented as such in deployment_constraints[] alongside the "frost:t-of-n:-" declaration (Section 4.1). 16. Privacy Considerations (NEW in -06) This document previously had no Privacy Considerations section. The XPID (Section 6) is, by its own stated design, a persistent, cross-context identifier, and warrants the same treatment given to weaker-linkability identifiers elsewhere in the SOOS suite ([SOOS-GAR]'s treatment of session_id/mandate_jwt_id as GDPR Art. 4(5) pseudonymous identifiers, [SOOS-MJWT]'s Section 12 covering jti timing leakage and consent-data sensitivity, and [SOOS-IDP]'s Section 11 covering PII in declared-goal text). 16.1. XPID Linkability Section 6.1's own stated design properties are that the XPID is Deterministic, Stable ("does not change within the lifetime of the agent's Party Registry entry and the GEC deployment's keypair"), and Immutable. It is recorded in every GAR governance span across every session (CONF-KIA-22), and it is specifically designed to be recomputable and correlatable by any federation participant holding the derivation inputs without coordination with the issuing GEC (Section 6.1(a)). This is precisely the shape of identifier that GDPR Art. 4(1) ("any information relating to an identified or identifiable natural person... in particular by reference to an identifier") and APPI Art. 2 linkability analysis exists to address: a stable, cross-context, third-party-recomputable identifier tied to a Party Registry entry that, per how human_principal_id binding works elsewhere in the SOOS suite ([SOOS-MJWT] Section 4.2.1), is plausibly traceable to a specific human principal or organization. Any party who can observe soos.governance.xpid across two or more GAR governance spans -- a federation participant, an auditor, or (per Section 6.6's OQ-KIA-EVIDENCE-VIS gap) an unintended verifier with structural visibility into Evidence it was not meant to see -- can trivially correlate that agent's activity across every session and every kernel boundary for the operational lifetime of the Party Registry entry, without compromising anything. XPID is more linkability-sensitive than session_id or mandate_jwt_id (session- scoped) precisely because it is deployment-lifetime-scoped by design, yet it has received no privacy treatment prior to this revision. 16.2. Access Scoping Resolving OQ-KIA-EVIDENCE-VIS (Section 6.6) -- restricting Evidence visibility to the intended verifier -- would also bound XPID's practical linkability blast radius, since an unintended verifier cannot correlate an XPID it never legitimately observes. The two gaps are related but not identical: Section 6.6 concerns who can see Evidence; this section concerns what a legitimate verifier can subsequently infer once they see it. Until OQ-KIA-EVIDENCE-VIS is resolved, operators SHOULD apply the tightest available transport- and access-control scoping to Evidence exchange as an interim, non-normative mitigation for both gaps together. 16.3. Rotation vs. Correlation Tradeoff XPID is explicitly "Immutable" by design (Section 6.1(c)), chosen to maximize audit-correlation utility. This is an unstated default rather than a considered tradeoff as currently written -- contrast [SOOS-GAR]'s explicit, justified choice of pseudonymization-over-deletion for session_id. A future revision SHOULD either (a) state explicitly why immutability was chosen over rotation given the linkability cost identified in Section 16.1, or (b) define a rotation mechanism (e.g., rotating the Party Registry entry, which would also rotate the derived XPID under the Section 6.2 procedure) for deployments where linkability risk outweighs correlation utility. No mechanism is specified in this revision; resolution is deferred to a KIA successor document, the same disposition as OQ-S-XPID-REV (Section 6.4) and OQ-KIA-EVIDENCE-VIS (Section 6.6). 17. IANA Considerations The IANA Considerations section from -02 is updated as follows. (Registration table for the GAR ALE Type Registry corrected in -04; see below.) This document requests the creation of the following IANA registry: Registry Name: SOOS GEC Manifest Extension Fields Registration Procedure: Specification Required [RFC8126] Initial Values: +-----------------------------+--------+---------------------------+ | Field Name | Type | Description | +-----------------------------+--------+---------------------------+ | xpid_derivation_version | string | XPID algorithm version | | | | (Section 6.2); "1.1", | | | | "1.0", or "none" | +-----------------------------+--------+---------------------------+ This document also requests registration of the following two event types in the GAR Authority Lifecycle Event Types Registry [I-D.sato-soos-gar], using that registry's column set (Event Type, Class, Reference) (CORRECTED in -04): +--------------------------+-------+---------------------------+ | Event Type | Class | Reference | +--------------------------+-------+---------------------------+ | XPID_DERIVED | ID | Sec. 6.2 | | XPID_VERIFICATION_FAILED | ID | Sec. 6.3 | +--------------------------+-------+---------------------------+ Class ID = Identity/Federation event (new class, requested via KIA-04). Required fields for each event type, moved here from the -03 registration table (which had incorrectly carried them in an extra Description column not present in the target registry's schema): XPID_DERIVED: Fired at session initialization when an XPID is derived for an agent in the session (Section 6.2). Required fields: session_id, agent_party_id, kernel_keypair_fingerprint, xpid, derivation_version, derived_at. XPID_VERIFICATION_FAILED: Fired when XPID verification fails during cross-instance federation (Section 6.3). Required fields: session_id, received_xpid, expected_xpid, receiving_kernel_id, presenting_kernel_id, detected_at. This document requests registration of the following CAEP event type [CAEP]: +--------------------+-------------------------------------------+ | Event Type | Description | +--------------------+-------------------------------------------+ | mandate_revoked | Mandate JWT revocation with XPID subject | | | (Section 6.5). Subject format: "xpid". | +--------------------+-------------------------------------------+ 18. 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, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . [RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, May 2024, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, June 2017, . [FROST] Connolly, D., Komlo, C., Goldberg, I., and C. Wood, "The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures", RFC 9591, DOI 10.17487/RFC9591, June 2024, . (NEW in -03; reference updated from the CFRG working draft to its published RFC in -06) [WIMSE-ARCH] Salomoni, D. et al., "WIMSE Architecture", draft-ietf-wimse-arch-07, Work in Progress, March 2026. [SOOS-CAP] Sato, T., "Constitutional AI Protocol", draft-sato-soos-cap-04, Work in Progress, June 2026. (UPDATED version ref) [SOOS-GAR] Sato, T., "Governance Audit Record", draft-sato-soos-gar-07, September 2026. (UPDATED version ref) [SOOS-MAD] Sato, T., "Multi-Agent Delegation", draft-sato-soos-mad-03, Work in Progress, June 2026. [SOOS-MJWT] Sato, T., "Mandate JWT", draft-sato-soos-mjwt-05, September 2026. (UPDATED version ref) 19. Informative References [SOOS-IDP] Sato, T., "Intent Declaration Primitive", draft-sato-soos-idp-05, June 2026. [RFC8037] Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017. [RATS-CORIM] Birkholz, H. et al., "Concise Reference Integrity Manifest (CoRIM)", Work in Progress, 2026. [SPIFFE-ID] SPIFFE Project, "Secure Production Identity Framework for Everyone (SPIFFE)", Work in Progress, draft-ietf-spiffe-spiffe-id, 2026. [SCITT-ARCH] Birkholz, H. et al., "An Architecture for Trustworthy and Transparent Digital Supply Chains", draft-ietf-scitt-architecture, Work in Progress, 2026. [CAEP] Cappalli, T. and Tschofenig, H., "OpenID Continuous Access Evaluation Profile 1.0", OpenID Foundation, 2022. [RFC9672] Backman, A., et al., "Shared Signals: A Secure Webhooks Framework", RFC 9672, November 2024. [CVE-2025-13609] Red Hat, "CVE-2025-13609: Keylime registrar allows identity takeover via duplicate UUID registration", CVSS 8.2, November 2025. (NEW in -03) [CVE-2026-33697] "CVE-2026-33697: Relay attack vulnerability in Cocos AI attested TLS implementation", High, 2026. (NEW in -03) [I-D.ritz-seat-proxies] Ritz, N., "SEAT Proxies", draft-ritz-seat-proxies, Work in Progress. (NEW in -05) Appendix B. Related Work B.1. RATS Architecture (RFC 9334) The normative RATS role mapping for KIA is specified in Section 11. This appendix provides additional context on the RATS architecture for readers unfamiliar with RFC 9334. The Remote ATtestation procedureS (RATS) architecture [RFC9334] defines a general model for remote attestation: an Attester produces Evidence, an Endorser vouches for the Attester, a Verifier appraises Evidence against Reference Values to produce Attestation Results, and a Relying Party consumes Attestation Results. KIA implements the RATS model with the following mapping: Attester: The GEC (via KIA). Endorser: The operator root keypair holder. Evidence: The GEC Manifest. Endorsement: The GEC Attestation Certificate. Verifier: Any party checking the GEC Manifest (agents, federated kernels, auditors). Relying Party: Agents submitting mandates; receiving kernel instances; audit consumers. The primary divergence from the generic RATS model is that SOOS does not require a separate Verifier service. Verification is performed inline by the relying party (agent or receiving kernel) against the GEC Manifest directly. This is appropriate for the SOOS deployment model, where the kernel and its agents operate in a controlled operator domain. A successor document (OQ-S-18 / OQ-S-19) will address whether a RATS Verifier service is warranted for high-assurance deployment topologies. B.2. WIMSE The normative WIMSE integration statement for KIA is in Section 12. This appendix provides additional context on the WIMSE working group scope and the OQ-S-19 open question. The Workload Identity and Minimal Security for Environments (WIMSE) working group defines how workloads -- long-running, machine- operated processes including AI agents -- establish cryptographic identity and present that identity for authentication. WIMSE's primary deliverable is a JOSE-bound token format carrying workload identity with caller-identity binding. WIMSE and KIA address complementary directions in the SOOS trust chain. WIMSE handles agent-to-kernel and agent-to-service identity: how an agent proves to the GEC who it is before the kernel validates its mandate. KIA handles kernel-to-everything identity: how the GEC proves to agents, to auditors, and to federated kernels that it is a genuine, conforming GEC running the expected policy configuration. A conforming SOOS deployment SHOULD use WIMSE tokens (or SPIFFE SVIDs) as the agent identity credential at Step 1 of the kernel execution sequence, complementing the mandate JWT. This resolves OQ-S-19 (Agent Runtime Attestation Profile) at the identity layer, though the full runtime attestation question (attesting agent model weights or TEE execution) remains open. B.3. SPIFFE / SPIRE The SPIFFE Identity Framework provides a URI-based workload identity standard (spiffe://trust-domain/path) with X.509- and JWT-based credential formats (SVIDs). SPIRE is the reference implementation. In the SOOS Party Registry, agent identities are Ed25519 public key fingerprints. A SPIFFE SVID could serve as the agent- authentication credential at Step 0 of the kernel execution sequence (pre-mandate presentation), with the GEC verifying the SVID against a SPIFFE trust domain configured for the operator. SPIFFE/SPIRE is the natural complement to WIMSE for agent identity in SOOS deployments. Neither replaces KIA: both address the agent side of the trust chain; KIA addresses the kernel side. B.4. SCITT The Supply Chain Integrity, Transparency and Trust (SCITT) architecture [SCITT-ARCH] defines a transparency log model: signed statements about supply chain artifacts are appended to an append-only, auditable log, with inclusion proofs enabling verifiers to check that a statement was accepted by the transparency service. draft-sato-soos-gar (Governance Audit Record) is the SOOS integration of SCITT: KIA-signed SOOS Event Log entries are submitted to a SCITT transparency service as COSE-signed statements, providing third-party verifiable inclusion proofs for the SOOS audit trail. KIA is the signing layer that makes GAR possible: GAR submits KIA-signed events to SCITT. Without KIA's INV-9 guarantees, the SCITT statements would not carry a verifiable kernel identity binding. KIA and GAR are designed as a pair. B.5. TCG TPM and Hardware Attestation The Trusted Computing Group (TCG) Trusted Platform Module (TPM) specifications define the hardware security device model on which KIA's hardware root requirement is based. TPM 2.0 provides Platform Configuration Registers (PCRs) for measuring the software stack, endorsement keys for hardware identity, and attestation keys for signing Evidence. KIA's hardware_backed field and the hardware root layer in the trust chain (Section 3.2) directly reference the TCG model. Deployments using TPM 2.0 SHOULD use the TPM endorsement key as the hardware root from which the operator root keypair derives its hardware backing. The CoRIM (Concise Reference Integrity Manifest) format [RATS-CORIM] is a candidate future format for distributing the SOOS Reference Values that RATS Verifiers would appraise GEC Manifests against. This is deferred to the OQ-S-18 deployment topology specification. B.6. SOOS Companion Drafts (UPDATED in -03) KIA is one of twelve SOOS IETF individual submissions. The drafts that directly depend on KIA are: draft-sato-soos-gar-03 Governance Audit Record. Submits KIA- signed Event Log entries to a SCITT transparency service. GAR-03 adds ALE-NEW-01 through ALE-NEW-04 (Section 21.3 of [SOOS-GAR]) and the soos.gar.* OTel attribute namespace. XPID is recorded as soos.governance.xpid in every GAR governance span. draft-sato-soos-mad-03 Multi-Agent Delegation. All cluster events are signed by KIA. MAD is also the source of the CAEP revocation stream used by XPID revocation propagation (Section 6.5). draft-sato-soos-hem-05 Human Escalation Mechanism. HEM events are KIA-signed (CONF-KIA-10). INV-HEM-01 (The Surfacing Obligation) references the L1/L2/L3 conformance levels defined in KIA. draft-sato-soos-aep-02 Agent Execution Protocol. AEP session events are KIA-signed. draft-sato-soos-mjwt-02 Mandate JWT. The MJWT aud claim MUST be bound to the kernel_keypair_fingerprint from the GEC Manifest. MJWT-02 adds the consent_scope claim; KIA-03 XPID is an additional MJWT-resolvable identity correlation primitive. draft-sato-soos-cap-04 Constitutional AI Protocol. CAP Violation Records are signed by the GIK. BIOMETRIC_ SIGNAL_INFERENCE Tier 0-A violation detection uses the consent_scope in the session MJWT, which is aud-bound to the kernel_keypair_fingerprint. Appendix C. Vibe Coding Assets (UPDATED in -06) C.1. Protocol Summary Protocol: Kernel Identity and Attestation (KIA) Version: draft-sato-soos-kia-06 Family: SOOS protocol suite Role: Layer 0 signing and attestation -- GEC keypair management (including FROST threshold option), GEC Manifest issuance, XPID derivation, Event Log signing (INV-9), and Revocation Registry maintenance (INV-11) Status: Standards Track Stack position: Below Cedar and all other SOOS protocols. Depended upon by GAR, MJWT, MAD, HEM, AEP, CAP. Vienna note: Reference spec for RATS WG + WIMSE WG presentations. New in -04: GAR ALE Type Registry request (Section 17) corrected to match [I-D.sato-soos-gar]'s Event Type / Class / Reference columns; new Class ID (Identity/Federation event) assigned to XPID_DERIVED and XPID_VERIFICATION_FAILED. Registration-format fix only; no new event types or normative behavior. New in -05: Evidence Visibility to Unintended Verifiers (OQ-KIA-EVIDENCE-VIS, Sections 6.6/14.4/15.12) disclosed as a known open issue, following a WIMSE security review checklist dry-run (DR-MJWT-KIA-CHECKLIST-01, Finding 4). No mitigation mechanism specified; disclosure only. New in -06: full WIMSE Security Review checklist pass (Stage 0 through Stage 2). Dedicated XPID namespace UUID (Section 6.2, xpid_derivation_version "1.1"); FROST reference updated to RFC 9591 with corrected section citations; CONF-KIA-24 resolves the CONF-KIA-18/CONF-KIA-19 quorum-failure alert-signing bootstrap contradiction; new Denial of Service Security Considerations entry (Section 15.13); new Privacy Considerations section (Section 16) covering XPID linkability. No prior conformance requirement is weakened. C.2. Key Identifiers Trust chain: Hardware Root -> Operator Root Keypair -> GEC Attestation Certificate -> GEC Keypair (or FROST threshold keypair) -> Event Log entries -> Cedar evaluations -> Sovereign Objects New in -03: XPID = UUID5(namespace, kernel_keypair_fingerprint + ":" + party_registry_entry_hash) FROST deployment marker: deployment_constraints[] entry "frost:t-of-n:-" xpid_derivation_version: "1.0" (superseded, Section 6.2) or "none" New in -06: XPID namespace UUID (version 1.1, dedicated, replaces reused DNS namespace): "447994dc-9ddf-578f-a851-3a77d8f7ae42" xpid_derivation_version: "1.1" (normative), "1.0" (backward-compat only), or "none" CONF-KIA-24: quorum-failure KERNEL_AUDIT_ANOMALY alert signing (Section 4.1, Section 13) GEC Manifest fields (RATS Evidence extension): loaded_policy_ids[], cedar_policy_hash, kernel_version, attestation_timestamp, deployment_constraints[], xpid_derivation_version (NEW in -03) Conformance identifiers: CONF-KIA-01 through CONF-KIA-24 Invariants: INV-9 (Event Log signing), INV-10 (policy change attestation), INV-11 (Revocation Registry) Open issues: OQ-S-18 (deployment topology), OQ-S-19 (agent runtime attestation profile), OQ-S-XPID-REV (XPID revocation gap) (NEW in -03), OQ-KIA-EVIDENCE-VIS (Evidence visibility to unintended verifiers) (NEW in -05) CVE defenses: CVE-2025-13609 class (S.15.10), CVE-2026-33697 class (S.15.11) (NEW in -03) C.3. Canonical Reference Specification: https://soosproject.ai/drafts/kia Datatracker: https://datatracker.ietf.org/doc/draft-sato-soos-kia/ Stack overview: https://soosproject.ai/stack Appendix D. Changes from Previous Versions (NEW in -04) D.1. Changes from draft-sato-soos-kia-05 This revision closes out a full WIMSE Security Review checklist pass (Stage 0 through Stage 2) run against -05, plus a bracket- annotation cleanup pass that required reconstructing this document's "carried forward from -02" sections against the actual -02/-03/-04 text rather than restating the annotation. All findings below were surfaced by one of those two processes. o Section 5.2 (RESTORED, substantive): -03's text claimed the GEC Manifest schema was "carried forward from -02 in full," but seven fields present in -02's schema -- manifest_version, manifest_id, issued_at, soos_conformance_version, cedar_policy_set_hashes[], so_type_registry_hash, and xstate_definition_hashes[] -- along with attestation_certificate, were silently absent from -03 through -05. Nothing in the SOOS UpgradeSprint records (June 23 - July 1, 2026) documents a decision to drop these fields; the most likely explanation is that the -03 authoring pass worked from Appendix C.2's abbreviated "RATS Evidence extension" field list rather than the full -02 Section 5.2 text, since -03's own authoring instructions describe adding kernel_keypair_fingerprint as though it were new, when it was already normative in -02. attestation_certificate's absence in particular contradicted Section 15.11's own CVE-2026-33697 defense text, which already assumed the field's presence. All eight fields are restored in this revision; no field is removed or renamed. This is a substantive change, not an editorial one -- flagged here rather than folded silently into the editorial bullet below. o Section 4.1, Section 13 (CONF-KIA-24, new): resolves a genuine bootstrapping contradiction between CONF-KIA-18 (refuse to sign any KIA artifact below FROST quorum) and CONF-KIA-19 (emit a signed KERNEL_AUDIT_ANOMALY alert on quorum failure). The alert is now a named, narrow exception to CONF-KIA-18, signed by whatever quorum is available or delivered unsigned out-of-band if fewer than two participants remain. o Section 6.2 (updated): the XPID namespace UUID is now a dedicated value minted for KIA ("447994dc-9ddf-578f-a851-3a77d8f7ae42") rather than the reused standard DNS namespace UUID, per [RFC9562] Section 6.5 guidance. xpid_derivation_version "1.1" is now the normative value; "1.0" remains valid for backward-compatible correlation against pre-(-06) audit history. o Section 15.9, Section 15.10 (corrected): wording describing the XPID as derived from "FROST threshold key material" corrected to match Section 6.2's actual derivation input, kernel_keypair_fingerprint (a public-key hash, not private threshold key material). o Section 15.13 (new): Denial of Service Security Considerations entry addressing the availability asymmetry created by CONF-KIA-18's quorum-failure refuse-to-sign requirement (compromising confidentiality/integrity requires t participants; denying availability requires isolating only n - t + 1). No prior requirement in Section 4.1 is changed; this is a disclosure and deployment-guidance addition. o Section 16 (new): Privacy Considerations, covering XPID linkability (Section 16.1), the relationship between Evidence access scoping and linkability blast radius (Section 16.2), and the immutability-vs-rotation tradeoff (Section 16.3). o [FROST] reference (updated): from the CFRG working draft to its published form, RFC 9591 (June 2024). Nonce-generation section citations in Section 4.1, Section 13, and Section 15.8 corrected from the working draft's "Section 5" to RFC 9591's actual Section 5.1 (Round One -- Commitment) and Section 4.1 (nonce_generate helper); Section 15.8 additionally cites RFC 9591 Section 7.3 ("Nonce Reuse Attacks"). o Editorial and structural: square-bracket style editorial and version-history tags -- both this document's own "NEW/UPDATED/ CLARIFIED/CORRECTED in -0X" section-header tags and the pre-existing "Carried forward from -02..." convention -- converted from square brackets to parentheses throughout, to avoid idnits REFERENCE_MISSING_IN_REFERENCE_SECTION false positives (idnits parses any bracketed token as an RFC citation). Abstract section-number references also removed (were also factually wrong for the -03 paragraph, which cited Sections 14.8-14.11 for what are actually Sections 15.8-15.11 after the Section 6 XPID insertion in -03). Beyond the mechanical bracket-to-paren conversion, every "carried forward from -02" section (Section 2's base terminology, Section 3, Sections 4.2-4.6, Section 5.1, Sections 5.3-5.5, Section 7, Section 8, Section 9, Section 10, Section 11, Section 12, Sections 14.1-14.2, Sections 15.2-15.7, Sections CONF-KIA-01 through CONF-KIA-15, and Appendix B.1-B.5) now carries its actual text inline instead of a bracketed provenance note -- readability feedback (Songbo Bu, on a separate but related draft) was that bracketed placeholder-style annotations read poorly for reviewers, not just badly for idnits. Provenance ("this text originates in -02, unchanged") now lives only in this Appendix D, not inline in the body. Two genuinely stale cross-references were caught and fixed in the process: Section 15.6's "Section 14.1" (should have read 15.1 under the post-XPID-insertion numbering) and Section 15.7's "Sections 4.4, 7" (Revocation Registry is Section 8, not 7) -- both invisible while the sections were bracket-only stubs, since nothing rendered them for a reader or a tool to catch. D.2. Changes from draft-sato-soos-kia-04 This revision addresses Finding 4 of DR-MJWT-KIA-CHECKLIST-01 (a WIMSE security review checklist dry-run against -03). Disclosure only; no mitigation mechanism, new fields, or normative behavior changes are introduced. o Section 6.6 (new): Discusses the Evidence-visibility gap in the Cross-Instance Trust Model (Section 6.3), citing `draft-ritz-seat-proxies` as the general pattern this instance follows. o Section 14.4 (new): OQ-KIA-EVIDENCE-VIS Open Issues entry, tracked at MEDIUM priority (topology-dependent, unlike OQ-S-XPID-REV's HIGH priority active-exploitation path). o Section 15.12 (new): Security Considerations entry for the same gap, mirroring the Section 6.4/14.3/15.9 treatment already used for OQ-S-XPID-REV. o Section 18 (informative references, as numbered in -05): Adds `draft-ritz-seat-proxies` as an informative reference. D.3. Changes from draft-sato-soos-kia-03 This is a registration-format correction only. No new event types, fields, or normative behavior are introduced. o IANA Considerations (Section 16 as numbered at the time): The GAR Authority Lifecycle Event Types Registry request for XPID_DERIVED and XPID_VERIFICATION_FAILED was reformatted from an ALE Name / Description table to the Event Type / Class / Reference columns that [I-D.sato-soos-gar] Section 16.3 actually defines for that registry. Both event types are assigned the newly-defined Class ID (Identity/Federation event). The required-fields prose previously packed into the Description column is now normative text following the table. o Identified by IANA early review #1456067, which flagged the -03 registration table as inconsistent with the target registry's schema. Acknowledgements The KIA trust chain architecture is modelled on the RATS architecture defined in RFC 9334 and the SPIFFE identity framework. The hardware attestation model follows TCG TPM 2.0 specifications. The SCITT integration in Appendix B.4 builds on the draft-ietf-scitt-architecture design. FROST threshold signing support (Section 4.1) was added in -03 following the SOOS UpgradeSprint Day 8 security pass (July 1, 2026, DR-DAY8-SEC-01). The FROST nonce reuse risk analysis (Section 15.8) and the implementation requirements are sourced from that session. The XPID design (Section 6) was developed during the SOOS UpgradeSprint (June 23 -- July 1, 2026) as the cross-instance identity correlation primitive. The CVE-2025-13609 class defense analysis (Section 15.10) and the CVE-2026-33697 class defense analysis (Section 15.11) were developed as part of the Day 8 security pass and are presented as RATS WG case studies at IETF 126 Vienna. The authors thank the RATS Working Group, the WIMSE Working Group, and the SCITT community for foundational work that made KIA's design possible. The RATS WG speaking request for Vienna is coordinated with Ned Smith. Author's Address Tom Sato MyAuberge K.K. Chino, Nagano, Japan Email: tomsato@myauberge.jp URI: https://soosproject.ai/drafts/kia