fix: JWT signing key is never the SPIRE key, even when SPIRE is active

[manzil-infinity180]

Summary

In MCP mode, initAuth() always generates a fresh ephemeral ECDSA P-256 key for JWT signing — even when initSigning() has just successfully connected to SPIRE and obtained an SVID. The JWT signing identity and the attestation signing identity are two independent ephemeral objects, which contradicts the paper §3.2 model of a single server identity backed by SPIRE.

Evidence

internal/mcp/server.go:392-400:

func (s *Server) initAuth() error {
    // For now, always use ephemeral key. When SPIRE integration provides a
    // crypto.Signer, use auth.NewTokenIssuerFromSigner instead.
    issuer, err := auth.NewTokenIssuer()
    if err != nil {
        return fmt.Errorf("create token issuer: %w", err)
    }
    s.tokenIssuer = issuer
    return nil
}

The comment acknowledges the gap. auth.NewTokenIssuerFromSigner exists at internal/auth/jwt.go:69 but has zero callers.

Why this matters

• Paper §3.2 diagram shows one "Signing Key (Server Holds)" object used for the agent's JWT and attestations alike
• With separate ephemeral keys, the SPIRE SVID only gates attestation signing; the JWT is effectively self-signed by a key that dies with the process
• Verifying JWTs against any external trust anchor (SPIRE trust bundle, OIDC discovery, etc.) is impossible
• Session replays across processes fail even when they should succeed — each new aflock serve process has a new key

Proposed fix

In initAuth(), when s.signer has completed Initialize() (SPIRE branch) successfully, extract the crypto.Signer and use it:

func (s *Server) initAuth() error {
    if s.signer != nil {
        if id, _ := s.signer.GetSigningIdentity(); id != nil {
            if priv, ok := id.PrivateKey.(crypto.Signer); ok {
                s.tokenIssuer = auth.NewTokenIssuerFromSigner(priv, id.SPIFFEID.String())
                return nil
            }
        }
    }
    issuer, err := auth.NewTokenIssuer()
    if err != nil {
        return fmt.Errorf("create token issuer: %w", err)
    }
    s.tokenIssuer = issuer
    return nil
}

Notes:

• SPIRE's default X509-SVID key is ECDSA P-256 by default → jwt.SigningMethodES256 stays correct
• Fulcio path also provides a crypto.Signer (via rookery/plugins/signers/fulcio) but with a very short TTL (~10 min); not a great JWT signer — keep ephemeral for that branch
• For the ephemeral branch, current behavior is fine

Verification

After fix, with SPIRE active:

1. aflock get_token → decoded JWT header kid should equal the SPIRE SVID string, not "ephemeral-ecdsa-p256"
2. JWT validates against the X.509 public key in the SPIRE trust bundle
3. Attestation keyid and JWT kid reference the same SPIFFE ID

Related

• PR security: hardening pass — closes #54 #55 #56 #57 #58 #59 #60 #61 #67 closes fix: MCP server needs signing fallback chain (SPIRE → Fulcio → ephemeral) #55 (attestation signing fallback) — this issue is the JWT-signing analogue
• fix: attestation signing path does not validate JWT — signing key separation incomplete #40 covers a different integration gap (JWT not validated before signing attestations)
• arch: dedicated signing service for true key separation #62 is the broader "dedicated signing service" architecture

[manzil-infinity180]

Concrete evidence — captured live on macOS with PR #88 + SPIRE

Repro setup:

