Kernel Identity and Attestation for Governing Enforcement Components
draft-sato-soos-kia-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Author | Tom Sato | ||
| Last updated | 2026-06-10 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-sato-soos-kia-00
Internet Engineering Task Force T. Sato
Internet-Draft MyAuberge K.K.
Intended Status: Standards Track 9 June 2026
Expires: 9 December 2026
Kernel Identity and Attestation for Governing Enforcement Components
draft-sato-soos-kia-00
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.
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 9 December 2026.
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
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
5.1. Purpose
5.2. Schema
5.3. Issuance Triggers
5.4. Staleness
5.5. PTD Consistency Requirement
6. Event Log Signing (INV-9)
6.1. Scope
6.2. Canonical Form
6.3. Signed Event Classes
7. Revocation Registry (INV-11)
7.1. Structure
7.2. Rebuild on Restart
7.3. Revocation Authority
7.4. Agent Revocation Prohibition
8. Policy Change Attestation (INV-10)
9. Federation and Cross-Instance Verification
10. GEC as RATS Attester
11. Relationship to WIMSE
12. Conformance
13. Open Issues
13.1. OQ-S-18: Deployment Topology
13.2. OQ-S-19: Agent Runtime Attestation Profile
14. Security Considerations
14.1. Private Key Extraction
14.2. GEC Manifest Forgery
14.3. Policy Hash Manipulation
14.4. Revocation Registry Incompleteness
14.5. Cascade Revocation Race
14.6. Implementation Degradation
14.7. Agent Session Revocation
15. IANA Considerations
16. Normative References
17. Informative References
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
Appendix C. Vibe Coding Assets
C.1. Protocol Summary
C.2. Key Identifiers
C.3. Canonical Reference
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 -- no agent may modify governed
object state except through the GEC's execution sequence. 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: the sequence of cryptographic
relationships 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
current runtime state, issued at deployment and reissued on
every policy change (INV-10). The GEC Manifest is the
document an external verifier, a federated kernel instance,
or an agent uses to establish trust in a kernel before
submitting a mandate or accepting an Event Log entry.
(3) The Revocation Registry maintenance requirements (INV-11):
the kernel-maintained index of revoked mandate JWT IDs,
rebuilt from the Event Log on restart, checked at every
mandate presentation.
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). The operator
root keypair holder is the RATS Endorser; the GEC Attestation
Certificate is the RATS Endorsement. Any external system consuming
Event Log entries or GEC Manifests is a RATS Relying Party. The
complete RATS role mapping is specified in Section 10.
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. The kernel's identity
anchor is the operator root keypair and the hardware attestation
layer beneath it. KIA grounds that anchor; Cedar governs what
the GEC permits; together they form the enforcement physics of
SOOS.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD 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.
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 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.
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.
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_REVOCATION_ISSUED 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 Kernel
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
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.
The GEC keypair is the operational keypair for the deployment
lifetime. Keypair rotation is an operator-initiated operation
requiring issuance of a new GEC Attestation Certificate and
a new GEC Manifest. All Event Log entries signed under the
prior keypair remain valid under the prior keypair fingerprint.
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 6.
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_REVOCATION_ISSUED 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 7.
4.5. Agent-Kernel Mutual Authentication
KIA SHOULD support an agent-kernel mutual authentication handshake
before mandate presentation. The handshake allows the agent to
verify the GEC's identity (via the GEC Manifest) and the
kernel to verify the agent's identity (via the agent's Party
Registry keypair) before the agent submits a mandate JWT.
For Class 2 and Class 3 agents (as defined in
draft-sato-soos-idp-04 Section 6.4), this handshake SHOULD be
performed at session initialisation. For Class 1 agents, the
handshake is OPTIONAL.
The mutual authentication handshake protocol is:
(1) Agent requests the current GEC Manifest from the kernel
API endpoint.
(2) Agent verifies the GEC Manifest signature against the
kernel public key fingerprint it holds (obtained via operator
provisioning or prior GEC Manifest).
(3) Agent verifies the attestation_certificate in the Kernel
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 Kernel
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 Kernel
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
KernelManifest {
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 Ed25519 public key held by this kernel instance.
This is the fingerprint against which all Event Log entry
kernel_signature fields are verified. This field also serves
as the GEC instance identifier: a stable, globally unique
reference to this kernel deployment. External systems --
including MJWT aud claim binding (draft-sato-soos-mjwt) --
MUST retrieve this value from the GEC Manifest via the kernel
API endpoint before constructing audience-bound tokens.
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 10).
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 10).
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 10).
attestation_timestamp
Unix timestamp (UTC seconds). Moment of GEC Manifest
issuance. Relying Parties SHOULD verify freshness; the
recommended maximum staleness for production deployments is
86400 seconds (24 hours). RATS Evidence extension field
(Section 10).
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 10).
Recommended values:
"vtpm:azure-confidential-vm"
"vtpm:aws-nitro-enclave"
"vtpm:gcp-confidential-compute"
"software-key-storage"
"shared-keypair:multi-region"
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)
and deployment_constraints[] if present, 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.
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 12) enforces this requirement
normatively.
6. Event Log Signing (INV-9)
6.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_REVOCATION_ISSUED
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
6.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.
6.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
HEMContext 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_REVOCATION_ISSUED: 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.
7. Revocation Registry (INV-11)
7.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_REVOCATION_ISSUED 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_REVOCATION_ISSUED>,
revoked_at: <ISO-8601>,
revocation_scope: "THIS_MANDATE_ONLY" |
"CASCADE_TO_DESCENDANTS",
transaction_disposition: "COMPLETE_SAFE" |
"SUSPEND_ALL" |
"ROLLBACK_AVAILABLE"
}
The Revocation Registry contains all jtis listed in all
revoked_mandate_jwt_ids arrays of all MANDATE_REVOCATION_ISSUED
events in the Event Log, including all jtis added by
CASCADE_TO_DESCENDANTS expansion.
7.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_REVOCATION_ISSUED event with a valid
authority_signature and kernel_signature, add all jtis in
revoked_mandate_jwt_ids to the Revocation Registry.
(3) For each CASCADE_TO_DESCENDANTS revocation, traverse the
mandate issuance tree (maintained in the Party Registry) and
add all descendant jtis.
(4) 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.
7.3. Revocation Authority
Only a human-held Party Registry principal may issue
MANDATE_REVOCATION_ISSUED 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_REVOCATION_ISSUED 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.
7.4. Agent Revocation Prohibition
An agent MUST NOT issue MANDATE_REVOCATION_ISSUED 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.
8. 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.
9. 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 Kernel
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.
10. 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.
11. 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 13.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.
12. 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_REVOCATION_ISSUED 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_REVOCATION_ISSUED 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 HEMContext
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.
13. Open Issues
13.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.
13.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. Security Considerations
14.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.
14.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 Kernel
Manifest forgery. Implementations MUST verify the
attestation_certificate as part of any GEC Manifest
verification procedure.
14.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 Kernel
Manifest reissuance can cause the GEC to evaluate transitions
under an unattempted policy set while presenting a stale Kernel
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.
14.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.
14.5. Cascade Revocation Race
In a CASCADE_TO_DESCENDANTS revocation, the GEC adds all
descendant jtis to the Revocation Registry atomically. A non-
atomic implementation risks a window where the parent mandate is
revoked but descendant mandates remain valid. Implementations
MUST add all jtis (parent and all descendants) to the Revocation
Registry in a single atomic operation, consistent with the
MANDATE_REVOCATION_ISSUED event's revoked_mandate_jwt_ids array.
14.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 14.1 (private key extraction).
14.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, 7) 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. IANA Considerations
This document has no IANA actions at this time. A successor
document will define the SOOS GEC Manifest registry and the
Agent Runtime Attestation Profile registry.
16. 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>.
[WIMSE-ARCH]
Salomoni, D. et al., "WIMSE Architecture",
draft-ietf-wimse-arch-07, Work in Progress, March 2026.
[SOOS-AEP] Sato, T., "Agent Execution Protocol",
draft-sato-soos-aep-01, Work in Progress, June 2026.
[SOOS-CAP] Sato, T., "Constitutional AI Protocol",
draft-sato-soos-cap-03, Work in Progress, June 2026.
[SOOS-GAR] Sato, T., "Governance Audit Record",
draft-sato-soos-gar-02, June 2026.
[SOOS-HEM] Sato, T., "Human Escalation Mechanism",
draft-sato-soos-hem-04, Work in Progress, June 2026.
[SOOS-MAD] Sato, T., "Multi-Agent Delegation",
draft-sato-soos-mad-02, Work in Progress, June 2026.
[SOOS-MJWT] Sato, T., "Mandate JWT",
draft-sato-soos-mjwt-01, June 2026.
[SOOS-SOV] Sato, T., "Sovereign Object",
draft-sato-soos-sov-01, June 2026.
17. Informative References
[SOOS-IDP] Sato, T., "Intent Declaration Primitive",
draft-sato-soos-idp-04, June 2026.
[RFC8037] Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman
(ECDH) and Signatures in JSON Object Signing and
Encryption (JOSE)", RFC 8037, DOI 10.17487/RFC8037,
January 2017,
<https://www.rfc-editor.org/rfc/rfc8037>.
[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.
Appendix B. Related Work
This appendix situates KIA within the broader attestation and
identity standards landscape. KIA is an application of
established attestation patterns -- primarily RATS (RFC 9334) --
to the specific requirements of a kernel-governed agentic AI
execution environment.
B.1. RATS Architecture (RFC 9334)
The normative RATS role mapping for KIA is specified in Section 10.
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 11.
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 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
KIA is one of twelve SOOS IETF individual submissions. The drafts
that directly depend on KIA are:
draft-sato-soos-gar-02 Governance Audit Record. Submits KIA-
signed Event Log entries to a SCITT
transparency service. GAR is the
external audit consumer of KIA.
draft-sato-soos-mad-02 Multi-Agent Delegation. All cluster
events (Section 6.1) are signed by KIA.
The mandate issuance tree in MAD depends
on the Party Registry, which is managed
by the same kernel that KIA signs for.
draft-sato-soos-hem-04 Human Escalation Mechanism. HEM_INVOKED,
HEM_RESOLVED, and HEM_TIMEOUT are KIA-
signed (CONF-KIA-10). The human
principal_signature in HEMDecision is
wrapped by the KIA kernel_signature.
draft-sato-soos-aep-01 Agent Execution Protocol. AEP_SENSE_
DELIVERED and AEP_SESSION_CLOSED are
KIA-signed (Section 6.1).
draft-sato-soos-mjwt-01 Mandate JWT. INV-11 (the Revocation
Registry) is a KIA responsibility
(Section 7). MANDATE_REVOCATION_ISSUED
is KIA-signed. The MJWT aud claim MUST
be bound to the kernel_keypair_fingerprint
retrieved from the GEC Manifest (Section
5.2).
Appendix C. Vibe Coding Assets
This appendix provides structured machine-readable references to
support AI-assisted implementation of KIA. Informative.
C.1. Protocol Summary
Protocol: Kernel Identity and Attestation (KIA)
Version: draft-sato-soos-kia-00
Family: SOOS protocol suite
Role: Layer 0 signing and attestation -- GEC keypair management,
GEC Manifest issuance, 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 (audit signing), MJWT
(revocation registry), MAD (cluster event signing),
and HEM (HEM event signing).
C.2. Key Identifiers
Trust chain: Hardware Root -> Operator Root Keypair ->
GEC Attestation Certificate -> GEC Manifest ->
Event Log entries -> Cedar evaluations -> Sovereign Objects
GEC Manifest fields (RATS Evidence extension):
loaded_policy_ids[], cedar_policy_hash, kernel_version,
attestation_timestamp, deployment_constraints[]
Conformance identifiers: CONF-KIA-01 through CONF-KIA-15
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)
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
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. The authors thank the RATS
Working Group, the WIMSE Working Group, and the SCITT community
for foundational work that made KIA's design possible.
Author's Address
Tom Sato
MyAuberge K.K.
Chino, Nagano, Japan
Email: tomsato@myauberge.jp
URI: https://soosproject.ai/drafts/kia