Summary
FCI.DelegatedCredentialsadvertises a downstream CDN’s credential ceiling and optional encryption key;MI.DelegatedCredentialscarries credentials and optionally their matching private keys.- Retrieval of the metadata object proves a bounded handoff, not endpoint installation, key usability, fleet convergence, routing selection or an RFC 9345 handshake.
- A defensible operating record must join issuance, key provenance, metadata version, per-edge state, client offer, selected algorithm, handshake evidence, fallback and content outcome without collapsing them into one green status.
The parcel arrived at the building
Picture an upstream CDN sending a sealed case to a downstream operator. The courier receipt says the case crossed the front desk. It does not say the contents were opened, matched, distributed to every intended server, activated before expiry or selected when a customer arrived. RFC 9677 standardizes the case and the front-desk exchange. It does not pretend to be the building’s inventory system.
That distinction is the Article’s centre. Modern TLS delegation is attractive because a certificate owner can authorize short-lived keys without copying the certificate’s long-term private key into every edge environment. CDNI then needs a way for one CDN to pass those bounded credentials to another. The specification provides it. Yet the moment a dashboard labels successful metadata retrieval as “deployed”, a precise protocol becomes an imprecise operational claim.
The missing proof is not a flaw that invalidates the RFC. It is an interface boundary that operators must preserve. Handoff, installation and use occur in different systems, under different clocks, with different failure modes. Good leadership does not ask one receipt to answer all three.
Two objects, two limited claims
The downstream CDN first advertises support. Through FCI.Metadata, it can say that it understands MI.DelegatedCredentials. Through FCI.DelegatedCredentials, it can announce a maximum number of delegated credentials and may publish a PrivateKeyEncryptionKey in JWK form. That information helps the upstream CDN size and protect the material it supplies.
The number is a ceiling, not a fleet census. RFC 9677 says it typically, but not necessarily, corresponds to the number of servers designated for delegated credentials. One credential may be copied to many endpoints; different endpoints may receive different credentials. The topology is a downstream choice. A value of ten therefore does not prove ten servers exist, ten slots are free, or ten credentials are active.
The metadata object carries an array. Each delegated credential is represented as a base64-encoded TLS CertificateEntry containing the RFC 9345 extension. The matching private key is optional. If present, it travels in compact JWE form encrypted to the downstream CDN’s advertised key. If absent, the downstream may have generated the key pair and supplied the public component out of band.
These alternatives create different custody stories. In one, the upstream generated or possessed the private key and encrypted it for transport. In the other, the private key never needed to leave the downstream domain. A single “credential delivered” flag erases which risk was actually taken.
Encryption protects transit, not the whole lifecycle
RFC 9677 does not recommend sending private keys through the metadata interface. When operators do so, the JWE recipient key must be at least as strong as the key it protects. The envelope offers confidentiality for the exchange, but the specification is explicit that it does not provide forward secrecy. Future compromise of the downstream encryption key can expose captured JWEs.
Short lifetime limits the usable period of a stolen delegated credential. It does not turn archival ciphertext into harmless data, establish deletion, prove that the recipient key was current, or show that the decrypted key entered an approved hardware boundary. Custody evidence should retain the JWE algorithms, recipient-key identifier, issuance and retrieval times, credential fingerprint, private-key origin and the component that performed decryption. Secrets themselves must not be logged.
The symmetric lesson is equally important: a delegated credential without the matching private key cannot terminate the delegated handshake. A perfectly parsed metadata object may still be unusable because the key was omitted without an out-of-band pair, encrypted to a stale key, rejected by policy or lost before installation.
RFC 9345 decides whether the client can use it
The CDNI handoff does not relax the TLS rules. A client willing to accept a delegated credential must advertise the extension and compatible signature schemes. The server must not send the credential when the client did not advertise support. The client still validates the certificate chain and service identity, verifies the delegation signature, checks the credential’s validity and algorithm, and uses the delegated public key to verify CertificateVerify.
By default, a delegated credential cannot remain valid for more than seven days and cannot outlive the delegation certificate. It is also bound to a particular handshake signature scheme. A credential can therefore be correctly transported yet wrong for the client’s offer, expired at the observed edge, attached to a certificate without the required authorization or rejected because the selected algorithm differs.
The server may choose not to send a delegated credential even when the client offered support. Operators may retain an ordinary certificate or remote-signing route for legacy clients and for fallback. A successful TLS session consequently proves service reachability under the observed path. It does not, without transcript-level evidence, prove delegated-credential use.
The standard call flow contains a deliberate gap
RFC 9677’s example is honest. The downstream advertises capability. It acquires MI.DelegatedCredentials. Later, a user agent establishes TLS with a downstream endpoint. Later again, the upstream supplies replacements before expiry. No normative message between acquisition and handshake certifies that every target edge installed the exact object.
That space may contain validation, decryption, secret-store import, configuration generation, canary rollout, cache propagation, process reload, health gating and request-routing convergence. Each step can partially succeed. A control plane may report completion after queuing work. A node may acknowledge storage but continue serving an older credential. An edge may be current but receive no traffic. Another may be stale but hidden by a healthy aggregate.
Fleet evidence must therefore name the denominator. “Ninety-nine per cent installed” is useful only if the operator records the intended endpoint set, exclusions, drains, last-seen time, credential fingerprint and activation state. An average cannot authorize global completion when one still-routed edge carries the only expired credential.
Expiry turns bookkeeping into availability
The capability object does not solve renewal. RFC 9677 assigns the upstream CDN responsibility to monitor supplied credentials and refresh them in time. If renewal fails, a downstream server possessing only expired delegated credentials must refuse new TLS connections that require a current credential.
That refusal is a strong local signal. It is not a map of the rest of the fleet. Other edges may have the successor, remain on the predecessor within an overlap window, fall back to the certificate path, be drained, or be unreachable. An incident view should preserve those states rather than summarizing them as “certificate problem”.
Short-lived material changes the operational incentive. It reduces the compromise window but increases the number of rotations and the frequency with which latent rollout defects can become outages. The relevant service-level objective is not merely “credential issued before expiry”. It is “successor usable on the intended routed set before the predecessor loses its permitted role, with a verified fallback for clients and endpoints that cannot use it”.
A ten-step receipt ladder
The evidence chain begins with the delegation certificate. Record the certificate fingerprint, authorized identity, delegation-use extension and validity. Then record the delegated credential’s fingerprint, public key, algorithm, issue and expiry bounds. Next, record whether its private key originated downstream or crossed CDNI inside JWE.
Capability evidence comes fourth: exact FCI version, footprint, announced ceiling and encryption-key identifier. Metadata acquisition comes fifth: object version, source, retrieval time, integrity result and the array entries accepted or rejected. Per-endpoint validation and installation come sixth. Fleet convergence with explicit stale, failed, drained and fallback nodes comes seventh.
Request routing supplies the eighth receipt: which hostname, client region and routing decision reached which edge. The ninth is the actual handshake, including client offer, negotiated protocol, selected signature scheme, certificate chain, delegated extension and verification result. The tenth is the HTTP and application outcome.
Each layer can cite the preceding one. None should overwrite it. The upstream’s metadata log must not be rewritten into an endpoint event, and the endpoint event must not be rewritten into customer delivery.
Build failure semantics before the first rotation
If capability is absent, use an explicitly supported path rather than assuming hidden support. If the announced ceiling is below demand, reduce the set or redesign the topology; do not treat the ceiling as reserved capacity. If the matching key is missing or JWE decryption fails, quarantine the credential. Repeated ambiguous retries risk spreading an unknown custody state.
For a mixed fleet, retain a verified fallback or drain stale endpoints. Canaries should test clients with and without RFC 9345 support, compatible and incompatible signature schemes, fresh and near-expiry credentials, and routing to every rollout cohort. A successful fallback must be labelled as fallback, not counted as delegated-credential deployment success.
When a client rejects the credential, preserve the endpoint, time, alert, client offer and credential fingerprint. When recipient-key compromise is suspected, rotate the encryption key and affected credentials and assess captured JWE exposure. The seven-day limit is a boundary on credential use, not a substitute for incident response.
The useful object remains usefully narrow
RFC 9677 does not issue certificates, revoke delegated credentials, choose request routes, attest endpoint rollout, verify host identity on behalf of the client, or prove delivery. Its value lies in doing less: it gives cooperating CDNs interoperable payloads for a difficult credential exchange.
The discipline from Heng Lu’s reality-layer and running-code notes applies cleanly. A configuration object is evidence of configured intent. Running endpoints and observed handshakes are evidence of execution. The standard coordinates action; it cannot create a fact the execution layer has not emitted.
That is not scepticism about standards. It is the respect standards deserve. Keep the CDNI receipt exactly as strong as it is, then build the operational ledger that connects it to the edge.
Sources
- https://datatracker.ietf.org/doc/rfc9677/history/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://www.iana.org/assignments/cdni-parameters/cdni-parameters.xhtml
- https://www.rfc-editor.org/errata/rfc9677
- https://www.rfc-editor.org/info/rfc5280
- https://www.rfc-editor.org/info/rfc7336
- https://www.rfc-editor.org/info/rfc7337
- https://www.rfc-editor.org/info/rfc7516
- https://www.rfc-editor.org/info/rfc7517
- https://www.rfc-editor.org/info/rfc7736
- https://www.rfc-editor.org/info/rfc8006
- https://www.rfc-editor.org/info/rfc8008
- https://www.rfc-editor.org/info/rfc8446
- https://www.rfc-editor.org/info/rfc9110
- https://www.rfc-editor.org/info/rfc9525
- https://www.rfc-editor.org/info/rfc9677
- https://www.rfc-editor.org/rfc/rfc9345.html
- https://www.rfc-editor.org/rfc/rfc9677.html
- https://www.rfc-editor.org/rfc/rfc9677.txt
- https://www.rfc-editor.org/rfc/rfc9677.xml
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
