Summary

  • A valid delegated credential proves a bounded authority to authenticate a compatible TLS or DTLS 1.3 connection under a parent certificate.
  • It does not prove domain control, CA issuance authority, organisational identity or a separately revocable delegation.

Imagine a hypothetical assurance dashboard watching a CDN edge. The edge presents a valid delegated credential, completes a TLS 1.3 handshake and is then classified as a new controller of the domain. The first observation is useful. The classification is not.

RFC 9345 defines a narrower mechanism. A certificate holder can sign a delegated credential containing a public key, a signature algorithm and a short validity interval. A supporting front end can use the delegated private key to complete TLS connections without receiving the long-term private key of the parent certificate. The signature binds the credential to the complete end-entity certificate and to a client- or server-authentication context.

The parent certificate does not disappear. The peer still validates its chain and matches it to the expected identity. It also checks that the certificate permits delegated credentials, that the algorithms fit the negotiation, that the credential signature is valid and that the time limit is acceptable. Without a different application profile, the maximum remaining lifetime is seven days, and the credential cannot outlive the parent certificate.

These checks explain both the value and the boundary. The delegated key can authenticate TLS connections on behalf of the certificate holder. It cannot issue another public certificate, alter DNS, prove a corporate relationship or establish who legally controls the name. A valid handshake is evidence of possession of the delegated private key within the protocol's scope—not a general title deed.

The revocation boundary is equally important. RFC 9345 adds no independent early-revocation channel for the delegated credential. Expiry ends it, while revocation of the parent end-entity certificate invalidates it implicitly. Compromise or retirement of the long-term private key used to sign delegated credentials is therefore a reason to revoke the parent certificate; the key event alone is not a separate protocol revocation signal. If the delegated private key is stolen, it can support impersonation in new connections until expiry or parent-certificate revocation. Short life reduces exposure; it does not make custody irrelevant.

Session resumption can also preserve a decision after operators think the credential has disappeared. A resumed TLS 1.3 handshake does not retransmit the certificate or delegated credential. Where an implementation or acceptance policy chooses to cache and revalidate the original certificate chain on resumption, it should associate and revalidate the original delegated credential too. That is a conditional assurance treatment, not a universal TLS validation step.

The acceptance object should therefore be a delegated-termination receipt: parent-certificate fingerprint and validity; DelegationUsage; delegated public-key fingerprint; issuer; client or server role; algorithms; validity interval; distribution target; custody owner; negotiated TLS version; observed handshake; resumption treatment; parent revocation state; retirement result; and evidence time.

The purpose is not to weaken the credential. It is to keep its authority exact. An edge may be fully authorised to terminate one class of TLS connection while possessing none of the broader powers that an inventory, compliance system or contract database might accidentally assign to it.

Sources