codexproof

glossary / Signing proxy

the per-domain sidecar holding that domain's signing key - namespace- pinned, reachable only from inside, doing exactly one job: sign templates whose names it owns, refuse everything else.

namespacegatewayjit capture
Signing proxy - The proxy's moment in the sequence: veto check, eleven microseconds of Ed25519, nothing else

The proxy's moment in the sequence: veto check, eleven microseconds of Ed25519, nothing else.

Etymology and backstory

the proxy pattern for key custody is how industry learned to stop scattering secrets: concentrate the private key behind a narrow service (HSMs, KMS, ssh-agent, Sigstore's Fulcio) so applications request signatures instead of holding keys. Codexproof applies it per trust domain: one proxy, one namespace, one secret.

Ecosystem

cloud KMS services, PKCS#11 HSM fronts, Vault transit engines, ssh-agent - all "the key lives behind a socket" designs.

In codexproof

the stock prov-signer binary configured by exactly two declarations - PROV_SIGNER_SECRET and PROV_NAMESPACE - with the single veto at line 149: names outside the pin get 403 and no signature. No custom per-spoke code (the +1-integration property). The measured hot path: ~74us of loopback round-trip around ~11us of Ed25519. Discretion at onboarding, none at the moment of signing (the Q-file's eight-word integrity story).

"The proxy is the domain's pen, kept in the domain's pocket - the gateway drafts, the proxy signs, and the pen refuses to write outside its own margins."
References: PKCS#11 / HSM tradition for key-behind-a-socket; the paper's capture section for the dispatch protocol.

All terms · Questions & answers · The verifier