Content Delivery Network Interconnection (CDNI) Metadata for Delegated Credentials
Extracted elements (23)
Private keys are optionally transmittable via MI rather than mandatory, because the preferred deployment has the dCDN generate its own key pair and provide only the public key out-of-band, limiting exposure. The JWE encryption with PrivateKeyEncryptionKey is specified for cases where the uCDN must supply the private key.
The FCI.DelegationCredentials object was introduced to allow the uCDN to supply the appropriate number of delegated credentials to the dCDN, since different dCDN deployments may have varying numbers of endpoints requiring credentials. The dCDN has flexibility to deploy one credential across multiple servers or unique credentials per server.
If the private-key property is not specified in MI.DelegatedCredentials, it is assumed that the dCDN generated the public-private key pair itself and provided the public key information to the uCDN via an out-of-band mechanism.
When a dCDN has been delegated to by a uCDN, the dCDN presents the 'delegated_credential' (rather than its own certificate) during the TLS handshake per RFC 8446 to the User Agent, and must also possess the corresponding private key so the User Agent can verify the CertificateVerify message signature.
If the delegated credential is not renewed on time by the uCDN, dCDN servers that only have expired delegated credentials MUST refuse any new TLS connection that requires an up-to-date delegated credential.
If the private-key property is used, the transported private key MUST be encrypted using the PrivateKeyEncryptionKey specified in FCI.DelegatedCredentials, and the envelope format MUST use JWE (RFC 7516) base64 compact serialization.
It is NOT RECOMMENDED to send private keys through the MI. Omitting the private key limits the ways an attacker could exploit the delegated credential.
Once the uCDN has provided delegated credentials via the MI, the uCDN SHOULD monitor the provided credentials and their expiry times and SHOULD refresh dCDN credentials via the MI in a timely manner.
The 'delegated-credential' field in a DelegatedCredentialObject MUST contain a DelegatedCredential structure as defined in RFC 9345, using the extension in the CertificateEntry of its end-entity certificate.
The JWE encryption key (PrivateKeyEncryptionKey) MUST have a strength equal to or larger than the private key it is encrypting for transport.
The PrivateKeyEncryptionKey provided by the dCDN MUST be used by the uCDN to encrypt private keys whenever such private keys are transmitted to the dCDN using MI.DelegatedCredentials.
The uCDN MAY decide to provide less than the maximum supported delegated credentials to the dCDN. The dCDN MAY use one single delegated credential deployed on multiple endpoints, or deploy a different delegated credential for each endpoint.
The FCI and MI objects defined in this document do not contain personally identifiable information (PII). However, systematic retrieval of delegated credentials and private keys would allow an attacker to decrypt end-user data intended for the end service, which may include PII.
FCI.DelegatedCredentials object enables a dCDN to advertise the maximum number of delegated credentials it supports, typically corresponding to the number of servers designated to support delegated credentials. It contains a mandatory integer property 'number-delegated-certs-supported' and an optional 'PrivateKeyEncryptionKey' property.
MI.DelegatedCredentials object contains an array of DelegatedCredentialObject entries, each with a mandatory 'delegated-credential' field (Base64-encoded CertificateEntry containing a DelegatedCredential structure per RFC 9345) and an optional 'private-key' field (JWE compact serialization).
IANA registered two new payload types in the 'CDNI Payload Types' registry under the 'Content Delivery Network Interconnection (CDNI) Parameters' registry group: MI.DelegatedCredentials (for the MI object) and FCI.DelegatedCredentials (for the FCI object), both referencing RFC 9677.
Leakage of only the delegated credential without the private key represents a limited security risk, since a delegated credential can only be used by an entity in possession of the associated private key. Delegated credentials are short-lived (max 7-day validity per RFC 9345), further limiting the impact of any single leaked credential-key pair.
Systematic retrieval of consecutive delegated credentials and private keys would allow an attacker to impersonate dCDN nodes. The CDNI MI interfaces defined in RFC 8006 provide integrity, confidentiality, and mutual authentication protections to prevent such systematic retrieval.
Transmitting private keys via JWE does not offer forward secrecy. If the dCDN's PrivateKeyEncryptionKey becomes compromised in the future, all encrypted JWEs transmitted using it will be compromised. The short-lived nature of delegated credentials limits the impact.
The delegated credentials lifecycle proceeds through: (1) uCDN acquires certificate out-of-band; (2) uCDN generates delegated credentials; (3) dCDN advertises MI.DelegatedCredentials capability and max count via FCI; (4) dCDN retrieves MI.DelegatedCredentials from uCDN; (5) TLS handshake with end user using delegated credentials; (6) uCDN refreshes credentials before expiry.
The 'delegated-credential' field is a Base64-encoded (RFC 4648 Section 4) CertificateEntry as defined in RFC 8446 Section 4.4.2, which MUST contain a DelegatedCredential structure per RFC 9345 using the extension in the end-entity certificate's CertificateEntry.
The 'private-key' field uses JSON Web Encryption (JWE) RFC 7516 base64 compact serialization (Section 7.1 of RFC 7516) as its envelope format, with the private key included as JWE Ciphertext. The JWE content-type field MAY signal the media type of the encrypted key.
The PrivateKeyEncryptionKey property in FCI.DelegatedCredentials is a public key in JSON Web Key (JWK) format per RFC 7517, provided by the dCDN for use by the uCDN to encrypt private keys before transmission.