• Branch fix/identity-discovery-63 (PR feat(identity): peer-PID binary digest + env per paper3.1 #88 peer-cred)
• Native SPIRE 1.11.1 server + agent on macOS (no Docker)
• Workload entry registered for the aflock binary SHA
• aflock UDS server started with SPIFFE_ENDPOINT_SOCKET=unix:///tmp/spire-native/sockets/api.sock
• Server log confirmed: Attestation signing: SPIRE and JWT authorization enabled
• Claude Code session over a stdio↔UDS socat bridge calling
  mcp__aflock-uds__get_token

The minted JWT exposes the contradiction directly:

HEADER

{
  "alg": "ES256",
  "kid": "ephemeral-ecdsa-p256",
  "typ": "JWT"
}

CLAIMS (selected)

{
  "iss": "aflock",
  "sub": "spiffe://aflock.ai/agent/claude-opus-4-7/4-7-0/b4d15ed93f404e8b",
  "agent_id": "spiffe://aflock.ai/agent/claude-opus-4-7/4-7-0/b4d15ed93f404e8b",
  "identity_hash": "b4d15ed93f404e8b4717bcf90313fda9d2a67799317468214634e5696f70b854",
  "aud": ["mcp-96f0e821-48c0-44d8-8a54-0b27f232ac2e"],
  "policy_digest": "17b0ca0437974a45bde46e7fd83e855d3420cb7ea01b8200797158dd10add55f"
}

The body claims SPIFFE identity (sub, agent_id use the
spiffe://aflock.ai/agent/... URN). The signature is rooted in an
ephemeral in-memory ECDSA P-256 key that aflock generates at
process start, never persists, never registers with SPIRE.

Two different trust chains in the same process

In the same session that produced this JWT, the DSSE-signed
attestations carry a SPIRE-rooted signature:

attestation.signatures[0].keyid = "spiffe://aflock.local/agent/aflock"
attestation.signatures[0].certificate = <X.509 SVID issued by SPIRE>

So we have:

Path	Signer	Verifiable externally?
Attestations (DSSE)	SPIRE-issued X.509 SVID	✅ chains to SPIRE CA
JWT (auth tokens)	aflock-internal ephemeral ECDSA	❌ rootless

A downstream verifier holding the SPIRE bundle can cryptographically
trust the attestations but cannot trust the JWT — the only place
the JWT-signing key exists is the issuing aflock process's RAM.
The sub: spiffe://... claim is a misleading string label, not a
verifiable assertion.

Why this is broken in practice

• Anyone who reads the issuing process's memory can forge tokens.
• Restarting aflock invalidates every previously-issued JWT silently
  (new ephemeral keypair, no rotation announcement).
• Multi-instance aflock deployments cannot cross-verify each other's
  tokens — each has its own ephemeral key.
• The sub: spiffe://... claim lulls integrators into assuming
  SPIFFE-grade trust where none exists.

Suggested fixes (either closes #71)

Option A — SPIRE-issued JWT-SVID (canonical SPIFFE pattern)

• Call WorkloadAPI.FetchJWTSVID(ctx, audience) against the same
  workload-API socket already used for X.509 SVIDs.
• Header kid becomes a real SPIRE-issued key id.
• Verifiers fetch the JWT bundle from SPIRE and validate normally.

Option B — sign with the X.509 SVID's private key

• Reuse the X.509 SVID private key already cached for DSSE signing.
• Set kid to the SVID cert's thumbprint (or serial); embed the cert
  chain in x5c if compactness is not critical.
• Verifiers chain through the SVID cert to the SPIRE CA bundle.

Option A is the SPIFFE-canonical answer. Option B is shorter to ship
and uses key material aflock already has. Either way, the goal is the
same: every signature aflock emits should chain to a single SPIRE
trust root, with no ephemeral fallback when SPIRE is healthy.

Files touched

• internal/auth/jwt.go — JWT signer wiring
• internal/identity/spire.go — SVID fetch (already exists)
• Wherever the ephemeral signer is constructed at startup — needs to
  become a fallback only when SPIRE is unavailable, not the default
  when SPIRE is active.

Acceptance

• With SPIRE active, every issued JWT verifies against the SPIRE bundle.
• With SPIRE absent, the JWT clearly indicates ephemeral signing
  (e.g. iss: "aflock-ephemeral" or non-spiffe sub URN) so consumers
  can refuse SPIFFE-grade trust paths.
• A regression test asserts header kid matches a SPIRE-served key id
  when the workload-API socket is reachable.

[manzil-infinity180]

[manzil-infinity180]

fixed #102