Key rotation policy
This page documents the key management and rotation policy for all cryptographic material CloakAPI controls. For keys controlled by the customer (e.g. their own LLM provider API keys stored via BYOK), see the Gateway authentication page.
Receipt signing keys
Receipt signing keys are used to produce the ECDSA signatures on signed receipt envelopes. They are the most security-critical keys in the system.
| Property | Value |
|---|---|
| Algorithm | ECDSA P-256 (secp256r1) |
Key ID (kid) format | gw-{region}-{YYYY}-q{quarter} — example: gw-prod-2026-q2 |
| Rotation period | Every 90 days |
| Overlap window | New key activated 7 days before old key stops signing, so in-flight receipts are always produced by the live key |
| Retention for verification | Old keys are retained for 7 years after rotation |
| Post-rotation status | Old kid entries are marked revoked: true in the JWKS — they can no longer sign new receipts but remain valid for historical verification |
JWKS endpoint
https://api.cloakapi.io/api/.well-known/cloakapi-receipt-pubkeys.jwksThis endpoint returns a standard JWK Set. Each entry includes:
kid— key identifier ingw-{region}-{YYYY}-q{quarter}formatkty—"EC"crv—"P-256"x,y— public key coordinates (base64url)use—"sig"revoked—truefor keys past their signing period (only present on revoked keys)
Example entry for an active key:
{ "kid": "gw-prod-2026-q2", "kty": "EC", "crv": "P-256", "use": "sig", "x-cloakapi-active": true, "x": "<base64url>", "y": "<base64url>"}Example entry for a revoked key (can still verify historical receipts):
{ "kid": "gw-prod-2026-q1", "kty": "EC", "crv": "P-256", "use": "sig", "revoked": true, "x": "<base64url>", "y": "<base64url>"}Rotation schedule
Keys are named after the quarter they are activated. A gw-prod-2026-q2 key begins signing in Q2 2026 (April) and is superseded in Q3 2026 (July). The overlap window means receipts signed near the boundary may carry either kid.
Customer API keys
Customer API keys authenticate requests to the CloakAPI gateway.
| Property | Value |
|---|---|
| Rotation | User-driven — rotated on demand from the dashboard or via the management API |
| Grace period | None — rotation deactivates the old key immediately and atomically (the new key is created and the old key deactivated in the same transaction). Have the new key deployed before you rely on it. |
| Format | cloak_live_<43 url-safe base64 chars> (32 random bytes); all keys carry the cloak_ prefix |
| Storage | Keys are stored as SHA-256 hashes server-side. The plaintext is shown once at creation and not recoverable |
| Revocation | Immediate — a revoked key fails with HTTP 401 within seconds of revocation |
| Expiry | No automatic expiry |
Rotation procedure
- In the dashboard go to Settings → API keys → Rotate.
- A new key is generated and displayed once — copy it immediately.
- The old key is deactivated at the moment of rotation — there is no grace window. Deploy the new key to your application right away.
- If a key is believed compromised, Revoke and Rotate are equally immediate; either invalidates the old key at once.
HSM / KMS path
Key ID reference table
kid | Status | Notes |
|---|---|---|
gw-prod-2026-q2 | Active | Current signing key, Q2 2026 |
| Earlier keys | Revoked | Available in JWKS for historical receipt verification |
This table reflects the state at documentation publish time. The JWKS endpoint is always authoritative.