Prompt and context
CDN edge nodes are numerous and exposed, so distributing a long-lived certificate key magnifies compromise impact. Using RFC 9345, design Delegated Credentials (DC): the certificate holder issues a short-lived credential, the edge uses it for TLS authentication, and it cannot issue another DC. Cover handshake validation, expiry, rotation, revocation limits, and fallback.
What the interviewer is testing
The signals are understanding the binding between a DC and an X.509 end-entity certificate, the authority boundary of a short-lived key, TLS extension negotiation, time windows, and compromise impact. Strong answers distinguish reducing exposure time from instant revocation and explain safe fallback for clients without DC support.
Clarifying questions to ask first
Traffic and termination point
Confirm whether TLS terminates at the CDN, a regional gateway, or the origin, whether edges span administrative domains, and whether DTLS or QUIC is involved. The termination point determines issuance and distribution paths.
Client compatibility matrix
Identify browser, mobile, IoT, and internal client versions and whether their TLS stacks can be upgraded. DC requires extension negotiation and new validation, so support cannot be assumed.
Compromise objective
Clarify whether the goal is to limit long-lived key exposure, edge-key lifetime, or both. Check whether compliance requires a separate revocation list or forced withdrawal.
A 30-second answer framework
“The certificate holder issues a short-lived DC, whose signature, usage, and lifetime are validated with the end-entity certificate key. Edges receive only the DC private key and cannot create another DC; clients validate the binding during the TLS extension flow. Use short lifetimes, overlapping rotation, and key isolation, while protecting the long-lived key. Unsupported clients use an explicit ordinary-certificate path; validation failures never silently downgrade. Compromise response relies on short expiry, stopping issuance, and, when necessary, revoking the parent certificate—not on assuming instant DC revocation.”
Deep-dive answer steps
Step 1: Define the issuance relationship
An issuer holding the long-lived private key corresponding to the end-entity certificate creates the DC public key, lifetime, signature algorithm, and TLS/DTLS usage information. The end-entity public key verifies the signature. Edges receive the DC private key and public credential, never the parent private key.
Step 2: Bound authority and usage
The DC private key is limited to the agreed TLS authentication role and cannot issue another DC. Validate DelegationUsage, algorithm compatibility, and protocol context so a TLS-only credential is not treated as a general signing key.
Step 3: Validate during the handshake
The client validates the traditional X.509 chain, then the DC signature, lifetime, parent binding, and handshake context. If extension negotiation fails, use an explicit ordinary-certificate path. Unknown or inconsistent security fields must fail validation rather than be ignored.
Step 4: Design the rotation window
Set overlap for edge clock skew, propagation delay, and maximum handshake duration. Load the new DC before switching while the old one remains valid; stop the old credential only after distribution is confirmed. Time synchronization and monitoring cover the boundary.
Step 5: Handle compromise and revocation
An attacker with a DC private key can impersonate the party in new connections until that DC expires, but cannot issue another DC. Response includes stopping issuance, shortening lifetimes, withdrawing edge credentials, and, if necessary, revoking the parent or switching to an ordinary certificate. DC is not an instant-revocation mechanism.
Step 6: Plan compatibility and fallback
Use a client matrix and staged traffic to verify extension support. Unsupported clients follow the long-lived-certificate termination path while the parent key remains isolated. Distinguish “peer lacks support” from “validation failed”; never downgrade a validation failure to plaintext or an arbitrary certificate.
Step 7: Observe and rehearse
Record issuance, distribution, loading, handshake failures, clock skew, and fallback rates without logging private keys. Rehearse edge compromise, issuer outage, parent revocation, and full fallback to verify recovery within the short lifetime.
High-quality sample answer
I would keep the long-lived certificate key in an issuer and use it to sign short-lived DCs; edges receive only each DC private key. During the handshake, validate the X.509 chain, then the DC binding, usage, algorithm, lifetime, and handshake context. Rotate with overlap, monitor clocks, stage compatibility, and provide an explicit old-client fallback. If a DC leaks, stop issuance, withdraw edge credentials, wait for expiry, and revoke the parent when necessary. Monitor validation failures and fallback rates; DC is not instant revocation.
Common mistakes
- Mistake: Assuming a leaked DC can be revoked instantly like an OAuth token. → Why: The RFC focuses on short lifetime and parent binding. → Improve: Shorten lifetime and prepare parent revocation and withdrawal.
- Mistake: Letting an edge with a DC private key issue more DCs. → Why: This expands the delegation chain and authority. → Improve: Keep the parent key in a controlled issuer.
- Mistake: Ignoring fields when extension support is absent. → Why: Negotiation compatibility is not validation success. → Improve: Separate unsupported, validation failure, and ordinary fallback.
- Mistake: Rotating only by issuance timestamp. → Why: Propagation and clock skew can make edges use a credential too early or too late. → Improve: Use overlap and monitor time synchronization.
Follow-up questions and answers
Follow-up 1: How does a DC differ from an ordinary short-lived X.509 certificate?
A DC is bound to an existing end-entity certificate and used in the TLS handshake, so the edge need not hold the parent private key. An ordinary short-lived certificate usually still requires the CA or certificate system to issue a complete chain. Their deployment and validation boundaries differ.
Follow-up 2: What can an attacker do with a DC private key?
They can impersonate the party in new TLS connections until the DC expires, but cannot use it to issue another DC. The window depends on lifetime, parent state, and detection and response speed.
Follow-up 3: Why is DelegationUsage needed?
It limits which certificates explicitly permit DC participation, reducing cross-protocol risk from feeding a certificate without delegation semantics into DC validation.
Follow-up 4: Do QUIC or DTLS require a separate trust root?
No new trust root is required, but RFC 9345’s protocol context and extension rules must validate usage, handshake fields, and algorithms. TLS parsing cannot be reused for another protocol without that review.