Re: [CDNi] FW: I-D Action: draft-ietf-cdni-https-delegation-subcerts-02.txt

["Kevin J. Ma" <[e-mail]>]

Hi Christoph,

  The draft looks good.  Just some more nits below.

thanx!

--  Kevin J. Ma

nits:

abstract:
 "in CDNI Control and Metadata interface" -> "in the CDNI Metadata interface"

section 1:
 remove " examples of the documents."
 "includes a proposal of IANA registry to enable adding of new methods." -> "proposes an IANA registry for future methods"
 i don't personally feel the ToC paragraph is necessary but if kept (also applies to section names):
   "(FCI) for delegated credentials" -> "(FCI) capabilities object for delegated credentials"
   "(MI) for delegated credentials" -> "(MI) metadata object for delegated credentials"
   "(FCI) for delegated credentials" -> "(FCI) capabilities object for delegated credentials"
   "IANA registry" -> "IANA registries"

section 3.2:
 "uCDN SHOULD remember and keep track of" -> "The uCDN SHOULD monitor"
 "The uCDN SHOULD refresh and provision on time the dCDN with new credentials through MI according to the dCDN capability." -> "The uCDN should timely refresh dCDN credentials via the MI."

section 4:
 "set a delegation to a downstream entity such as a downstream CDN (i.e., dCDN)" -> "delgated to a dCDN"
 "end-user client application" -> "User Agent"
 "end user client" -> "User Agent"
 "out of band" -> "out-of-band"
 missing indentation in the json example
 can we add a "SHOULD NOT" or "NOT RECOMMENDED" wrt adding a private-key? (i see it is in section 7, but it doesn't hurt to put it here too)

section 5:
 "on-purpose when dCDN" -> "on-demand when the dCDN"
 "required delegated crednetials" -> "supported delegated crednetials"
 "Using CDNI Footprint" -> "Using the CDNI Footprint"
 "Using CDNI the Metadata" -> "Using the CDNI Metadata"
 "Some delegated credentials are about to expire. The uCDN uses CDNI" -> "When some delegated credentials are about to expire, the uCDN uses the CDNI"
 could add vertical ellipses to temporally separate 5 from 4, and 6 from 5

section 6.2:
 "see see" -> "see"

section 7:
 "if it is in the" -> "if it is in"
 "it is recommended not to send private keys" -> "it is NOT RECOMMENDED to send private keys"
 "as it further limits the possibility by attacker to exploit the delegated credential" -> "as omitting the private key further limits the possibility exploits by an attacker"
 "more important number" -> "consecutive or consistent set"

section 8:
 title: "Security" -> "Privacy"
 "FCI and" -> "FCI, and"

Sent from my iPhone

On May 4, 2023, at 5:06 AM, Christoph Neumann <[e-mail]> wrote:



Hi Kevin, all,

 

I worked on a new version of the draft to address all your comments and submitted the document.

All, please review the document and provide comments and feedbacks.

 

Below is the detail of the modifications according to Kevin comments.

 

Christoph

 

>  The RFC2119 boilerplate is missing

Done

> general: "i.e." -> "i.e.,"

Done

> general: "e.g." -> "e.g.,"  

Done

> I think the second paragraph of section 1 is unnecessary

Removed. Done

> I think we can remove section 2.1 now

Removed. one

> I'm not sure if the ACME discussion in section 3 is relevant?

Agreed. I removed Section 3.

> section 4.1: "allows to announce" -> "enables advertising"

Done

> section 4.1: i would add another example with the MI.DelegatedCredentials metadata object advertisement, since it is mentioned in section 4.0

Done

> section 4.2: "When uCDN queries and retrieves" -> "When the uCDN receives", since CDNI does not officially support an FCI request interface

Done

> section 4.2: "within a dCDN" -> "within a dCDN,"

Done

> section 4.2: "This choice depends" -> "This choice is at the discretion of the dCDN and depends"

Done

> section 4.2: "FCI.DelegationCredentials is not used to cope with" -> "The FCI.DelegationCredentials object does not address"

Done

> section 4.2: "MI interface, uCDN" -> "MI, the uCDN"

Done

> section 4.2: "The uCDN knowing the expiry times" -> "As the uCDN knows the expiry times"

Done

> section 4.2: is the "must" in this section an RFC2119 "MUST"? and is it further a "MUST" that the uCDN refresh the certs? 

I think for both cases it is a SHOULD. There might be valid reasons for a uCDN not to keep track of certificate validy periodsand refresh the certs  (e.g., single shot deployments, deprovisioning of dCDN)

> section 5: i don't think the "must" is an RFC2119 "MUST"?  can we reword it?

Reworded as descriptive text recalling the subcert mechanism instead of normative sepcification text.

> section 5: "the object, MI.DelegatedCredentials" -> "the MI.DelegatedCredentials object"

Done

> section 5: i think it would be cleaner to define an object that has the two properties: delegated-credential and private-key, and give the delegated-credentials object a "Type: Array of <object_name> objects"

Done

> section 5: "of the array of the property delegated-credentials" -> "of the property delegated-credentials array"  

Changed by naming the object

> section 5: the delegated-credential and private-key properties need a "Type: String" ?

Added the type String. Done.

> section 5: is the private-key base64 encoded?

Yes. I also changed the encoding of the delgated credential to Base64 as this is more efficient.

> section 5: "If not used, we suppose that" -> "If not specified, it is assumed that the"

Done

> section 5: "mechanism outside of this specification" -> "out of band mechanism"

Done

> section 6: "We suppose" -> "It is assumed" (in multiple places)

Done

> section 6, bullet 6: "CDNI the Metadata interface to push" -> "the MI to provide", since CDNI does not technically support metadata push

Done

> section 7.1: the "Encoding" should reference section 5.0

Done

> section 7.2: the "Encoding" should reference section 4.1

Done

> section 8: "allow to provide" -> "enable providing"

Done

> section 8: i think we need to say something about sending keys in metadata, e.g., though the keys are short lived, passing key material through the MI is dangerous and should be avoided

I reformulated the Section 8 accordingly

> section 10.1: i don't think the ACME RFCs or the ACME draft are normative.  i also don't think RFC8007 is a normative reference?

ACME RFC and RFC8007 are both normative. The RFC coming out of the ACME draft will also be normative. Done

 

 

From: Kevin Ma <[e-mail]>
Sent: Wednesday, March 15, 2023 5:35 AM
To: Christoph Neumann <[e-mail]>
Cc: [e-mail]
Subject: Re: [CDNi] FW: I-D Action: draft-ietf-cdni-https-delegation-subcerts-02.txt

 

Hi Christoph,

 

  Thanks for the update.  With the ACME draft now in WGLC, I think we can similarly tighten up the text for the subcerts draft, make it more concise, and push it across the line.  I've included some comments below.

 

thanx!

 

--  Kevin J. Ma

 

- The RFC2119 boilerplate is missing
- general: "i.e." -> "i.e.,"
- general: "e.g." -> "e.g.,"
- I think the second paragraph of section 1 is unnecessary
- I think we can remove section 2.1 now
- I'm not sure if the ACME discussion in section 3 is relevant?
- section 4.1: "allows to announce" -> "enables advertising"
- section 4.1: i would add another example with the MI.DelegatedCredentials metadata object advertisement, since it is mentioned in section 4.0
- section 4.2: "When uCDN queries and retrieves" -> "When the uCDN receives", since CDNI does not officially support an FCI request interface
- section 4.2: "within a dCDN" -> "within a dCDN,"
- section 4.2: "This choice depends" -> "This choice is at the discretion of the dCDN and depends"
- section 4.2: "FCI.DelegationCredentials is not used to cope with" -> "The FCI.DelegationCredentials object does not address"
- section 4.2: "MI interface, uCDN" -> "MI, the uCDN"
- section 4.2: "The uCDN knowing the expiry times" -> "As the uCDN knows the expiry times"
- section 4.2: is the "must" in this section an RFC2119 "MUST"?  and is it further a "MUST" that the uCDN refresh the certs?
- section 5: i don't think the "must" is an RFC2119 "MUST"?  can we reword it?
- section 5: "the object, MI.DelegatedCredentials" -> "the MI.DelegatedCredentials object"
- section 5: i think it would be cleaner to define an object that has the two properties: delegated-credential and private-key, and give the delegated-credentials object a "Type: Array of <object_name> objects"
- section 5: "of the array of the property delegated-credentials" -> "of the property delegated-credentials array"
- section 5: the delegated-credential and private-key properties need a "Type: String" ?
- section 5: is the private-key base64 encoded?
- section 5: "If not used, we suppose that" -> "If not specified, it is assumed that the"
- section 5: "mechanism outside of this specification" -> "out of band mechanism"
- section 6: "We suppose" -> "It is assumed" (in multiple places)
- section 6, bullet 6: "CDNI the Metadata interface to push" -> "the MI to provide", since CDNI does not technically support metadata push
- section 7.1: the "Encoding" should reference section 5.0
- section 7.2: the "Encoding" should reference section 4.1
- section 8: "allow to provide" -> "enable providing"
- section 8: i think we need to say something about sending keys in metadata, e.g., though the keys are short lived, passing key material through the MI is dangerous and should be avoided
- section 10.1: i don't think the ACME RFCs or the ACME draft are normative.  i also don't think RFC8007 is a normative reference?

 

On Tue, Mar 7, 2023 at 5:53 AM Christoph Neumann <[e-mail]> wrote:

Hi all,

I submitted a new version of the internet draft covering delegated credentials.
The edits are minor and mostly address typos and reformulations.

Christoph

-----Original Message-----
From: CDNi <[e-mail]> On Behalf Of [e-mail]
Sent: mardi 7 mars 2023 11:46
To: [e-mail]
Cc: [e-mail]
Subject: [CDNi] I-D Action: draft-ietf-cdni-https-delegation-subcerts-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This Internet-Draft is a work item of the Content Delivery Networks Interconnection WG of the IETF.

        Title           : CDNI Metadata for Delegated Credentials
        Authors         : Frederic Fieau
                          Emile Stephan
                          Guillaume Bichot
                          Christoph Neumann
  Filename        : draft-ietf-cdni-https-delegation-subcerts-02.txt
  Pages           : 12
  Date            : 2023-03-07

Abstract:
   The delivery of content over HTTPS involving multiple CDNs raises
   credential management issues.  This document defines metadata in CDNI
   Control and Metadata interface to setup HTTPS delegation using
   Delegated Credentials from an Upstream CDN (uCDN) to a Downstream CDN
   (dCDN).



The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-cdni-https-delegation-subcerts/" target="_blank" rel="nofollow">https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-cdni-https-delegation-subcerts%2F&data=05%7C01%7Cchristoph.neumann%40broadpeak.tv%7C226365e4b0594e0378a208db1ef92e5d%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C638137827956490497%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=w0y%2FzqwicSXneLWBF3ywOoDYFNHdIAyQYohXwaLg79E%3D&reserved=0

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-cdni-https-delegation-subcerts-02" target="_blank" rel="nofollow">https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-cdni-https-delegation-subcerts-02&data=05%7C01%7Cchristoph.neumann%40broadpeak.tv%7C226365e4b0594e0378a208db1ef92e5d%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C638137827956490497%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=GEHIk7O6rRlEmpT9Vbv%2Fi50ut5MaQx%2FuK9I5nbtVI7U%3D&reserved=0

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-cdni-https-delegation-subcerts-02" target="_blank" rel="nofollow">https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-cdni-https-delegation-subcerts-02&data=05%7C01%7Cchristoph.neumann%40broadpeak.tv%7C226365e4b0594e0378a208db1ef92e5d%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C638137827956490497%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=4xqxIzt%2F2VCjBs2xMhSkytQR98rw8dHRwuFrAweUvsw%3D&reserved=0


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


_______________________________________________
CDNi mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/cdni" target="_blank" rel="nofollow">https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcdni&data=05%7C01%7Cchristoph.neumann%40broadpeak.tv%7C226365e4b0594e0378a208db1ef92e5d%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C638137827956646711%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=2eUetO7RzD7xJZfJJoxp6EaTcGFj3MRVo%2Fuhlpc5V3c%3D&reserved=0
Broadpeak, S.A. Registered offices at 15 rue Claude Chappe, Zone des Champs Blancs, 35510 Cesson-Sévigné, France | Rennes
Trade Register: 524 473 063
This e-mail and its attachments contain confidential information from Broadpeak S.A. and/or its affiliates (Broadpeak), which is intended only for the person to whom it is addressed.
If you are not the intended recipient of this email, please notify immediately the sender by phone or email and delete it. Any use of the information contained herein in any way, including, but not limited to, total or partial disclosure, reproduction, or dissemination, by persons other than the intended recipient(s) is prohibited, unless expressly authorized by Broadpeak. Broadpeak, S.A. and its affiliates respect privacy laws, and is committed to the protection of personal data. Emails and/or attachments thereof exchanged between us may include your personal data which may be processed by Broadpeak and/or its affiliates according to applicable privacy laws & regulations.
In compliance with Regulation (EU) 2016/679 (GDPR) and applicable implementation in local legislations, you can exercise at any time your rights of access, rectification or erasure of your personal data, as well as your rights to restriction, portability or object to the processing.
For such purpose, or to know more about how Broadpeak processes your personal data, you may contact Broadpeak by email [e-mail].
Local authority : Commission Nationale Informatique et Libertés (CNIL): 3 Place de Fontenoy - TSA 80715 - 75334 PARIS CEDEX 07 or http://www.cnil.fr/" target="_blank" rel="nofollow">www.cnil.fr
_______________________________________________
CDNi mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/cdni" target="_blank" rel="nofollow">https://www.ietf.org/mailman/listinfo/cdni

Broadpeak, S.A. Registered offices at 15 rue Claude Chappe, Zone des Champs Blancs, 35510 Cesson-Sévigné, France | Rennes
Trade Register: 524 473 063
This e-mail and its attachments contain confidential information from Broadpeak S.A. and/or its affiliates (Broadpeak), which is intended only for the person to whom it is addressed.
If you are not the intended recipient of this email, please notify immediately the sender by phone or email and delete it. Any use of the information contained herein in any way, including, but not limited to, total or partial disclosure, reproduction, or dissemination, by persons other than the intended recipient(s) is prohibited, unless expressly authorized by Broadpeak. Broadpeak, S.A. and its affiliates respect privacy laws, and is committed to the protection of personal data. Emails and/or attachments thereof exchanged between us may include your personal data which may be processed by Broadpeak and/or its affiliates according to applicable privacy laws & regulations.
In compliance with Regulation (EU) 2016/679 (GDPR) and applicable implementation in local legislations, you can exercise at any time your rights of access, rectification or erasure of your personal data, as well as your rights to restriction, portability or object to the processing.
For such purpose, or to know more about how Broadpeak processes your personal data, you may contact Broadpeak by email [e-mail].
Local authority : Commission Nationale Informatique et Libertés (CNIL): 3 Place de Fontenoy - TSA 80715 - 75334 PARIS CEDEX 07 or www.cnil.fr