Re: [CDNi] Request for feedback on the 3 SVTA drafts presented at IETF116

[Kevin Ma <[e-mail]>]

Hi All,

  (as an individual) I read through the protected secrets draft and have
included some comments below.

thanx!

--  Kevin J. Ma

- abstract: "for ... that may be embedded" -> "to embed ..."

- section 1: "in both the FCI and MI" -> "in both the CDNI FCI and MI"

- section 1: "(support defined in this draft is specifically for HashiCorp
Vault), which are accessed via a specified path and a key ID. Refer to
HashiCorp Vault documentation for details." -> "(e.g., HashCorp Vault
[reference])."  -- i'm not sure if we should really make a reference to a
specific implementation here; could we describe it more generically as "and
external key management system"?  counter argument: if we're going to
create a registry and register HashCorp Vault, then it's probably fine.

- section 1: remove duplicate "uCDN issues a GET to receive an
advertisement with FCI.SecretStore and FCI.SecretCertificate. As the uCDN
has not yet provided a certificate, any embedded secret values in the
advertisement are omitted."

- section 1: "uCDN issues a GET to receive an advertisement" -> "The uCDN
receives an advertisement" - CDNI FCI (currently) is a push interface via
ALTO.

- section 1: "any embedded secret values in the advertisement are omitted"
- i think this could use a little bit more explicit explanation, e.g., the
dCDN is not yet able to encrypt the secrets, so no secrets are provided.

- section 1: "uCDN issues a PUT to publish a configuration" -> "The uCDN
publishes a configuration" - CDNI MI (currently) is a pull interface;
alternately, this could be an invalidation/prepositioning trigger?

- section 1: remove " The configuration also contains MI.SecretStore and
MI.SecretCertificate." ?

- section 1: "uCDN issues a GET to receive" -> "The uCDN receives"

- section 1: "the advertisement SHOULD now contain populated MI.SecretValue
objects where necessary" - again, i think some addition context would help
here, bothas to why secrets "SHOULD" now be populated, and why the
qualifier "where necessary" is necessary

- section 1: a sequence diagram might help here.

- section 1: is "MI.LoggingTransportS3API" in a separate, yet to be adopted
draft?  we may want to remove this to remove the forward reference.

- section 3.1, "secret-store-type" type: should probably quote
"MI.SecretStoreTypeEmbedded" and "MI.SecretStoreTypeVault"

- section 3.1: should there be a registry for secret-store-types?

- section 3.1: why is "secret-certificate-id" in the MI.SecretStore object
and not in the MI.SecretStoreTypeEmbedded object if it is
MI.SecretStoreTypeEmbedded-specific?

- section 3.1: the example is duplicated in 3.2; can probably remove this
one

- section 3.2: should there be a registry for formats?

- section 3.2: there is probably going to need to be must stronger wording
around the usage (or prohibition thereof) of "cleartext"

- section 3.3: is "MI.SecretStoreTypeVault" HashiCorp Vault specific?  is
there a way to make it generic to support AWS KMS, GCP KMS, and/or Azure
Key Vault?  alternately, should the object name be made HashiCorp-specific?

- section 3.3: is there a reference for the definition of "namespace" and
"version"?

- section 3.4, "secret-store-id" description: "The linked" -> "The ID of
the"

- section 3.4: should we have separate objects for embedded secrets and
HashiCorp Vault?  it seems odd to mix "secret-value" and "secret-path" in
the same object.

- section 3.4, does one of either "secret-value" or "secret-path" have to
be specified?  the MtSs both say no, but it doesn't make sense to let them
both be blank?

- section 3.4, "timeout" description: "the specified duration" -> "this
timeout"

- section 3.4, "timeout" description: "should be discarded" -> "MUST be
discarded" or "SHOULD be discarded" ?

- section 3.5: "(CA)and" -> "(CA) and"

- section 4: I don't think we need to register separate types for FCI.  If
the "FCI.*" object is identical to the corresponding "MI.*" object, this is
just registry bloat?  there's nothing that says a "capability-type" must
start with "FCI."; you can just use the MI payload types, as long as it is
clear how to deserialize it.

- section 5: the SVTA2038 reference gives a 404.  again, i'm wondering if
there is a way to make the proposed metadata objects extensible to other
methods/services.

- section 5: remove duplicate "When the recipient of a secret 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."

- section 5: "in MI.SecretStore" -> "in an MI.SecretStore"

- section 5: a sequence diagram might help

- section 5.1: remove duplicate "The 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
that do not presently contain a secret-value property."

- section 5.1: "MI.SecretValue objects that do not presently contain a
secret-value property" - this is an incomplete sentence?

- section 5.1: a sequence diagram might help

- section 5.2: remove duplicate "The uCDN advertises an
FCI.SecretCertificate."

- section 5.2: a sequence diagram might help

- section 5.3: remove duplicate "An MI.SecretStoreTypeEmbedded has a
defined format of "cleartext"."

- section 5.3: a sequence diagram might help

- section 5.4: the uCDN should use MI to provide config to a dCDN?

- section 5.4: the dCDN should use FCI to advertise to a uCDN?

- section 7.1: this obviously needs to be filled out.



On Thu, Apr 27, 2023 at 1:16 PM Goldstein, Glenn <Glenn.Goldstein=
[e-mail]> wrote:

> We received a good chunk of comments from Kevin on the Cache Control
> Metadata draft (
> https://datatracker.ietf.org/doc/draft-power-cdni-cache-control-metadata/),
> and have addressed all the issues for the update that we will submit prior
> to IETF117.
>
>
>
> It would be very helpful if we could also get some feedback from the CDNI
> WG on the other 2 drafts:
>
>
> https://datatracker.ietf.org/doc/draft-rosenblum-cdni-protected-secrets-metadata/
>
> https://datatracker.ietf.org/doc/draft-siloniz-cdni-edge-control-metadata/
>
>
>
> thanks,
>
> Glenn
>
>
> This communication is the property of Lumen Technologies and may contain
> confidential or privileged information. Unauthorized use of this
> communication is strictly prohibited and may be unlawful. If you have
> received this communication in error, please immediately notify the sender
> by reply e-mail and destroy all copies of the communication and any
> attachments.
> _______________________________________________
> CDNi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cdni
>