Content Delivery Networks Interconnection B. Rosenblum Internet-Draft Vecima Intended status: Standards Track G. Goldstein Expires: 6 May 2027 Lumen Technologies 2 November 2026 Content Delivery Network Interconnection (CDNI) Protected Secrets Metadata draft-ietf-cdni-protected-secrets-metadata-08 Abstract This document defines Content Delivery Network Interconnection (CDNI) Metadata Interface and Footprint and Capabilities Interface objects that carry secrets, such as encryption keys, either embedded and encrypted to the recipient's certificate or referenced in an external store. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 6 May 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Rosenblum & Goldstein Expires 6 May 2027 [Page 1] Internet-Draft CDNI Protected Secrets Metadata November 2026 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 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Metadata Objects . . . . . . . . . . . . . . . . . . . . . . 5 3.1. MI.SecretStore . . . . . . . . . . . . . . . . . . . . . 5 3.2. MI.SecretStoreTypeEmbedded . . . . . . . . . . . . . . . 6 3.3. MI.SecretStoreTypeExternal . . . . . . . . . . . . . . . 7 3.4. MI.SecretValue . . . . . . . . . . . . . . . . . . . . . 8 3.5. MI.SecretCertificate . . . . . . . . . . . . . . . . . . 10 4. Capabilities Objects . . . . . . . . . . . . . . . . . . . . 11 4.1. FCI.SecretStore . . . . . . . . . . . . . . . . . . . . . 11 4.2. FCI.SecretCertificate . . . . . . . . . . . . . . . . . . 12 5. Workflow Examples . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Workflow: dCDN -> uCDN Embedded . . . . . . . . . . . . . 14 5.2. Workflow: uCDN -> dCDN Embedded . . . . . . . . . . . . . 15 5.3. Workflow: Embedded Cleartext (uCDN and dCDN) . . . . . . 16 5.4. Workflow: dCDN -> uCDN External Store . . . . . . . . . . 17 5.5. Workflow: uCDN -> dCDN External Store . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 9. Normative References . . . . . . . . . . . . . . . . . . . . 20 10. Informative References . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction Certain objects in both the CDNI Footprint and Capabilities Interface (FCI) [RFC8008] and Metadata Interface (MI) [RFC8006] encapsulate sensitive values, such as credentials and access keys, which should not necessarily be accessible to all parties that can view the advertisement and configuration payloads. Rosenblum & Goldstein Expires 6 May 2027 [Page 2] Internet-Draft CDNI Protected Secrets Metadata November 2026 This document defines two mechanisms to enclose secret values in the context of other FCI and MI objects that may only be viewed by the intended recipients: embedded secrets encrypted using a certificate supplied by a counterparty, and secrets stored in an external service and referenced by a path. Either side can share secrets, and the functionality is the same for both sides, so the FCI capabilities are wrappers around the MI objects, similar to how FCI footprints (used in [RFC8008]) reuse the MI.Footprint and registry defined in [RFC8006]. The public certificate for the downstream content delivery network (dCDN) is shared via FCI.SecretCertificate and the certificate for the upstream content delivery network (uCDN) is shared via MI.SecretCertificate. Overview of the workflow for embedded secrets: * uCDN retrieves an advertisement with FCI.SecretStore and FCI.SecretCertificate. The uCDN has not yet provided a certificate, so the advertisement contains no secret values. * uCDN provides configuration including MI.SecretStore, MI.SecretCertificate and MI.SecretValue with values encrypted using the dCDN certificate. * uCDN receives an updated advertisement with secret values encrypted using the uCDN certificate. Rosenblum & Goldstein Expires 6 May 2027 [Page 3] Internet-Draft CDNI Protected Secrets Metadata November 2026 +----+ +----+ |uCDN| |dCDN| +----+ +----+ | Retrieve FCI.SecretStore and FCI.SecretCertificate | |--------------------------------------------------------------->| | | |---- | | | Encrypt secrets using provided FCI.SecretCertificate | |<--- | | | | Provide MI.SecretStore, MI.SecretCertificate and | | MI.SecretValue with encrypted secrets | |--------------------------------------------------------------->| | | | ----| | Encrypt secrets using provided MI.SecretCertificate | | | --->| | | | Retrieve FCI objects with encrypted MI.SecretValue | |--------------------------------------------------------------->| | | +----+ +----+ |uCDN| |dCDN| +----+ +----+ Figure 1: Bi-directional Protected Secrets Workflow, Embedded Store Detailed workflow examples, including modes that reference external services or contain secret values in cleartext, are available in the Workflow Examples (Section 5) section. The sender of a secret validates the recipient's certificate before it uses the certificate (Section 3.5). 2. Requirements 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. Long lines in examples are folded as described in [RFC8792]. Rosenblum & Goldstein Expires 6 May 2027 [Page 4] Internet-Draft CDNI Protected Secrets Metadata November 2026 3. Metadata Objects MI.SecretStore and MI.SecretCertificate are GenericMetadata objects (Section 4.1.7 of [RFC8006]). An MI.SecretValue is the value of a property of another MI or FCI object. 3.1. MI.SecretStore MI.SecretStore instructs the counterparty how to dereference the value of any MI.SecretValue objects linked to the store. For embedded stores, MI.SecretStore identifies the certificate used for encrypting the values. For external stores, MI.SecretStore specifies the endpoint that is used with the secret-path property of MI.SecretValue to obtain the secret. Additional store types can be registered as CDNI Payload Types [RFC7736]. The specification of a store type defines its secret- store-config object and how linked MI.SecretValue objects are dereferenced. A recipient that does not support the secret-store- type of an MI.SecretStore MUST treat MI.SecretValue objects linked to that store as unavailable. Property: secret-store-id * Description: An identifier for this store configuration that is referenced from linked MI.SecretValue objects. This value MUST be unique within the context of the metadata objects and the FCI advertisement. * Type: String * Mandatory-to-Specify: Yes Property: secret-store-type * Description: The CDNI Payload Type [RFC7736] of the object contained in the secret-store-config property. * Type: String * Mandatory-to-Specify: Yes Property: secret-store-config * Description: An object conforming to the specification associated with the secret-store-type. Rosenblum & Goldstein Expires 6 May 2027 [Page 5] Internet-Draft CDNI Protected Secrets Metadata November 2026 * Type: Object * Mandatory-to-Specify: Yes 3.2. MI.SecretStoreTypeEmbedded MI.SecretStoreTypeEmbedded contains the configuration necessary to decrypt embedded secrets in MI.SecretValue. The encrypted message format is Cryptographic Message Syntax (CMS) as defined in [RFC5652]. Messages MUST be CMS type "AuthEnvelopedData" [RFC5083]. Messages MUST be base64-encoded (Section 4 of [RFC4648]) DER [X.690] CMS ContentInfo structures. Implementations MUST support AES-128-GCM [RFC5084] and RSAES-OAEP [RFC3560]. RSA keys MUST be at least 2048 bits long. Other algorithms MAY be used by agreement between the parties. A cleartext format is also defined for testing purposes. In this case, the value of an MI.SecretValue object's secret-value property is the cleartext secret. It is NOT RECOMMENDED to use the cleartext format in production environments. Property: format * Description: The format of the embedded secret. Other formats require a new store type (Section 3.1). * Type: String. Either "cms" or "cleartext". * Mandatory-to-Specify: Yes Property: secret-certificate-id * Description: The ID of the MI.SecretCertificate used to encrypt secret messages linked with this store configuration. * Type: String * Mandatory-to-Specify: Yes when format is "cms" and a linked MI.SecretValue contains secret-value, otherwise No. The following is an example of MI.SecretStore with an MI.SecretStoreTypeEmbedded configuration using CMS: Rosenblum & Goldstein Expires 6 May 2027 [Page 6] Internet-Draft CDNI Protected Secrets Metadata November 2026 { "secret-store-id": "ucdn-store-1", "secret-store-type": "MI.SecretStoreTypeEmbedded", "secret-store-config": { "format": "cms", "secret-certificate-id": "dcdn-cert-1" } } Figure 2 3.3. MI.SecretStoreTypeExternal MI.SecretStoreTypeExternal contains the configuration necessary to reference secrets stored in an external key/value secret store. MI.SecretValue objects reference secrets stored in the external store using the secret-path property to identify the path and property key. See the MI.SecretValue (Section 3.4) section for details. This document does not define the protocol to retrieve a secret from an external store or how the recipient authenticates to the store. The parties agree on both. Store types that define them can be registered (Section 3.1). Property: endpoint * Description: The base URL of the external secret store. The URL MUST use the "https" scheme (Section 4.2.2 of [RFC9110]). * Type: String * Mandatory-to-Specify: Yes The following is an example of MI.SecretStore with an MI.SecretStoreTypeExternal configuration: { "secret-store-id": "ucdn-store-2", "secret-store-type": "MI.SecretStoreTypeExternal", "secret-store-config": { "endpoint": "https://secrets.example.com/" } } Figure 3 Rosenblum & Goldstein Expires 6 May 2027 [Page 7] Internet-Draft CDNI Protected Secrets Metadata November 2026 3.4. MI.SecretValue MI.SecretValue may be used in any FCI or MI object where sensitive data must be transmitted only to intended recipients. An MI.SecretValue MUST NOT contain both secret-value and secret-path. With MI.SecretStoreTypeEmbedded, an MI.SecretValue without secret- value indicates that the secret is not available, for example before the recipient has provided a certificate or after it has removed its certificate. The recipient MUST treat such an MI.SecretValue as unavailable. Property: secret-store-id * Description: The ID of MI.SecretStore that contains the configuration defining how to decrypt or access the referenced secret. * Type: String * Mandatory-to-Specify: Yes Property: secret-value * Description: Used only for embedded secrets. Format is one of the following: - The cleartext string - The base64-encoded DER CMS message, as specified in Section 3.2. * Type: String * Mandatory-to-Specify: No Property: secret-path * Description: Used only for external store secrets, the path to the secret, including the key of the particular property to access as the last path parameter. * Type: String * Mandatory-to-Specify: Yes when the store type is MI.SecretStoreTypeExternal, No when it is MI.SecretStoreTypeEmbedded. Rosenblum & Goldstein Expires 6 May 2027 [Page 8] Internet-Draft CDNI Protected Secrets Metadata November 2026 Property: timeout * Description: If this property is present and the elapsed time since last retrieving the secret value has exceeded this timeout, any cached instance of this secret value MUST be discarded and fetched again from the associated secret store. If this property is absent, the sender sets no limit on how long the recipient caches the secret value. This value has no effect when using an embedded store. * Type: Integer duration in seconds. * Mandatory-to-Specify: No The following is an example of MI.SecretValue specifying an embedded value: NOTE: '\' line wrapping per RFC 8792 { "secret-store-id": "ucdn-store-1", "secret-value": "MIIB4QYLKoZIhvcNAQkQARegggHQMIIBzAIBADGCAXYwggFyA\ gEAMC8wFzEVMBMGA1UEAwwMZGNkbi5leGFtcGxlAhQtq7Z+mgaIVXjibwZStYXPy\ f8WXjA4BgkqhkiG9w0BAQcwK6ANMAsGCWCGSAFlAwQCAaEaMBgGCSqGSIb3DQEBC\ DALBglghkgBZQMEAgEEggEAqk2kskAdPgP12PSFGPYjgGPXeXddMSTgd9hZ3Dk8l\ 4ehP6O+GvjhgMOeNtB/9WN1WjxbGcbLyPgYPJa9hVGhC2KFeJCRMEn8kk4F/k3I1\ f10Jpx2ILaRTc3AkApuMLaxZSaVbQ63NTxhYXGMh+EVdJaY6+EMzkA2IH9D7k7ZI\ jb8YX6Myr8r3Cm/eq0HxPHQztukY2Jcr6vg5H6jG4zhsrBZFaHRpAYK6sOErIyjp\ F28xz88+lQIRipsQhPqkZ1deVFYChs/Ix9mjS3URxrtS/KGj/iZdScyQxb4Y792X\ tW1XHaePy9o+f6hLHx6rUkddJfxyWvkUIs/wJEsyC6CfjA7BgkqhkiG9w0BBwEwH\ gYJYIZIAWUDBAEGMBEEDFMmNO9IlChMEqeyCgIBEIAOEDVew3L0nP+Iapd1SfMEE\ KgqlUi+oRvbBLQ0UXn/c8Y=" } Figure 4 The following is an example of MI.SecretValue for an external store: { "secret-store-id": "ucdn-store-2", "secret-path": "bar/baz/importantsecret", "timeout": 3600 } Figure 5 Rosenblum & Goldstein Expires 6 May 2027 [Page 9] Internet-Draft CDNI Protected Secrets Metadata November 2026 3.5. MI.SecretCertificate MI.SecretCertificate is used to share an X.509 certificate [RFC5280] to be utilized for encrypting embedded secret messages. Before the sender of a secret uses a certificate to encrypt the secret, it MUST validate the certificate in one of these ways: * Certification path validation (Section 6 of [RFC5280]) to a trust anchor agreed between the parties, and a check that the certificate identifies the counterparty. * Comparison with a certificate or public key that the parties exchanged out of band. The certificate-value property contains one certificate; the parties agree how the sender obtains any intermediate certificates. Property: certificate-id * Description: An identifier for this MI.SecretCertificate that is referenced by the secret-certificate-id property of a counterparty's MI.SecretStoreTypeEmbedded configuration. This value MUST be unique within the context of the metadata objects and the FCI advertisement. * Type: String * Mandatory-to-Specify: Yes Property: certificate-value * Description: The base64-encoded (Section 4 of [RFC4648]) DER [X.690] certificate. * Type: String * Mandatory-to-Specify: Yes The following is an example of MI.SecretCertificate: Rosenblum & Goldstein Expires 6 May 2027 [Page 10] Internet-Draft CDNI Protected Secrets Metadata November 2026 NOTE: '\' line wrapping per RFC 8792 { "certificate-id": "ucdn-cert-1", "certificate-value": "MIIDHDCCAgSgAwIBAgIUfqyKmabtHWTnPBb+UZ8Lt0qC\ DBEwDQYJKoZIhvcNAQELBQAwFzEVMBMGA1UEAwwMdWNkbi5leGFtcGxlMB4XDTI2\ MTEwMjE4NDU1MVoXDTM2MTAzMDE4NDU1MVowFzEVMBMGA1UEAwwMdWNkbi5leGFt\ cGxlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnGkTFuH00aaeaXZm\ 7EaXQlMSn89rkA8xgrnqswZl7S6lULM5GJU+2ECxdsmZhL759YuxYe9R8YXoQoMZ\ tOgOlbR1YlinxO/sQMAqQk0KkwpK9oowRqFss+KcEvZ8HovhvHATc3OySCd4vVoU\ KNPX+tH0mZR2whE0qbAHm/1eggL43LPRJRcpTY5gGWBtRkcrt1OGO4ChmC0Cr5Ep\ L42SFlBDCeEeRUDXBO1EAG28c1ynC9ek27hZt8BOOttK2vYudWp7nRK4LB5fZPfp\ 3nrQb/TM4GZnfzLwMSCNeZBRdRIuwLLGL9+R6+NqFQ69C+2P2AgUiaxm8r8kIJoc\ SP21qwIDAQABo2AwXjAdBgNVHQ4EFgQUq0JZOFLdE68bsTShXt0weM546IUwHwYD\ VR0jBBgwFoAUq0JZOFLdE68bsTShXt0weM546IUwDAYDVR0TAQH/BAIwADAOBgNV\ HQ8BAf8EBAMCBSAwDQYJKoZIhvcNAQELBQADggEBAH+VMRITZwcw80RNtJsiUAGG\ WMU8F+Ve1olo3z7HwExeq0KOyekU1GzTmBEZopMYfDKCDeF+InDzdLsJL9xeQLab\ YiWCnfBqyOGmqqEXgg+KcUUdrec/eKzLhnLQVj0HPRTgcBHfTD4sp96KqQu13Ijw\ hrGNLh2n0khBVex5k/eEb8jycMh4rQq/Dddtxc+shMjFk6afJ6V2hm4R4WcGhbFn\ QfLkfqO2QDskBeBlMifuB61qutqEJ2n2q/teImuyKiUGAQLVLH7HBYiyOijId0cs\ VF39LGygRJh5x+TQ3AUsN9I/dy7GdL0PmnJQAENzTXPfQAVvN0ekTAVfh54Rzok=" } Figure 6 4. Capabilities Objects These objects are FCI capability objects (Section 5.1 of [RFC8008]) whose capability-value is the corresponding MI object defined in Section 3. 4.1. FCI.SecretStore FCI.SecretStore instructs the uCDN how to dereference the value of any MI.SecretValue objects linked to the store from other FCI objects via an embedded MI.SecretStore object. For further details, see the MI.SecretStore (Section 3.1) section. The following is an example of FCI.SecretStore before the uCDN has provided a certificate (step 1 in Section 5.1): Rosenblum & Goldstein Expires 6 May 2027 [Page 11] Internet-Draft CDNI Protected Secrets Metadata November 2026 { "capabilities": [ { "capability-type": "FCI.SecretStore", "capability-value": { "secret-store-id": "dcdn-store-1", "secret-store-type": "MI.SecretStoreTypeEmbedded", "secret-store-config": { "format": "cms" } } } ] } Figure 7 4.2. FCI.SecretCertificate FCI.SecretCertificate is used to share an X.509 certificate [RFC5280] to be utilized for encrypting embedded secret messages via an embedded MI.SecretCertificate object. For further details, see the MI.SecretCertificate (Section 3.5) section. The following is an example of FCI.SecretCertificate: Rosenblum & Goldstein Expires 6 May 2027 [Page 12] Internet-Draft CDNI Protected Secrets Metadata November 2026 NOTE: '\' line wrapping per RFC 8792 { "capabilities": [ { "capability-type": "FCI.SecretCertificate", "capability-value": { "certificate-id": "dcdn-cert-1", "certificate-value": "MIIDHDCCAgSgAwIBAgIULau2fpoGiFV44m8GUr\ WFz8n/Fl4wDQYJKoZIhvcNAQELBQAwFzEVMBMGA1UEAwwMZGNkbi5leGFt\ cGxlMB4XDTI2MTEwMjE4NDU1MloXDTM2MTAzMDE4NDU1MlowFzEVMBMGA1\ UEAwwMZGNkbi5leGFtcGxlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB\ CgKCAQEAvjNpLTTKkWGAYvrO22MPt7UnHHH8ALLSCfrv3hLcYJizYNrPwi\ 7oMwzEUKObPrLxx1dNHBSQKUtWwa/i8MlRjQpyg+hxlbeoVzbwui8iECyI\ qbkRgjO0U0+FuYByi92Pj1dMJCuFfvvw91ZZ4ZbS+vj6twteVral3yO3XI\ BbOzljxxVCi2QEtI/H0zVt9MFViDzswQ8xZ8XC32qLIfgIcjP+wsN7ML0R\ 2HCYoGuFK2ZT+Tss3Mzt8Z0a3xN2ZM9cGHi7ujPYQIeolPowd7Lr/TWd4b\ yV8uyy3RIV91ED6g67rE9mDCw/M/73jx71dcGwGpuBdu2PEDNptiUH1Ap/\ BQIDAQABo2AwXjAdBgNVHQ4EFgQUgPa2cu1ecgfdoPFvR8fPC3pw41UwHw\ YDVR0jBBgwFoAUgPa2cu1ecgfdoPFvR8fPC3pw41UwDAYDVR0TAQH/BAIw\ ADAOBgNVHQ8BAf8EBAMCBSAwDQYJKoZIhvcNAQELBQADggEBAFzyGgbmRi\ ijJc2NxXhyKmrJjEOu/XPOysbQWPGOOhloTeNjOW4ZVWwF3Leddkp/ympv\ kbfk1fx4PWYfPdrskhfAhs7EQfWgnBd1sV9FcLJEme3yE0Z94RMbmo2Qjy\ 9V8ji91KE/rQwLxbRsdqIVsOn15uSynUxoxz6SO0HKjyR4aiOXoRvsKZ+Y\ SUq3w2we0Qmdal+Esk2q/+3ueZM/+ZUhP5aItMxL4yk8fSPKizbLDBmS4F\ c3i/heacLJEIEnuADDjIjOV+3o40IBWSS9BN8/crikaGyN5wjNkQGsKYCq\ 8M+0qri/sIMp7gT9+MKsZ6/WDbOEuFnhk4DowK7eims=" } } ] } Figure 8 5. Workflow Examples The facilities in this document can be used for simple and bidirectional exchange of secret values between a uCDN and a dCDN. The embedded model provides for a secret exchange without reference to out-of-band services, while the external store support allows for reference to secrets stored in an external key/value store. Other secret distribution methods can be supported by defining new store types (Section 3.1). Provided below are workflow examples for uCDN -> dCDN and dCDN -> uCDN exchanges of secret values. Rosenblum & Goldstein Expires 6 May 2027 [Page 13] Internet-Draft CDNI Protected Secrets Metadata November 2026 In the embedded model, the RECOMMENDED procedure for key rollover, for example before a certificate expires, is as follows: * The recipient of a secret provides an MI.SecretCertificate with the same certificate-id and a new certificate-value, and keeps the previous private key. * The sender of the secret SHOULD then encrypt the linked secrets with the new certificate and update the secret-value properties. * The recipient can discard the previous private key when no secret- value that it holds uses it. The RecipientInfo of each CMS message identifies the certificate used (Section 6.2 of [RFC5652]). To revoke a certificate, for example after a key compromise, the recipient removes the MI.SecretCertificate. The sender SHOULD then remove the secret-value property from the linked MI.SecretValue objects, as in the initial state before any certificate has been provided. 5.1. Workflow: dCDN -> uCDN Embedded 1. The dCDN advertises FCI.SecretStore with a secret-store-type of MI.SecretStoreTypeEmbedded; other FCI objects may contain MI.SecretValue objects that reference the secret-store-id. MI.SecretValue objects do not presently contain a secret-value property. 2. The uCDN pushes the MI configuration with an MI.SecretCertificate. 3. The dCDN updates the advertised FCI.SecretStore with a secret- certificate-id property that references the uCDN MI.SecretCertificate provided in step 2; any MI.SecretValue objects in other FCI objects now contain a secret-value property with the CMS encrypted secret. Rosenblum & Goldstein Expires 6 May 2027 [Page 14] Internet-Draft CDNI Protected Secrets Metadata November 2026 +----+ +----+ |uCDN| |dCDN| +----+ +----+ | Retrieve FCI.SecretStore | |--------------------------------------------------------------->| | | | Provide MI.SecretCertificate | |--------------------------------------------------------------->| | | | ----| | Encrypt secrets using provided MI.SecretCertificate | | | --->| | | | Retrieve FCI objects with encrypted MI.SecretValue | |--------------------------------------------------------------->| | | +----+ +----+ |uCDN| |dCDN| +----+ +----+ Figure 9: dCDN -> uCDN Workflow, Embedded Store 5.2. Workflow: uCDN -> dCDN Embedded 1. The dCDN advertises an FCI.SecretCertificate. 2. The uCDN pushes the MI configuration containing MI.SecretStore with a secret-store-type of MI.SecretStoreTypeEmbedded and a secret-certificate-id referencing the FCI.SecretCertificate advertised by the dCDN. Other MI objects may contain MI.SecretValue objects with a secret-value property containing the CMS encrypted secret. Rosenblum & Goldstein Expires 6 May 2027 [Page 15] Internet-Draft CDNI Protected Secrets Metadata November 2026 +----+ +----+ |uCDN| |dCDN| +----+ +----+ | Retrieve FCI.SecretCertificate | |--------------------------------------------------------------->| | | |---- | | | Encrypt secrets using provided FCI.SecretCertificate | |<--- | | | | Provide MI.SecretStore and MI.SecretValue objects | |--------------------------------------------------------------->| | | +----+ +----+ |uCDN| |dCDN| +----+ +----+ Figure 10: uCDN -> dCDN Workflow, Embedded Store 5.3. Workflow: Embedded Cleartext (uCDN and dCDN) 1. An MI.SecretStore has an MI.SecretStoreTypeEmbedded configuration with format "cleartext". 2. Any MI.SecretValue objects that reference the cleartext store contain a secret-value property with the unencrypted secret. +----+ +----+ |uCDN| |dCDN| +----+ +----+ | Retrieve FCI.SecretStore ("cleartext") and FCI objects | | with MI.SecretValue | |--------------------------------------------------------------->| | | | Provide MI.SecretStore ("cleartext") and MI.SecretValue | |--------------------------------------------------------------->| | | +----+ +----+ |uCDN| |dCDN| +----+ +----+ Figure 11: Embedded Cleartext Workflow Rosenblum & Goldstein Expires 6 May 2027 [Page 16] Internet-Draft CDNI Protected Secrets Metadata November 2026 5.4. Workflow: dCDN -> uCDN External Store The dCDN advertises an FCI.SecretStore with an appropriate configuration for accessing an external secret store accessible to the uCDN. Other FCI objects may contain MI.SecretValue objects that reference the FCI.SecretStore and a secret-path property specifying the secret to retrieve. +----+ +----+ +-----+ |uCDN| |dCDN| |Store| +----+ +----+ +-----+ | Retrieve external FCI.SecretStore | | | and FCI objects with MI.SecretValue | | |--------------------------------------------------->| | | | | | Retrieve secrets using path provided | | | in MI.SecretValue objects | | |----------------------------------------------------|---------->| | | | +----+ +----+ +-----+ |uCDN| |dCDN| |Store| +----+ +----+ +-----+ Figure 12: dCDN -> uCDN Workflow, External Store 5.5. Workflow: uCDN -> dCDN External Store The uCDN provides the MI configuration, including an MI.SecretStore with appropriate configuration for accessing an external secret store accessible to the dCDN. Other MI objects may contain MI.SecretValue objects that reference the MI.SecretStore and a secret-path property specifying the secret to retrieve. Rosenblum & Goldstein Expires 6 May 2027 [Page 17] Internet-Draft CDNI Protected Secrets Metadata November 2026 +----+ +----+ +-----+ |uCDN| |dCDN| |Store| +----+ +----+ +-----+ | | | | Provide external MI.SecretStore | | | and MI.SecretValue objects | | |-------------------------------->| | | | | | | Retrieve secrets using path | | | provided in MI.SecretValue | | | objects | | |----------------------------->| | | | +----+ +----+ +-----+ |uCDN| |dCDN| |Store| +----+ +----+ +-----+ Figure 13: uCDN -> dCDN Workflow, External Store 6. Security Considerations The objects defined in this document are carried in the FCI and the MI, and the security considerations of Section 7 of [RFC8008] and Section 8 of [RFC8006] apply. Both require authentication of the peers and protection of the integrity and confidentiality of the objects. An attacker that can insert, delete, modify or replay MI or FCI objects can, for example, add its own secrets, replace a certificate or a store endpoint, remove a secret, or bring back a replaced secret. As Section 7 of [RFC8008] assumes, the parties have a preexisting relationship; misuse of a secret by a party authorized to hold it is out of scope. Section 7 of [RFC8008] finds no apparent need for further object- level security in bilateral CDNI relationships. The confidentiality of secrets is an exception: MI and FCI payloads are visible to more systems and people than the component that uses a secret, for example when they are stored, logged or shown in management tools. With the "cms" format, only the holder of the recipient's private key can read a secret; with an external store, the secret is not in the payload. AuthEnvelopedData protects the confidentiality and integrity of a secret but does not authenticate the sender (Section 2.4.4 of [RFC8551]): anyone who has the recipient's certificate can create a valid message. The security considerations of [RFC5652], [RFC5083], [RFC5084] and [RFC3560] apply. The "cleartext" format provides no protection beyond that of the interfaces. Rosenblum & Goldstein Expires 6 May 2027 [Page 18] Internet-Draft CDNI Protected Secrets Metadata November 2026 An attacker that replaces the certificate in an MI.SecretCertificate or FCI.SecretCertificate with its own receives every secret later encrypted to it; the validation in Section 3.5 protects against this. Removing a certificate (Section 5) does not protect secrets already encrypted to it, so after a compromise of the recipient's private key the sender SHOULD replace the affected secrets with new values. For external stores, the endpoint is an "https" URL (Section 3.3), so the recipient verifies the identity of the store (Section 4.3.4 of [RFC9110]); the parties agree how the recipient authenticates to the store. The sender supplies the endpoint, so a recipient can be made to send requests, possibly with its store credentials, to other systems, including systems in its own network. Recipients SHOULD send requests only to endpoints agreed between the parties. The availability of a secret in an external store depends on the store; a longer timeout (Section 3.4) reduces this dependence but keeps a replaced secret in use for longer. A recipient that uses an empty or default value in place of an unavailable secret can remove the protection that the secret provides. Implementations SHOULD NOT log secrets. 7. IANA Considerations 7.1. CDNI Payload Types This document requests the registration of the following entries under the "CDNI Payload Types" registry hosted by IANA: +----------------------------+---------------+ | Payload Type | Specification | +----------------------------+---------------+ | MI.SecretStore | RFCthis | +----------------------------+---------------+ | MI.SecretStoreTypeEmbedded | RFCthis | +----------------------------+---------------+ | MI.SecretStoreTypeExternal | RFCthis | +----------------------------+---------------+ | MI.SecretValue | RFCthis | +----------------------------+---------------+ | MI.SecretCertificate | RFCthis | +----------------------------+---------------+ | FCI.SecretStore | RFCthis | +----------------------------+---------------+ | FCI.SecretCertificate | RFCthis | +----------------------------+---------------+ Table 1: CDNI Payload Types Rosenblum & Goldstein Expires 6 May 2027 [Page 19] Internet-Draft CDNI Protected Secrets Metadata November 2026 [RFC Editor: Please replace RFCthis with the published RFC number for this document.] 8. Acknowledgements The authors would like to express their gratitude to the members of the Streaming Video Technology Alliance [SVTA] Open Caching Working Group for their contributions and guidance. The following people contributed to this document: * Chris Lemmons (Comcast) * Rajeev RK (picoNETS) * Yoav Gressel (Qwilt) * Arnon Warshavsky (Qwilt) * Alfonso Siloniz (Telefonica) 9. 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, . [RFC3560] Housley, R., "Use of the RSAES-OAEP Key Transport Algorithm in Cryptographic Message Syntax (CMS)", RFC 3560, DOI 10.17487/RFC3560, July 2003, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type", RFC 5083, DOI 10.17487/RFC5083, November 2007, . [RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)", RFC 5084, DOI 10.17487/RFC5084, November 2007, . Rosenblum & Goldstein Expires 6 May 2027 [Page 20] Internet-Draft CDNI Protected Secrets Metadata November 2026 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, . [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, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [X.690] ITU-T, "Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, February 2021, . 10. Informative References [RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI) Media Type Registration", RFC 7736, DOI 10.17487/RFC7736, December 2015, . [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification", RFC 8551, DOI 10.17487/RFC8551, April 2019, . Rosenblum & Goldstein Expires 6 May 2027 [Page 21] Internet-Draft CDNI Protected Secrets Metadata November 2026 [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, "Handling Long Lines in Content of Internet-Drafts and RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, . [SVTA] SVTA, "Streaming Video Technology Alliance Home Page", . Authors' Addresses Ben Rosenblum Vecima United States of America Email: ben@rosenblum.dev Glenn Goldstein Lumen Technologies United States of America Email: glenng1215@gmail.com Rosenblum & Goldstein Expires 6 May 2027 [Page 22]