Summary

  • RFC 9345 lets a certificate owner sign a bounded credential whose private key can complete compatible TLS or DTLS 1.3 handshakes. The relying peer still validates the original certificate and expected identity; the edge receives handshake authority, not ownership of the certificate or the right to mint further credentials.
  • The default maximum is seven days, but short life is a damage window rather than a revocation channel. A stolen delegated private key can impersonate the peer until expiry, and one credential cannot be withdrawn early without the broader act of revoking the signing certificate.
  • Operational proof must join certificate opt-in, credential bytes, signer event, key custody, intended edge set, negotiated client support, CertificateVerify success, fallback behavior, resumption state and post-expiry refusal. A valid handshake alone cannot prove safe distribution or application authorization.

The object that arrived at the edge

Picture a content service whose certificate private key remains behind a controlled signing boundary. At 02:00, that back end signs a new object for an edge cluster. The object contains a public key, an expiry measured from the certificate’s notBefore, and a signature scheme. The edge holds the corresponding private key. A compatible browser connects, advertises extension 34, receives the ordinary certificate chain plus this object, and accepts a CertificateVerify signature made at the edge.

The round trip to the long-term signer has disappeared. So has the need to place the certificate private key on that front end. But the edge has not become the certificate holder. It cannot renew the certificate, change its names, alter the CA’s record, sign an unlimited successor credential or make a legacy client accept the mechanism. It has received a capability to authenticate a bounded class of new handshakes while several other facts agree.

That distinction is the whole design. Calling the object a “short-lived certificate” is convenient and wrong. RFC 9345 deliberately avoids creating another X.509 certificate. A delegated credential carries only the semantics needed for the handshake, and its signature is tied to the complete end-entity certificate, the credential fields, a chosen algorithm and a role-specific context string. It is narrow because the certificate owner is delegating one executable function, not reproducing the CA hierarchy at the edge.

Permission begins in the certificate

The long-term certificate must opt in. It needs the non-critical DelegationUsage extension and the digitalSignature KeyUsage. A relying endpoint must reject a delegated credential when either condition is absent. This prevents temporary access to an ordinary certificate key—or a signing oracle built around an older protocol—from silently becoming authority to manufacture TLS delegated credentials.

For server authentication, the client first advertises the delegated_credential extension and acceptable delegated CertificateVerify algorithms in ClientHello. Only then may the server put one delegated credential in the end-entity CertificateEntry. For client authentication, the server advertises support in CertificateRequest before the client may return one. A credential delivered without the prior signal is not a helpful upgrade; it is an unexpected_message failure.

The verifier does not skip ordinary identity work. It validates the certificate chain and checks the end-entity certificate against the expected peer just as it would without delegation. It then checks time, the default maximum remaining life, the certificate boundary, both signature-algorithm relationships, the opt-in extension and the credential signature made by the certificate key. Only after those checks does the delegated public key replace the certificate public key for verifying CertificateVerify.

The result is a layered authentication statement. The CA chain says which end-entity certificate is acceptable. The certificate signature says that this particular credential may act within its encoded scope. The edge proves possession of the delegated private key in this handshake. The application still decides what an authenticated transport may do. None of those layers can safely impersonate the next one.

Seven days is a ceiling, not an undo button

Without an application profile that says otherwise, a delegated credential may extend no more than seven days from the verifier’s current time and no later than the signing certificate’s expiry. A provider can choose much less. Cloudflare, for example, documents a product lifecycle under which its generated credentials become invalid within 24 hours after Keyless is disabled.

Those statements are compatible because the RFC supplies a default maximum, not a mandatory lifetime for every deployment. They also expose a common reporting error. “Disabled” does not necessarily mean “unable to authenticate now.” RFC 9345 defines no separate early-revocation service for one delegated credential. Normal withdrawal is expiry. Revoking the signing certificate also removes the basis of the delegation, but that wider action can disrupt every non-delegated and delegated use of the same certificate.

If an edge private key leaks at noon and the credential expires at midnight, deletion from the intended edge does not retrieve the attacker’s copy. The defensible statement is that compromise is bounded by the last valid instant, subject to clocks, certificate status and relying behavior. A shorter lifetime narrows that interval but raises the reliability requirement for signing, distribution and time.

