RFC 9677 PROPOSED STANDARD CDN · TLS · CREDENTIALS
CDNI Delegated Creds: Content Delivery Network Interconnection (CDNI) Metadata for Delegated Credentials
How an upstream CDN hands short-lived TLS credentials to a downstream CDN so it can serve HTTPS on its behalf.
RFC EDITOR
Fieau, F., Stephan, E., Bichot, G., and C. Neumann, "Content Delivery Network Interconnection (CDNI) Metadata for Delegated Credentials", RFC 9677, DOI 10.17487/RFC9677, October 2024, <https://www.rfc-editor.org/info/rfc9677>.
BIBTEX
@misc{rfc9677,
series = {Request for Comments},
number = 9677,
howpublished = {RFC 9677},
publisher = {RFC Editor},
doi = {10.17487/RFC9677},
url = {https://www.rfc-editor.org/info/rfc9677},
author = {F. Fieau and E. Stephan and G. Bichot and C. Neumann},
title = {{Content Delivery Network Interconnection (CDNI) Metadata for Delegated Credentials}},
pagetotal = 11,
year = 2024,
month = oct,
} RFC text
Contents
Internet Engineering Task Force (IETF) F. Fieau
Request for Comments: 9677 E. Stephan
Category: Standards Track Orange
ISSN: 2070-1721 G. Bichot
C. Neumann
Broadpeak
October 2024
Content Delivery Network Interconnection (CDNI) Metadata for Delegated
Credentials
Abstract
The delivery of content over HTTPS involving multiple Content
Delivery Networks (CDNs) raises credential management issues. This
document defines metadata in the Content Delivery Network
Interconnection (CDNI) Control and Metadata interface to set up HTTPS
delegation using delegated credentials from an upstream CDN (uCDN) to
a downstream CDN (dCDN).
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9677.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents
1. Introduction
2. Terminology
3. CDNI Footprint and Capabilities Advertisement Interface (FCI)
Capabilities Object for Delegated Credentials
3.1. FCI.DelegatedCredentials
3.2. Expected Usage of the Property Number of Supported
Delegated Credentials
4. CDNI Metadata Interface (MI) Metadata Object for Delegated
Credentials
5. Delegated Credentials Call Flow
6. IANA Considerations
6.1. CDNI MI.DelegatedCredentials Payload Type
6.2. CDNI FCI.DelegatedCredentials Payload Type
7. Security Considerations
8. Privacy Considerations
9. References
9.1. Normative References
9.2. Informative References
Authors' Addresses
1. Introduction
Content delivery over HTTPS utilizing one or more Content Delivery
Networks (CDNs) along the delivery path necessitates the management
of credentials. This requirement is particularly pertinent when an
entity delegates the delivery of content via HTTPS to another trusted
entity.
This document specifies the CDNI Metadata interface for establishing
HTTPS delegation through the use of delegated credentials, as defined
in [RFC9345], between an upstream CDN (uCDN) and a downstream CDN
(dCDN).
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document uses terminology from the CDNI specifications -- CDNI
framework [RFC7336], CDNI requirements [RFC7337], and CDNI Metadata
interface [RFC8006].
3. CDNI Footprint and Capabilities Advertisement Interface (FCI)
Capabilities Object for Delegated Credentials
A dCDN should advertise its supported delegation methods using the
Footprint and Capabilities Advertisement interface (FCI) as defined
in [RFC8008]. The FCI.Metadata object enables a dCDN to communicate
its capabilities and the Metadata interface (MI) objects it supports.
To indicate support for delegated credentials, the dCDN should
announce the support for MI.DelegatedCredentials, as illustrated in
the example below.
{
"capabilities": [
{
"capability-type": "FCI.Metadata",
"capability-value": {
"metadata": [
"MI.DelegatedCredentials",
"... other supported MI objects ..."
]
},
"footprints": [
"Footprint objects"
]
}
]
}
This document also defines an object that informs the uCDN of the
number of delegated credentials supported by the dCDN, enabling the
uCDN to supply the appropriate number of delegated credentials. To
this end, the FCI object, FCI.DelegationCredentials, is introduced.
3.1. FCI.DelegatedCredentials
The FCI.DelegationCredentials object enables advertising the maximum
number of delegated credentials supported by the dCDN. This number
typically (but not necessarily) corresponds to the number of servers
designated by the dCDN to support delegated credentials.
The property PrivateKeyEncryptionKey contains a public key provided
by the dCDN that MUST be used by the uCDN to encrypt private keys
whenever such private keys are transmitted to the dCDN using
MI.DelegatedCredentials (see Section 4).
Property: number-delegated-certs-supported
Description: Number of delegated credentials supported by the dCDN.
Type: integer
Mandatory-to-Specify: Yes
Property: PrivateKeyEncryptionKey
Description: Public key in JSON Web Key (JWK) format [RFC7517] of
the dCDN to be used by the uCDN to encrypt private keys.
Type: string
Mandatory-to-Specify: No
The following is an example of the FCI.DelegatedCredentials.
{
"capabilities": [
{
"capability-type": "FCI.DelegatedCredentials",
"capability-value": {
"number-delegated-certs-supported": 10
}
"footprints": [
<Footprint objects>
]
}
]
}
3.2. Expected Usage of the Property Number of Supported Delegated
Credentials
The dCDN uses the FCI.DelegatedCredentials object to announce the
number of servers that support delegated credentials.
When the uCDN receives the FCI.DelegatedCredentials object, it can
issue the supported number of delegated credentials to the dCDN.
When configuring the dCDN, the uCDN MAY decide to provide less than
the maximum supported delegated credentials to the dCDN. Note that,
within a dCDN, different deployment possibilities of the delegated
credentials on the endpoints exist. The dCDN MAY use one single
delegated credential and deploy it on multiple endpoints.
Alternatively, the dCDN MAY deploy a different delegated credential
for each endpoint (provided that the uCDN delivers enough different
delegated credentials). This choice is at the discretion of the dCDN
and depends on the number of delegated credentials provided by the
uCDN.
The FCI.DelegationCredentials object does not address expiry or
renewal of delegated credentials. 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 uCDN may decide not
to monitor the validity period of delegated credentials and not to
refresh the credentials, for example, in cases of short-term one-shot
deployments or once it has decided to deprovision a dCDN. If the
delegated credential is not renewed on time by the uCDN, the servers
of the dCDN that only have expired delegated credentials MUST refuse
any new TLS connection that requires an up-to-date delegated
credential.
4. CDNI Metadata Interface (MI) Metadata Object for Delegated
Credentials
As expressed in [RFC9345], when an uCDN has delegated to a dCDN, the
dCDN presents the "delegated_credential" (rather than its own
certificate) during the TLS handshake [RFC8446] to the User Agent.
This implies that the dCDN is also in the possession of the private
key corresponding to the public key in DelegatedCredential.cred
[RFC9345]. This allows the User Agent to verify the signature in a
CertificateVerify message (Section 4.4.3 of [RFC8446]) sent and
signed by the dCDN.
This section defines the MI.DelegatedCredentials object containing an
array of delegated credentials and optionally the corresponding
private keys. The CDNI MI [RFC8006] describes the CDNI metadata
distribution mechanisms according to which a dCDN can retrieve the
MI.DelegatedCredentials object from the uCDN.
The properties of the MI.DelegatedCredentials object are as follows:
Property: delegated-credentials
Description: Array of delegated credentials
Type: Array of DelegatedCredentialObject objects
Mandatory-to-Specify: Yes
The DelegatedCredentialObject object is composed of the following
properties:
Property: delegated-credential
Description: Base64-encoded (as defined in Section 4 of [RFC4648])
version of a CertificateEntry as defined in Section 4.4.2 of
[RFC8446]. The CertificateEntry MUST contain a
DelegatedCredential structure (as defined in [RFC9345]) using the
extension in the CertificateEntry of its end-entity certificate
(see Section 4.1.1 of [RFC9345]).
Type: string
Mandatory-to-Specify: Yes
Property: private-key
Description: Encrypted private key corresponding to the public key
contained in the DelegatedCredential. The envelope format for
this property is JSON Web Encryption (JWE) [RFC7516] using the
base64 compact serialization (Section 7.1 of [RFC7516]).
Type: string
Mandatory-to-Specify: No
The private-key property is not mandatory. If not specified, it is
assumed that the dCDN generated the public-private key pair for the
delegated credential itself and provided the public key information
with an out-of-band mechanism to the uCDN. See Section 7 for
constraints regarding the usage of the private key.
If the private-key property is used, the transported private key MUST
be encrypted using the PrivateKeyEncryptionKey specified in
FCI.DelegatedCredentials. The envelope format for this property MUST
use JWE [RFC7516] using the base64 compact serialization (Section 7.1
of [RFC7516]), whereas the private key is included as JWE Ciphertext
in the JWE. The JWE content-type field MAY be used to signal the
media type of the encrypted key.
Below, please see an example of an MI.DelegatedCredentials object.
{
"generic-metadata-type": "MI.DelegatedCredentials",
"generic-metadata-value": {
"delegated-credentials": [
{"delegated-credential":
"cBBfm8KK6pPz/tdgKyedwA...
iXCCIAmzMM0R8FLI3Ba0UQ=="},
{"delegated-credential":
"4pyIGtjFdys1+9y/4sS/Fg...
J+h9lnRY/xgmi65RLGKoRw=="},
{"delegated-credential":
"6PWFO0g2AXvUaULXLObcVA...
HXoldT/qaYCCNEyCc8JM2A=="}
]
}
}
5. Delegated Credentials Call Flow
An example call-flow using delegated credentials is depicted in
Figure 1. The steps are as follows.
1. It is assumed that the uCDN has been provisioned and configured
with a certificate. Note that it is out of scope of CDNI and the
present document how and from where (e.g., which Content Service
Provider) the uCDN acquired its certificate.
2. The uCDN generates a set of delegated credentials (here it is
assumed that public keys of the dCDN are known). Note that the
uCDN may generate this material at different points in time,
e.g., in advance to have a pool of delegated credentials or on
demand when the dCDN announces its maximum number of supported
delegated credentials.
3. Using the CDNI FCI [RFC8008], the dCDN advertises
MI.DelegatedCredentials capabilities to the uCDN. The dCDN
further uses FCI.DelegatedCredentials to advertise the maximum
number of supported delegated credentials.
4. Using the CDNI MI [RFC8006], the dCDN acquires the
MI.DelegatedCredentials, retrieving an array of delegated
credentials.
5. The client establishes a TLS connection with an endpoint of the
dCDN according to [RFC9345] using the delegated credentials
retrieved in step 4.
6. When some delegated credentials are about to expire, the uCDN
uses the CDNI MI [RFC8006] to provide new, valid delegated
credentials.
User-Agent dCDN uCDN
| | |
| | [1. uCDN acquires its certificate
| | out of scope of CDNI]
| | |
| | [2. generation of
| | delegated credentials]
| | |
| 3. CDNI FCI used to
| advertise support of MI.DelegatedCredentials
| and announce number of delegated credentials
| supported using FCI.DelegatedCredentials
| |-------------------->+
| | |
| 4. CDNI MI used to
| provide the MI.DelegatedCredentials object
| |<--------------------+
| | |
.
.
.
[5. TLS handshake according |
to [RFC9345]] . |
|<------------------->| |
| | |
.
.
.
| 6. Some delegated credentials about to expire.
| CDNI MI used to
| provide new MI.DelegatedCredentials object
| |<--------------------+
| | |
Figure 1: Example Call Flow of Delegated Credentials in CDNI
6. IANA Considerations
IANA has registered the following payload types in the "CDNI Payload
Types" registry in the "Content Delivery Network Interconnection
(CDNI) Parameters" registry group.
+==========================+===========+
| Payload Type | Reference |
+==========================+===========+
| MI.DelegatedCredentials | RFC 9677 |
+--------------------------+-----------+
| FCI.DelegatedCredentials | RFC 9677 |
+--------------------------+-----------+
Table 1
Sections 6.1 and 6.2 provide additional necessary information for the
registration of those CDNI payload types (see Section 2.2 of
[RFC7736]).
6.1. CDNI MI.DelegatedCredentials Payload Type
Purpose: The purpose of this payload type is to distinguish
delegated credentials MI objects.
Interface: MI/FCI
Encoding: See Section 4.
6.2. CDNI FCI.DelegatedCredentials Payload Type
Purpose: The purpose of this payload type is to advertise the number
of delegated credentials needed (and any associated capability
advertisement).
Interface: FCI
Encoding: See Section 3.1.
7. Security Considerations
The extensions defined enable providing delegated credentials to
dCDNs. A delegated credential can only be used by a dCDN if it is in
possession of the associated private key. Similarly, an attacker
requires access to the private key in order to exploit a delegated
credential and impersonate dCDN nodes. Thus, leakage of only the
delegated credential without the private key represents a limited
security risk.
Delegated credentials and associated private keys are short-lived
(per default, the maximum validity period is set to 7 days in
[RFC9345]) and as such a single leaked delegated credential with its
private key represents a limited security risk. Still, it is NOT
RECOMMENDED to send private keys through the MI. Omitting the
private key further limits the possible ways an attacker could
exploits the delegated credential.
If this recommendation is not followed, i.e., the private key is
communicated via the MI, the transported private key MUST be
encrypted within a JWE envelope using the encryption key
(PrivateKeyEncryptionKey) provided within the
FCI.DelegatedCredentials by the dCDN. The JWE encryption key
(PrivateKeyEncryptionKey) MUST have a strength equal to or larger
than the private key it is encrypting for transport. Note that the
specified encryption method does not offer forward secrecy. If the
dCDN's encryption key becomes compromised in the future, then all
encrypted JWEs will become compromised. Due to the short-lived
nature of delegated credentials, the impact is limited.
It is also important to ensure that an attacker is not able to
systematically retrieve a consecutive or consistent set of delegated
credentials and associated private keys. Such an attack would allow
the attacker to systematically impersonate dCDN nodes. The MI
objects defined in the present document are transferred via the
interfaces defined in CDNI [RFC8006]. [RFC8006] describes how to
secure these interfaces, protecting the integrity and
confidentiality, as well as ensuring the authenticity of the dCDN and
uCDN, which should prevent an attacker from systematically retrieving
delegated credentials and associated private keys.
8. Privacy Considerations
The FCI and MI objects and the information defined in the present
document do not contain any personally identifiable information
(PII). As such, this document does not change or alter the
confidentiality and privacy considerations outlined in Section 8.2 of
[RFC8006] and Section 7 of [RFC8008].
A single or systematic retrieval of delegated credentials and
associated private keys would allow the attacker to decrypt any data
sent by the end user intended for the end service, which may include
PII.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, DOI 10.17487/RFC7516, May 2015,
<https://www.rfc-editor.org/info/rfc7516>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/info/rfc7517>.
[RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
"Content Delivery Network Interconnection (CDNI)
Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016,
<https://www.rfc-editor.org/info/rfc8006>.
[RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg,
R., and K. Ma, "Content Delivery Network Interconnection
(CDNI) Request Routing: Footprint and Capabilities
Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016,
<https://www.rfc-editor.org/info/rfc8008>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC9345] Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla,
"Delegated Credentials for TLS and DTLS", RFC 9345,
DOI 10.17487/RFC9345, July 2023,
<https://www.rfc-editor.org/info/rfc9345>.
9.2. Informative References
[RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed.,
"Framework for Content Distribution Network
Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336,
August 2014, <https://www.rfc-editor.org/info/rfc7336>.
[RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution
Network Interconnection (CDNI) Requirements", RFC 7337,
DOI 10.17487/RFC7337, August 2014,
<https://www.rfc-editor.org/info/rfc7337>.
[RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI)
Media Type Registration", RFC 7736, DOI 10.17487/RFC7736,
December 2015, <https://www.rfc-editor.org/info/rfc7736>.
Authors' Addresses
Frédéric Fieau
Orange
40-48, avenue de la République
92320 Châtillon
France
Email: frederic.fieau@orange.com
Emile Stephan
Orange
2, avenue Pierre Marzin
22300 Lannion
France
Email: emile.stephan@orange.com
Guillaume Bichot
Broadpeak
3771 Boulevard des Alliés
35510 Cesson-Sévigné
France
Email: guillaume.bichot@broadpeak.tv
Christoph Neumann
Broadpeak
3771 Boulevard des Alliés
35510 Cesson-Sévigné
France
Email: christoph.neumann@broadpeak.tv
AI ELI5
On this page
PROBLEMWhen content is delivered over HTTPS through more than one content delivery network, the downstream CDN needs a way to prove its identity to browsers without holding the upstream CDN's own certificate.
MECHANISMThe RFC defines two CDNI objects: FCI.DelegatedCredentials, where the downstream CDN says how many credentials it can use, and MI.DelegatedCredentials, which carries the delegated credentials (and optionally encrypted private keys) from the upstream CDN.
WHY IT MATTERSA downstream CDN can present a delegated credential in the TLS handshake as defined in RFC 9345. The RFC advises against sending private keys through the metadata interface at all.
§1Delegating HTTPS Across CDNs
Delivering content over HTTPS through one or more Content Delivery Networks (CDNs) means somebody has to manage credentials. The problem is sharpest when one entity hands HTTPS delivery to another trusted entity.
RFC 9677 specifies the CDNI Metadata interface for setting up that handoff using delegated credentials as defined in RFC 9345. The two parties are the upstream CDN (uCDN), which holds the certificate, and the downstream CDN (dCDN), which serves the content. It builds on the CDNI framework, requirements and metadata documents (RFC 7336, RFC 7337, RFC 8006).
One company owns the shop's ID, but another company is doing the actual deliveries. This document is about lending the second company a temporary pass so it can say it is working for the first.
§2How a Delegated Credential Is Used
Under RFC 9345, when a uCDN has delegated to a dCDN, the dCDN presents a delegated_credential instead of its own certificate during the TLS handshake with the User Agent. The dCDN therefore also needs the private key matching the public key inside the delegated credential. With it, the dCDN signs the CertificateVerify message, and the User Agent can check that signature.
RFC 9677 does not change any of that. It only defines how the credentials get from the uCDN to the dCDN using CDNI interfaces: the Footprint and Capabilities Advertisement interface (FCI) and the Metadata interface (MI).
The visitor checks the temporary pass, and the second company proves the pass really is theirs by using a secret only they hold. This document just explains how the pass gets to them.
§3Advertising Capabilities with the FCI
A dCDN should announce what it supports through the FCI defined in RFC 8008. Inside an FCI.Metadata capability it lists MI.DelegatedCredentials among the MI objects it understands.
This RFC also defines a new object, FCI.DelegatedCredentials, with two properties:
number-delegated-certs-supported: an integer, mandatory, giving the maximum number of delegated credentials the dCDN supports. It typically, but not necessarily, matches the number of servers the dCDN designates for delegated credentials.PrivateKeyEncryptionKey: an optional string holding the dCDN's public key in JSON Web Key (JWK) format, which the uCDN MUST use to encrypt any private key it sends.
The uCDN may issue fewer than the maximum. The dCDN may use a single credential on many endpoints, or a different one per endpoint if it was given enough. That choice is the dCDN's.
The FCI object does not cover expiry or renewal. The uCDN SHOULD monitor expiry times and SHOULD refresh credentials through the MI in good time. If a dCDN server holds only expired credentials, it MUST refuse any new TLS connection that needs an up-to-date delegated credential.
The second company tells the first how many passes it can use, and (if it wants) gives a special lock so the first can send secrets safely. If a pass runs out and is not replaced, the second company must turn visitors away.
§4The MI.DelegatedCredentials Object
The MI.DelegatedCredentials object carries an array called delegated-credentials (mandatory). Each entry is a DelegatedCredentialObject with two properties:
delegated-credential(mandatory): a Base64-encodedCertificateEntryfrom RFC 8446 that MUST contain aDelegatedCredentialstructure, using the extension in the end-entity certificate's entry.private-key(optional): the private key matching the credential's public key, encrypted as a JSON Web Encryption (JWE) object in compact serialization, with the key as the JWE Ciphertext. The JWE content-type field MAY signal the media type of the encrypted key.
If private-key is left out, the dCDN is assumed to have generated the key pair itself and passed the public key to the uCDN by some out-of-band means. If it is included, it MUST be encrypted with the PrivateKeyEncryptionKey from the FCI. The dCDN retrieves the object from the uCDN using the CDNI metadata distribution mechanisms of RFC 8006.
The package holds a list of passes. Each pass can come with its secret key, but only locked in a box that only the second company can open. Often the second company makes its own key and just sends the matching public half.
§5The Call Flow
The RFC walks through six steps:
- The uCDN is provisioned with a certificate. How it got one is out of scope.
- The uCDN generates a set of delegated credentials, either in advance as a pool or on demand when the dCDN announces its maximum.
- The dCDN uses the FCI to advertise
MI.DelegatedCredentialssupport and the maximum number of credentials. - The dCDN uses the MI to fetch the
MI.DelegatedCredentialsarray. - A client opens a TLS connection to a dCDN endpoint per RFC 9345, using those credentials.
- When credentials are about to expire, the uCDN sends new ones through the MI.
The first company prepares passes, the second says how many it needs and picks them up, visitors use them, and the first company hands over fresh ones before the old ones run out.
User AgentdCDNuCDN
- FCI: MI.DelegatedCredentials and max countStep 3: advertise support and the number of credentials.
- MI: MI.DelegatedCredentialsStep 4: the array of delegated credentials.
- TLS handshake (RFC 9345)Step 5: the dCDN presents a delegated credential.
- MI: new credentialsStep 6: sent when current ones are about to expire.
§6IANA Registrations
IANA has registered two payload types in the CDNI Payload Types registry: MI.DelegatedCredentials (interface MI/FCI) and FCI.DelegatedCredentials (interface FCI). The first distinguishes delegated credentials MI objects. The second advertises the number of delegated credentials needed, along with any associated capability advertisement.
The two new kinds of message get official names in a public list so everybody uses the same ones.
§7Security and Privacy
A delegated credential is only useful with its private key, so leaking the credential alone is a limited risk. Credentials are short-lived: RFC 9345 sets a default maximum validity of 7 days. Even so, the RFC says it is NOT RECOMMENDED to send private keys through the MI at all.
If keys are sent, they MUST be JWE-encrypted with the dCDN's PrivateKeyEncryptionKey, which MUST be at least as strong as the key it protects. This method does not offer forward secrecy: if the encryption key is later compromised, all the JWEs sent with it are too, though short lifetimes limit the damage. An attacker who could systematically collect credentials and keys could impersonate dCDN nodes, so the CDNI interfaces must be secured as RFC 8006 describes.
The objects contain no personally identifiable information, but leaked credentials and keys would let an attacker decrypt end-user data sent to the service.
A pass is useless without its secret key, and passes expire quickly. Still, the safest plan is not to mail the secret key at all, because a thief with both could pretend to be the second company.
§8References
[RFC9345]RFC 9345Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, "Delegated Credentials for TLS and DTLS", RFC 9345, July 2023.July 2023[RFC8006]RFC 8006Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, "Content Delivery Network Interconnection (CDNI) Metadata", RFC 8006, December 2016.December 2016[RFC8008]RFC 8008Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, R., and K. Ma, "Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics", RFC 8008, December 2016.December 2016[RFC8446]RFC 8446Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, August 2018.August 2018[RFC7516]RFC 7516Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, May 2015.May 2015[RFC7517]RFC 7517Jones, M., "JSON Web Key (JWK)", RFC 7517, May 2015.May 2015