CDNI Protected Secrets Metadata
draft-rosenblum-cdni-protected-secrets-metadata-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Author | Ben Rosenblum | ||
| Last updated | 2023-03-10 | ||
| Replaced by | draft-ietf-cdni-protected-secrets-metadata | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Associated None milestone |
|
||
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-rosenblum-cdni-protected-secrets-metadata-00
Network Working Group B. Rosenblum
Internet-Draft Vecima
Updates: 8006, 8008 (if approved) 10 March 2023
Intended status: Standards Track
Expires: 11 September 2023
CDNI Protected Secrets Metadata
draft-rosenblum-cdni-protected-secrets-metadata-00
Abstract
This is an early draft for a proposed mechanism to protect secret
values (such as keys or token salt values) that are part of the
Configuration Metadata.
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 11 September 2023.
Copyright Notice
Copyright (c) 2023 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.
Rosenblum Expires 11 September 2023 [Page 1]
Internet-Draft CDNI rotected Secrets Metadata March 2023
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Metadata Objects . . . . . . . . . . . . . . . . . . . . . . 3
2.1. MI.SecretStore . . . . . . . . . . . . . . . . . . . . . 3
2.2. MI.SecretStoreTypeEmbedded . . . . . . . . . . . . . . . 5
2.3. MI.SecretStoreTypeVault . . . . . . . . . . . . . . . . . 5
2.4. MI.SecretValue . . . . . . . . . . . . . . . . . . . . . 7
2.5. MI.SecretCertificate . . . . . . . . . . . . . . . . . . 8
3. Capabilities Objects . . . . . . . . . . . . . . . . . . . . 9
3.1. FCI.SecretStore . . . . . . . . . . . . . . . . . . . . . 9
3.2. FCI.SecretCertificate . . . . . . . . . . . . . . . . . . 10
4. Workflow Examples . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Workflow: uCDN -> dCDN Embedded . . . . . . . . . . . . . 12
4.2. Workflow: dCDN -> uCDN Embedded . . . . . . . . . . . . . 12
4.3. Workflow: Embedded Cleartext (uCDN and dCDN) . . . . . . 13
4.4. Workflow: uCDN -> dCDN Vault . . . . . . . . . . . . . . 13
4.5. Workflow: dCDN -> uCDN Vault . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
Certain objects in both the FCI and MI interfaces encapsulate
sensitive values such as credentials and access keys which should not
necessarily be accessible to all parties which can view the
advertisement and configuration payloads.
This subpart defines two mechanisms to enclose secret values in the
context of other FCI and MI objects which may only be viewed by the
intended recipients: embedded secrets encrypted using a certificate
supplied by counterparty, and secrets stored in an external service
(support defined in this draft specifically for HashiCorp Vault)
accessed via a specified path and a key ID.
Either side can share secrets, and the functionality is the same, so
the FCI capabilities are wrappers around the MI objects similar to
how FCI footprints (used in [RFC8008] ) reutilize the MI.Footprint
and registry defined in [RFC8006] .
Rosenblum Expires 11 September 2023 [Page 2]
Internet-Draft CDNI rotected Secrets Metadata March 2023
The public certificate for the dCDN is shared via
FCI.SecretCertificate and the certificate for the uCDN is shared via
MI.SecretCertificate.
The workflow for embedded secrets on both sides:
1. uCDN GET advertisement with FCI.SecretStore and
FCI.SecretCertificate
2. As the uCDN has not yet provided a certificate, any embedded
secret values in the advertisement are omitted.
3. uCDN PUT configuration with MI.SecretStore and MI.SecretValue
with values encrypted using dCDN certificate. Configuration also
contains MI.SecretStore and MI.SecretCertificate.
4. uCDN GET advertisement again; having provided an
MI.SecretCertificate, the advertisement now contains populated
MI.SecretValue objects where necessary.
Detailed workflow examples, including modes which reference external
services or contain secret values in plaintext, are available in
Section 4 .
The MI.SecretValue objects are utilized in the FCI and MI interfaces
where secrets must be referenced, for example, the access-key-secret
used for the MI.LoggingTransportS3API.
Certificates can be validated based on signature in production
environments, and self-signed certificates can be accepted in
testing/lab environments. With this model, no out-of-band
communication is required to share secrets.
2. Metadata Objects
2.1. MI.SecretStore
MI.SecretStore instructs the counterparty on 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 (Vault),
MI.SecretStore specifies the service endpoint that should be used in
conjunction with the MI.SecretValue key path to obtain the secure
data.
Property: secret-store-id
Rosenblum Expires 11 September 2023 [Page 3]
Internet-Draft CDNI rotected Secrets Metadata March 2023
- Description: A unique identifier for this store configuration
that is referenced from linked MI.SecretValue objects.
- Type: String.
- Mandatory-to-Specify: Yes.
Property: secret-store-type
- Description: A type discriminator for the config object, this
property specifies whether the linked MI.SecretValue objects
contain embedded secret objects or reference an external store.
- Type: String. One of MI.SecretStoreTypeEmbedded or
MI.SecretStoreTypeVault.
- Mandatory-to-Specify: Yes.
Property: secret-store-config
- Description: The appropriate configuration object for the
specified store type.
- Type: Specified by the secret-store-type property.
- Mandatory-to-Specify: Yes.
Property: secret-certificate-id
- Description: The ID of the MI.SecretStoreCertificate used to
encrypt secret messages linked with this store configuration.
Used only in the case of MI.SecretStoreTypeEmbedded.
- Type: String.
- Mandatory-to-Specify: No.
The following shows an example usage of MI.SecretStore
{
"secret-store-id": "store-1",
"secret-store-type": "MI.SecretStoreTypeEmbedded",
"secret-store-config": {
"format": "cms"
}
}
Rosenblum Expires 11 September 2023 [Page 4]
Internet-Draft CDNI rotected Secrets Metadata March 2023
2.2. MI.SecretStoreTypeEmbedded
MI.SecretStoreTypeEmbedded contains the configuration necessary to
decrypt embedded secrets in MI.SecretValue.
The only currently supported encrypted message format is
Cryptographic Message Syntax as defined in [RFC5652] . Messages must
be CMS type "EnvelopedData" and Base64 encoded.
A cleartext format is also defined for testing purposes. In this
case, the value of a MI.SecretValue object's secret-value property is
the cleartext secret.
Property: format
- Description: The format of the embedded encrypted message.
- Type: String. One of "cms" or "cleartext".
- Mandatory-to-Specify: Yes.
The following shows an example usage of MI.SecretStoreTypEmbedded
with a "cms" format.
{
"secret-store-id": "store-1",
"secret-store-type": "MI.SecretStoreTypeEmbedded",
"secret-store-config": {
"format": "cms"
}
}
2.3. MI.SecretStoreTypeVault
MI.SecretStoreTypeVault contains the configuration necessary to
reference secrets stored in an external instance of HashiCorp Vault
KV store.
MI.SecretValue objects referencing secrets stored in Vault use the
secret-path property to identify the path and property key. See the
MI.SecretValue documentation for details.
Property: endpoint
- Description: The base URL of the Vault instance.
- Type: String.
Rosenblum Expires 11 September 2023 [Page 5]
Internet-Draft CDNI rotected Secrets Metadata March 2023
- Mandatory-to-Specify: Yes.
Property: namespace
- Description: The Vault namespace in which secret lookups should
be performed.
- Type: String.
- Mandatory-to-Specify: Yes.
Property: version
- Description: The Vault KV version.
- Type: Integer. Valid values: 1 or 2.
- Mandatory-to-Specify: Yes.
The following shows an example usage of MI.SecretStoreTypVault for
Vault V1.
{
"secret-store-id": "store-2-vaultv1",
"secret-store-type": "MI.SecretStoreTypeVault",
"secret-store-config": {
"endpoint": "https://vault.example.com/v1/secret",
"version": 1,
"namespace": "customer-1"
}
}
The following shows an example usage of MI.SecretStoreTypVault for
Vault V2.
{
"secret-store-id": "store-2-vaultv2",
"secret-store-type": "MI.SecretStoreTypeVault",
"secret-store-config": {
"endpoint": "https://vault.example.com/v1/secret",
"version": 2,
"namespace": "customer-1"
}
}
Rosenblum Expires 11 September 2023 [Page 6]
Internet-Draft CDNI rotected Secrets Metadata March 2023
2.4. MI.SecretValue
MI.SecretValue may be used in any FCI or MI object where sensitive
data must be transmitted only to intended recipients.
Property: secret-store-id
- Description: The linked MI.SecretStore which 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; the Base64 encoded
value of a CMS message or the cleartext string, depending on
the defined MI.SecretStore configuration.
- Type: String.
- Mandatory-to-Specify: No.
Property: secret-path
- Description: Used only for HashiCorp Vault secrets; the path,
not including namespace, to the secret, including the key of
the particular property to access as the last path parameter.
- Type: String.
- Mandatory-to-Specify: No.
The following shows an example usage of MI.SecretValue with an
embdedded CMS secret.
Rosenblum Expires 11 September 2023 [Page 7]
Internet-Draft CDNI rotected Secrets Metadata March 2023
{
"secret-store-id": "store-1-cms",
"secret-value": "MIIBiQYJKoZIhvcNAQcDoIIBejCCAXYCAQAxggEhMIIBHQIBADAFM
AACAQEwDQYJKoZIhvcNAQEBBQAEggEApJeXzsUS1jbAyNtQiJ9um9IMIHW5B2g+gHnXdNSTy
d33OEfTR6yLSZihBlFbHpY3qSzK1CX7RF5Oz3SqLDW+r3i1D/aHbVXwQbviWHEvHterql8l9
VDm2FCNaDx5vihdbtvng3+/vdJNNMMhmovwZL5uhPsK81DkKwZCvznMMWt8YdNSFGT62f73a
sh7Eg/mS54IUyYOJHYrXEkRLSjvl0j+JqcIR8hCOCA78+5bS4MgfdsS9xxSwQTrPru6EdTiv
MDKE/jlKg7li8lWdirWqtv0za5gLmH5T+zslXIoklwERAE50Jj8FxZD98EikKH8DAa+JeFsB
m6Z1+yVFsWucTBMBgkqhkiG9w0BBwEwHQYJYIZIAWUDBAEqBBBws1riXA6m336zRbsiKtrVg
CA267133v2zD/wjFQHXrKSJfd/2YJaxPskgdmQaVlgWCw=="
}
The following shows an example usage of MI.SecretValue with a
reference to a secert stored in Vault.
{
"secret-store-id": "store-2-vaultv1",
"secret-path": "bar/baz/importantsecret",
"secret-key": "keyA"
}
2.5. MI.SecretCertificate
MI.SecretCertificate is used to share an [X.509] certificate to be
used for encrypting embedded secret messages.
In lab and testing environments, this certificate may be self-signed
depending on participant agreement.
In production environments, this should be a certificate signed by an
appropriate CA and validated by the counterparty.
Property: certificate-id
- Description: A unique ID for this certificate that can be
referenced from a corresponding MI.SecretStore configuration
defined by the counterparty.
- Type: String.
- Mandatory-to-Specify: Yes.
Property: certificate-value
- Description: The Base64 encoded certificate.
- Type: String.
Rosenblum Expires 11 September 2023 [Page 8]
Internet-Draft CDNI rotected Secrets Metadata March 2023
- Mandatory-to-Specify: Yes.
The following shows an example usage of MI.SecretCertificate.
{
"certificate-id": "store-1",
"certificate-value": "MIIDZTCCAk2gAwIBAgIUFJokJzAxDgUGsBd8uhSblpMwSLAw
DQYJKoZIhvcNAQELBQAwQjELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0dlb3JnaWExITAfBgNV
BAoMGEludGVybmV0IFdpZGdpdHMgUHR5IEx0ZDAeFw0yMzAxMjMyMDM2MDNaFw0yMzAyMjIy
MDM2MDNaMEIxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdHZW9yZ2lhMSEwHwYDVQQKDBhJbnRl
cm5ldCBXaWRnaXRzIFB0eSBMdGQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCT
11o9yebJmjiq7mXbLtnr5THpTnyahNpKECI+N8YZSl5+cS9hGa06zKQV3MNxbjJ15smmeWbg
ynYGwqhs5ZXGUjzd8S1/M1A08z1VFhEJiODQ00f3BOocpIn25RQzFz/BOLREW7sLkrhuz/WV
BR3bzp6T1gu3nKcRSNuNxO1p9490gS1LhsZYQKfNvncuxBCP0GTNbUOXd6xkQ+EX5cEKoODU
YWzOMdMAMlEEFb4jUjxYbbJoygwTMHpG2yGAQ2IXpB2/wrrawivxDHlMHGpML+Ie8o6YBR4P
DiOJmlCg9uIsirf65R1zhfcCxmNQ7z/IggC0WNQjZwymeZT9cFDdAgMBAAGjUzBRMB0GA1Ud
DgQWBBQb5eJeYLEpErJetb1eid5BgsS3uTAfBgNVHSMEGDAWgBQb5eJeYLEpErJetb1eid5B
gsS3uTAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IBAQBURnrjVbHVwfV/u/xj
zK8p4dTke0xb0oKt0J5YeH95sRa66m3tQJYf0jbMNQ8InfXK0IzGM/uUOJX3daeOMQxMbJva
UDZV64kuU6IgkEQuLwkOP5k0Rc9+SuRMlvWOB2exiyQkd2iHJtURuEtvB39LIr4pPDsicBAY
xsm5ybIWCmqNMPkVl8Qks3lAXeF+xvH11tmciTJSYP0Ud2psbV3lduD76UT2bzDGkr690Kqr
oNS57WbQrHxEhtMbdq0cPfzqFlxyhckqNYrcw2v1igQDhplQ2eUc4ye0Mvimj1Me2mWjPvil
hvS3vDGhrmcx9mlishlI/RFy6yDI1gtkF7eS"
}
3. Capabilities Objects
These objects are simple capability wrappers around the Section 2
defined MI objects.
3.1. FCI.SecretStore
FCI.SecretStore instructs the uCDN on how to dereference the value of
any MI.SecretValue objects linked to the store from other FCI objects
via an embedded MI.SecretValue object. For further details, see
Section 2.1 MI.SecretStore.
The following shows an example usage of FCI.SecretStore.
Rosenblum Expires 11 September 2023 [Page 9]
Internet-Draft CDNI rotected Secrets Metadata March 2023
{
"capabilities": [
{
"capability-type": "FCI.SecretStore",
"capability-value": {
"secret-store-id": "store-1",
"secret-store-type": "MI.SecretStoreTypeEmbedded",
"secret-store-config": {
"format": "cms"
}
}
}
]
}
3.2. FCI.SecretCertificate
FCI.SecretCertificate is used to share an [X.509] certificate to be
used for encrypting embedded secret messages via an embedded
MI.SecretCertificate object. For further details, see Section 2.5
MI.SecretCertificate.
Rosenblum Expires 11 September 2023 [Page 10]
Internet-Draft CDNI rotected Secrets Metadata March 2023
{
"capabilities": [
{
"capability-type": "FCI.SecretCertificate",
"capability-value": {
"certificate-id": "store-1",
"certificate-value": "MIIDZTCCAk2gAwIBAgIUFJokJzAxDgUGsBd8uhSblp
MwSLAwDQYJKoZIhvcNAQELBQAwQjELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0dlb3JnaWExIT
AfBgNVBAoMGEludGVybmV0IFdpZGdpdHMgUHR5IEx0ZDAeFw0yMzAxMjMyMDM2MDNaFw0yMz
AyMjIyMDM2MDNaMEIxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdHZW9yZ2lhMSEwHwYDVQQKDB
hJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAo
IBAQCT11o9yebJmjiq7mXbLtnr5THpTnyahNpKECI+N8YZSl5+cS9hGa06zKQV3MNxbjJ15s
mmeWbgynYGwqhs5ZXGUjzd8S1/M1A08z1VFhEJiODQ00f3BOocpIn25RQzFz/BOLREW7sLkr
huz/WVBR3bzp6T1gu3nKcRSNuNxO1p9490gS1LhsZYQKfNvncuxBCP0GTNbUOXd6xkQ+EX5c
EKoODUYWzOMdMAMlEEFb4jUjxYbbJoygwTMHpG2yGAQ2IXpB2/wrrawivxDHlMHGpML+Ie8o
6YBR4PDiOJmlCg9uIsirf65R1zhfcCxmNQ7z/IggC0WNQjZwymeZT9cFDdAgMBAAGjUzBRMB
0GA1UdDgQWBBQb5eJeYLEpErJetb1eid5BgsS3uTAfBgNVHSMEGDAWgBQb5eJeYLEpErJetb
1eid5BgsS3uTAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IBAQBURnrjVbHVwf
V/u/xjzK8p4dTke0xb0oKt0J5YeH95sRa66m3tQJYf0jbMNQ8InfXK0IzGM/uUOJX3daeOMQ
xMbJvaUDZV64kuU6IgkEQuLwkOP5k0Rc9+SuRMlvWOB2exiyQkd2iHJtURuEtvB39LIr4pPD
sicBAYxsm5ybIWCmqNMPkVl8Qks3lAXeF+xvH11tmciTJSYP0Ud2psbV3lduD76UT2bzDGkr
690KqroNS57WbQrHxEhtMbdq0cPfzqFlxyhckqNYrcw2v1igQDhplQ2eUc4ye0Mvimj1Me2m
WjPvilhvS3vDGhrmcx9mlishlI/RFy6yDI1gtkF7eS"
}
}
]
}
4. Workflow Examples
The facilities in this document can be used for simple and
bidirectional exchange of secret values between uCDN and dCDN
participants in an Open Caching System. The embedded model provides
for secret exchange without reference to out-of-band services, and
the Vault support allows external reference to secrets stored in
HashiCorp Vault.
Participants utilizing a secrets distribution method or service not
supported here may define a Private Feature MI object with the
necessary configuration for that method or service and then utilize
that MI object within MI.SecretStore and FCI.SecretStore.
Provided below are workflow examples for uCDN -> dCDN and dCDN ->
uCDN exchange of secret values.
Rosenblum Expires 11 September 2023 [Page 11]
Internet-Draft CDNI rotected Secrets Metadata March 2023
Consideration is needed when addressing key rollover, expiration, and
revocation in the embedded model. The recommended workflow for key
rollover is as follows:
When the secrets recipient provides an updated configuration that no
longer contains an MI.SecretCertificate with an ID referenced in
MI.SecretStore used by MI.SecretValue objects, those MI.SecretValue
objects should be reduced to an object with no contained secret-value
property as they would be in the initial state before any certificate
had been provided.
1. When the secrets recipient provides an updated configuration that
no longer contains an MI.SecretCertificate with an ID referenced
in MI.SecretStore used by MI.SecretValue objects, those
MI.SecretValue objects should be reduced to an object with no
contained secret-value property as they would be in the initial
state before any certificate had been provided.
2. If the secrets recipient then provides a new MI.SecretCertificate
object, the secrets sender should update their MI.SecretStore to
reference the new certificate-id and then update any referencing
MI.SecretValue objects to include an updated secret-value
property that contains the newly encrypted values.
4.1. Workflow: uCDN -> dCDN Embedded
1. uCDN advertises FCI.SecretStore with a store-type of
MI.SecretStoreTypeEmbedded; other FCI objects may contain
MI.SecretValue objects that reference the store-id.
MI.SecretValue objects do not presently contain a secret-value
property.
2. dCDN pushes MI configuration with an MI.SecretCertificate.
3. uCDN updates the advertised FCI.SecretStore with a certificate-id
property that references the dCDN MI.SecretCertificate; any
MI.SecretValue objects in other FCI objects now contain a secret-
value property with the CMS encrypted secret.
4.2. Workflow: dCDN -> uCDN Embedded
1. uCDN advertises an FCI.SecretCertificate.
2. dCDN pushes MI configuration containing MI.SecretStore with a
store-type of MI.SecretStoreTypeEmbedded and a certificate-id
referencing the FCI.SecretCertificate advertised by the uCDN.
Other MI objects may contain MI.SecretValue objects with a
secret-value property containing the CMS encrypted secret.
Rosenblum Expires 11 September 2023 [Page 12]
Internet-Draft CDNI rotected Secrets Metadata March 2023
4.3. Workflow: Embedded Cleartext (uCDN and dCDN)
1. An MI.SecretStoreTypeEmbedded has a defined format of
"cleartext".
2. Any MI.SecretValue objects that reference the cleartext store
contain a secret-value property with the unencrypted secret.
4.4. Workflow: uCDN -> dCDN Vault
1. uCDN advertises an FCI.SecretStore with appropriate configuration
for accessing an instance of HashiCorp Vault accessible to the
dCDN. Other FCI objects may contain MI.SecretValue objects that
reference the FCI.SecretStore and a secret-path property
specifying which secret to retrieve.
4.5. Workflow: dCDN -> uCDN Vault
1. dCDN pushes MI configuration including an MI.SecretStore with
appropriate configuration for accessing an instance of HashiCorp
Vault accessible to the uCDN. Other MI objects may contain
MI.SecretValue objects that reference the MI.SecretStore and a
secret-path property specifying which secret to retrieve.
5. Security Considerations
The FCI and 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,
confidentiality and ensuring the authenticity of the dCDN and uCDN.
The security provide by [RFC8006] should therefore address the above
security concerns.
6. IANA Considerations
6.1. CDNI Payload Types
TBD.
7. Acknowledgements
The authors would like to express their gratitude to the following
members of the Streaming Video Technology Alliance [SVTA] Open
Caching Working Group for their guidance, contribution, and review,
Glenn Goldstein
Alfonso Siloniz
Rosenblum Expires 11 September 2023 [Page 13]
Internet-Draft CDNI rotected Secrets Metadata March 2023
8. References
8.1. Normative References
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<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, 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>.
[X.509] {ITU}, "X.509", February 2011,
<http://www.itu.int/rec/T-REC-X.509>.
8.2. Informative References
[SVTA] "Streaming Video Technology Alliance Home Page",
<https://www.svta.org>.
Author's Address
Ben Rosenblum
Vecima
4375 River Green Pkwy #100
Duluth
, GA 30096
United States of America
Email: ben@rosenblum.dev
Rosenblum Expires 11 September 2023 [Page 14]