Time itself becomes a dependency. Credential expiry is calculated from the certificate’s notBefore, while validation compares the result with the peer’s clock. Skew near the boundary can make a server believe it has deployed a live credential while clients reject it. The safe rotation window therefore includes clock margin, next-credential overlap and measured rejection evidence; it is not the encoded timestamp alone.

Session resumption adds another clock. If a peer caches the certificate chain and revalidates it while resuming, RFC 9345 says it should also cache and revalidate the delegated credential. Otherwise a resumed connection can preserve an authentication decision whose delegated basis has expired. “No new full handshake occurred” is not proof that expiry was respected.

Key custody decides the real blast radius

The protocol object is public. The corresponding delegated private key creates the practical power. An operations ledger must therefore say where the key originated and how it moved.

RFC 9677 makes two inter-CDN patterns explicit. A downstream CDN may generate its key pair and send the public portion out of band for the upstream certificate owner to authorize. In that design, the private key never crosses the metadata interface, but the enrolment path must prove that the public key belongs to the intended downstream endpoint. Alternatively, the upstream can deliver an encrypted private key with the credential. That simplifies centralized generation while creating a transported ciphertext and a protection key whose later compromise may expose recorded deliveries.

The RFC does not recommend sending private keys through the metadata interface. If an operator nevertheless chooses that path, encryption is mandatory, but the specified envelope does not give forward secrecy against later loss of the downstream decryption key. Short credential life limits current impersonation; it does not erase archived ciphertext or prove that copied keys disappeared.

Distribution granularity is also a governance choice. One credential can serve many edge nodes, reducing signing and refresh load. A compromise then reaches every node sharing the key, and a handshake cannot identify which one used it. Per-edge credentials narrow attribution and containment but multiply issuer work, inventory states and expiry hazards. The right unit is the smallest one the signing and delivery systems can rotate reliably—not the smallest one a security diagram can draw.

Compatibility keeps the long-term path alive

Delegated credentials work only in TLS or DTLS 1.3 and only when the initiating peer advertises support. IANA’s recommended registration makes the extension stable; it does not install support in clients or persuade CAs to issue certificates with DelegationUsage.

Cloudflare’s current documentation says very few clients and only a handful of CAs support the mechanism, while identifying Firefox 77 and later as a supporting browser. That is enough to establish a real deployment path and not enough to claim ubiquity. A mixed fleet needs an ordinary certificate-key or remote-signing path for clients that do not offer extension 34 or do not accept the available algorithms.

The fallback is not free. Remote signing adds a per-handshake dependency and latency. Placing the certificate key at more edges enlarges long-term exposure. Serving a separate certificate without the delegation extension changes inventory and renewal. A dashboard that celebrates rising delegated handshakes while hiding fallback load can miss the failure of the very signing service the design was meant to reduce.

Running code reveals further boundaries. BoringSSL’s tests distinguish the algorithm used to sign the delegated credential from the one used by its key for CertificateVerify, refuse the mechanism in TLS 1.2 and exercise selection of an ordinary certificate when no suitable delegated credential matches. Mozilla NSS selects the delegated private key for signing and the delegated public key for verification, then checks that the CertificateVerify scheme matches the credential expectation. The registry entry is one fact; those executed branches are the acceptance surface.

The evidence ledger for one credential epoch

A useful record begins before the edge sees the key. It includes the end-entity certificate fingerprint, serial, validity, names, KeyUsage and DelegationUsage; the delegated credential byte hash, public-key hash, role, algorithms and calculated expiry; the signer identity and certificate-key audit event; and the authorization that names the intended delegate.

The custody record states whether the delegate generated the key or received it, the authenticated enrolment or encrypted delivery path, the intended edge set and each deployment acknowledgement. The handshake record states client support, the credential selected, certificate and DC validation outcomes, CertificateVerify success, TLS or DTLS version and whether ordinary certificate fallback occurred.

Retirement has its own evidence. Record the stop on future issuance, removal acknowledgements, expected last-valid instant, certificate-revocation decision, resumption treatment and a negative test after expiry. An edge configuration that no longer lists the credential proves a local change. It does not prove that every copy ceased to authenticate.

Sources