papers/lux-trust-kernel/sections/02-k-chain-key-registry-and-policy.tex

%% ===================================================================
%% LP-134 canonical naming (2025-12-15):
%% Per LP-134 (Lux Chain Topology), T-Chain has been split into:
%%   M-Chain — MPC ceremonies for bridge custody of EXTERNAL wallets
%%             (CGGMP21, FROST, Pulsar-general)
%%   F-Chain — FHE compute + TFHE bootstrap-key generation (encrypted EVM)
%% T-Chain is REMOVED entirely; teleport is B-Chain (bridgevm, LP-6000). No teleportvm.
%% Where this paper says "F-Chain MPC" / "F-Chain threshold governance" /
%% "F-Chain TFHE" / "F-Chain custody", read as M-Chain (MPC) or F-Chain (FHE).
%% ===================================================================

\section{K-Chain: Key Registry and Policy}
\label{sec:kchain}
%% ===================================================================

The K-Chain is a purpose-built chain within the Lux primary network that manages
the lifecycle of cryptographic keys. It does not store encrypted data; it stores
\emph{policy about keys}.

\subsection{Key Registry}

\begin{definition}[Key Record]\label{def:key-record}
A key record $\kappa$ is a tuple:
\[
    \kappa = (\mathsf{id}, \mathsf{pk}, \mathsf{alg}, \mathsf{caps}, \mathsf{policy},
              \mathsf{created}, \mathsf{expires}, \mathsf{status})
\]
where $\mathsf{id} \in \{0,1\}^{256}$ is the key identifier, $\mathsf{pk}$ is the
public key, $\mathsf{alg} \in \{\text{ML-KEM-768}, \text{ML-KEM-1024}, \text{Ed25519},
\text{ML-DSA-65}, \text{secp256k1}\}$ is the algorithm identifier, $\mathsf{caps}$
is a capability bitfield, $\mathsf{policy}$ is a policy predicate,
$\mathsf{created}$ and $\mathsf{expires}$ are block heights, and
$\mathsf{status} \in \{\textsc{active}, \textsc{rotated}, \textsc{revoked}\}$.
\end{definition}

\subsection{ML-KEM Wrapping}

Keys stored in capsule vaults are wrapped using ML-KEM (FIPS~203) as specified in
\cite{lux-pq-crypto-suite}. The K-Chain stores only the public encapsulation key
$\mathsf{ek}$ and the policy governing who may request encapsulation. The wrapped
key material never appears on-chain.

\begin{definition}[Wrapping Policy]\label{def:wrap-policy}
A wrapping policy $\pi_w$ for key record $\kappa$ is a predicate over requestor
identity and context:
\[
    \pi_w : \mathsf{DID} \times \mathsf{Context} \to \{\top, \bot\}
\]
where $\mathsf{Context}$ includes the requestor's capability set, the current block
height, and an optional threshold requirement.
\end{definition}

When a capsule requires a wrapped key, it submits a \textsc{WrapRequest} transaction
to the K-Chain. The chain evaluates $\pi_w$ against the requestor's DID and, if
satisfied, emits a \textsc{WrapGrant} receipt containing the ML-KEM ciphertext
$c = \mathsf{Encaps}(\mathsf{ek}; r)$ and the shared secret $K$ is delivered
to the requestor off-chain via a secure channel.

\subsection{Rotation Policy}

\begin{definition}[Rotation Rule]\label{def:rotation}
A rotation rule $\rho$ for key $\kappa$ specifies:
\[
    \rho = (\mathsf{max\_age}, \mathsf{successor\_alg}, \mathsf{approval\_threshold},
            \mathsf{grace\_period})
\]
The K-Chain enforces that no key remains active beyond $\mathsf{max\_age}$ blocks
past $\kappa.\mathsf{created}$. Upon rotation, the old key enters
$\textsc{rotated}$ status and a new key record is created with algorithm
$\mathsf{successor\_alg}$.
\end{definition}

Rotation may be triggered by three events: (1)~age expiry, (2)~explicit owner request,
or (3)~threshold governance vote on the F-Chain. In cases (1) and (3), the rotation
is mandatory and produces a \textsc{RotationReceipt} regardless of owner action.

\subsection{Capability Grants and Revocation}

Capabilities are delegated via \textsc{GrantCap} transactions that append to the
key record's capability set. Each grant is scoped to a specific DID, a capability
type (read, sign, admin), and an optional time bound.

Revocation is immediate and final. A \textsc{RevokeCap} transaction sets the
capability's status to revoked and emits a \textsc{RevocationReceipt}. The receipt
includes the revoked capability hash, the revoking authority's DID, and the block
height, providing a permanent audit trail.

\begin{proposition}[Revocation Finality]\label{prop:revocation}
Once a \textsc{RevocationReceipt} is finalized on the K-Chain, no subsequent
transaction can restore the revoked capability for the same key--DID pair.
\end{proposition}

%% ===================================================================