Internet-Draft CDNI Protected Secrets Metadata November 2026
Rosenblum & Goldstein Expires 6 May 2027 [Page]
Workgroup:
Content Delivery Networks Interconnection
Published:
Intended Status:
Standards Track
Expires:
Authors:
B. Rosenblum
Vecima
G. Goldstein
Lumen Technologies

Content Delivery Network Interconnection (CDNI) Protected Secrets Metadata

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.

▲

Table of Contents

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.

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|                                                           |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].

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.

  • 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:

{
  "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

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.

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

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

The following is an example of MI.SecretCertificate:

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):

{
  "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:

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.

In the embedded model, the RECOMMENDED procedure for key rollover, for example before a certificate expires, is as follows:

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.

+----+                                                           +----+
|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.

+----+                                                           +----+
|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

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.

+----+                            +----+                        +-----+
|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.

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:

Table 1: CDNI Payload Types
Payload Type Specification
MI.SecretStore RFCthis
MI.SecretStoreTypeEmbedded RFCthis
MI.SecretStoreTypeExternal RFCthis
MI.SecretValue RFCthis
MI.SecretCertificate RFCthis
FCI.SecretStore RFCthis
FCI.SecretCertificate RFCthis

[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:

9. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC3560]
Housley, R., "Use of the RSAES-OAEP Key Transport Algorithm in Cryptographic Message Syntax (CMS)", RFC 3560, DOI 10.17487/RFC3560, , <https://www.rfc-editor.org/info/rfc3560>.
[RFC4648]
Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, , <https://www.rfc-editor.org/info/rfc4648>.
[RFC5083]
Housley, R., "Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type", RFC 5083, DOI 10.17487/RFC5083, , <https://www.rfc-editor.org/info/rfc5083>.
[RFC5084]
Housley, R., "Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)", RFC 5084, DOI 10.17487/RFC5084, , <https://www.rfc-editor.org/info/rfc5084>.
[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, , <https://www.rfc-editor.org/info/rfc5280>.
[RFC5652]
Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, , <https://www.rfc-editor.org/info/rfc5652>.
[RFC8006]
Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, "Content Delivery Network Interconnection (CDNI) Metadata", RFC 8006, DOI 10.17487/RFC8006, , <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, , <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, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC9110]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, , <https://www.rfc-editor.org/info/rfc9110>.
[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, , <https://www.itu.int/rec/T-REC-X.690-202102-I/en>.

10. Informative References

[RFC7736]
Ma, K., "Content Delivery Network Interconnection (CDNI) Media Type Registration", RFC 7736, DOI 10.17487/RFC7736, , <https://www.rfc-editor.org/info/rfc7736>.
[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, , <https://www.rfc-editor.org/info/rfc8551>.
[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, , <https://www.rfc-editor.org/info/rfc8792>.
[SVTA]
SVTA, "Streaming Video Technology Alliance Home Page", <https://www.svta.org>.

Authors' Addresses

Ben Rosenblum
Vecima
United States of America
Glenn Goldstein
Lumen Technologies
United States of America