Kernel Identity and Attestation for Governing Enforcement Components
draft-sato-soos-kia-07
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Tom Sato | ||
| Last updated | 2026-09-07 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
Additional Web Page
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-sato-soos-kia-07
Internet Engineering Task Force T. Sato
Internet-Draft MyAuberge K.K.
Intended Status: Standards Track 7 September 2026
Expires: 7 March 2027
Kernel Identity and Attestation for Governing Enforcement Components
draft-sato-soos-kia-07
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.
Version -07 is an editorial revision with no normative content
changes: sibling-draft citations had gone stale against those
drafts' current live versions and are updated to
draft-sato-soos-cap-06, draft-sato-soos-gar-08,
draft-sato-soos-mad-05, draft-sato-soos-mjwt-06, and
draft-sato-soos-idp-06; the companion-drafts discussion's HEM
and AEP mentions are similarly updated to hem-07 and aep-04.
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 7 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:<t>-<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
[I-D.sato-soos-aep] Section 13), 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:<t>-<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": "<XPID value>"
},
"jti_revoked": "<revoked mandate JWT jti>",
"revocation_type": "direct" |
"cascade",
"cascade_root_mandate_id": "<jti of the directly-revoked
ancestor, present only when
revocation_type is cascade>",
"originating_kernel": "<kernel_keypair_fingerprint>",
"revoked_at": "<ISO-8601 UTC>"
}
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<jti_string, RevocationRecord>
}
RevocationRecord {
revoked_jti: <jti>,
revocation_event_id: <UUID of MANDATE_REVOKED>,
revoked_at: <ISO-8601>,
revocation_type: "DIRECT" |
"CASCADE",
cascade_root_jti: <jti of the directly-revoked ancestor,
present only when revocation_type is
"CASCADE">,
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:<t>-<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,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
RFC 2119 Key Words", BCP 14, RFC 8174,
DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/rfc/rfc8174>.
[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,
<https://www.rfc-editor.org/rfc/rfc9334>.
[RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally
Unique IDentifiers (UUIDs)", RFC 9562, May 2024,
<https://www.rfc-editor.org/rfc/rfc9562>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs",
BCP 26, RFC 8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>.
[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,
<https://www.rfc-editor.org/rfc/rfc9591>.
(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-06, Work in Progress, September
2026.
[SOOS-GAR] Sato, T., "Governance Audit Record",
draft-sato-soos-gar-08, September 2026.
[SOOS-MAD] Sato, T., "Multi-Agent Delegation",
draft-sato-soos-mad-05, Work in Progress, September
2026.
[SOOS-MJWT] Sato, T., "Mandate JWT",
draft-sato-soos-mjwt-06, September 2026.
19. Informative References
[SOOS-IDP] Sato, T., "Intent Declaration Primitive",
draft-sato-soos-idp-06, September 2026.
[I-D.sato-soos-aep]
Sato, T., "The Agent Execution Protocol (AEP) for
Agentic AI Systems", draft-sato-soos-aep-04,
September 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.
<https://access.redhat.com/security/cve/CVE-2025-13609>
(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-05 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-07 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-04 Agent Execution Protocol. AEP session
events are KIA-signed.
draft-sato-soos-mjwt-06 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-06 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:<t>-<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