TLS Delegated Credentials (RFC 9345) — Edge Key Isolation Playbook

Date: 2026-03-30
Category: knowledge
Audience: security engineering / edge platform / SRE / PKI operators

1) Why this matters

If you terminate TLS across many edge locations, your leaf private key becomes a high-value asset with broad blast radius.

Delegated Credentials (DCs) let you keep the CA-issued certificate model, but delegate short-lived handshake signing authority to ephemeral keys at the edge. In practice, this gives you:

• smaller key-exposure window (hours to days vs long-lived cert key material),
• fewer online uses of the leaf private key,
• better operational flexibility for algorithm rollout,
• improved reliability for remote-key architectures (fewer per-handshake key-server round trips in supported clients).

2) Protocol essentials (what to remember)

From RFC 9345:

1. TLS/DTLS 1.3+ only (not for pre-1.3 handshakes).
2. Client/server negotiates support using delegated_credential extension (type 34).
3. A DC contains:
   • delegated public key,
   • validity (valid_time),
   • algorithm metadata,
   • signature by the end-entity certificate private key.
4. Default max validity is 7 days (unless profile specifies otherwise).
5. DC validity must not extend past the parent certificate validity.
6. The end-entity cert must explicitly allow delegation via DelegationUsage extension (OID 1.3.6.1.4.1.44363.44, non-critical).

Operationally: this is a constrained delegation primitive, not a new PKI.

3) Security model: what improves, what does not

Improves

• Edge compromise no longer necessarily exposes long-lived leaf keys.
• Incident dwell-time value drops when delegated keys are aggressively short-lived.
• Keyless / remote-signing deployments can reduce handshake latency for DC-capable clients.

Does not magically improve

• No standalone revocation channel for a stolen DC: practical kill path remains certificate-level controls and waiting out DC expiry.
• Client ecosystem support is still uneven; legacy clients fall back to classic cert-key handshake behavior.
• Misconfigured issuance pipelines can accidentally create long validity windows (if policy checks are weak).

4) Architecture pattern that works in production

A. Signer tier (high trust)

• Holds leaf private key (HSM/KMS strongly preferred).
• Mints DCs on schedule (e.g., every 6-24h).
• Enforces strict policy:
  • max DC TTL,
  • allowed signature schemes,
  • cert-binding checks,
  • audit metadata.

B. Distribution tier

• Pushes fresh DC bundles to edge POPs.
• Uses versioned artifact IDs + monotonic activation windows.
• Supports rollback to previous known-good DC bundle.

C. Edge termination tier

• Uses delegated key for CertificateVerify only when client negotiated DC support.
• Falls back cleanly to normal certificate-key flow otherwise.
• Exposes telemetry for negotiated-vs-fallback ratio.

5) Rollout playbook (practical sequence)

Phase 0 — Readiness gates

• Confirm CA profile can issue certs with DelegationUsage extension.
• Confirm TLS stack behavior in your runtime (server path + validation path).
• Add policy tests that reject DC TTL > org maximum (often far below RFC max).

Phase 1 — Canary with strict TTL

• Start with one hostname / low-risk edge group.
• Use short DC lifetime (e.g., 12-24h) and frequent rotation.
• Observe handshake success delta between DC-enabled and control cohorts.

Phase 2 — Expand by client-compatibility data

• Expand where user-agent mix shows stable negotiation.
• Keep fallback enabled for all unsupported clients.
• Watch for clock-skew-driven failures and regional outliers.

Phase 3 — Security hardening

• Reduce signer privilege surface.
• Encrypt and attest DC distribution channel.
• Add emergency “stop minting + forced fallback” runbook drills.

6) Policy defaults to set on day 1

• Org DC max TTL: 24h (or tighter), even though RFC default cap is 7 days.
• Overlap window: minimal but non-zero (for propagation jitter).
• Mint cadence: at least 2x faster than TTL.
• Signer isolation: separate role/account from normal TLS edge operations.
• Artifact retention: keep signed DC metadata for forensics, not private delegated keys.

7) Observability: minimum dashboard

Track these per region, SNI, and client family:

• DC negotiation rate (% handshakes using DC).
• Handshake failure rate: DC vs non-DC.
• Failure reasons split:
  • unsupported extension,
  • invalid signature,
  • expired/not-yet-valid,
  • algorithm mismatch,
  • cert extension missing.
• Median/P95 handshake latency deltas (especially in keyless deployments).
• DC mint/distribution lag (signer time → edge active time).

If you can’t see these, you can’t operate DCs safely.

8) Common failure modes and fast responses

1. Clock skew causes “expired” DC rejects
   Response: shorten distribution lag, add overlap buffer, verify NTP hygiene, widen alerting on skew-heavy ASNs/regions.

2. CA issued cert without DelegationUsage extension
   Response: fail closed in preprod checks; never promote certs missing delegation policy bits.

3. Algorithm mismatch between negotiated schemes and minted DC
   Response: enforce scheme compatibility matrix in mint pipeline before publish.

4. Signer outage during rotation window
   Response: keep last-known-good DC active until expiry; have tested fallback to non-DC handshake path.

9) Decision rule

Adopt Delegated Credentials if all are true:

• you terminate TLS at scale across lower-trust edges,
• private-key exposure window is a top risk,
• you can operate a reliable mint/distribution pipeline,
• you can measure DC-specific handshake outcomes.

Delay adoption if:

• your client base is dominated by stacks without practical DC support,
• your cert procurement flow cannot consistently include DelegationUsage,
• you cannot run strict rotation and telemetry discipline.

10) Bottom line

Delegated Credentials are a high-leverage middle path between “long-lived cert keys everywhere” and “fully remote signing on every handshake.”

Treat DC as an operational security system, not just a TLS checkbox:

• short lifetimes,
• strict signer isolation,
• measured fallback behavior,
• continuous telemetry.

That combination gives real blast-radius reduction without sacrificing uptime.

References

1. RFC 9345 — Delegated Credentials for TLS and DTLS
   https://www.rfc-editor.org/rfc/rfc9345.html
2. Cloudflare Docs — Keyless delegation
   https://developers.cloudflare.com/ssl/keyless-ssl/reference/keyless-delegation/
3. Cloudflare Blog — Delegated Credentials for TLS
   https://blog.cloudflare.com/keyless-delegation/
4. Mozilla Security Blog — Validating Delegated Credentials for TLS in Firefox
   https://blog.mozilla.org/security/2019/11/01/validating-delegated-credentials-for-tls-in-firefox/
5. Meta Engineering — Delegated credentials: Improving the security of TLS certificates
   https://engineering.fb.com/2019/11/01/security/delegated-credentials/