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

[Christoph Neumann <[e-mail]>]

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]<mailto:[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]<mailto:[e-mail]>> On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: mardi 7 mars 2023 11:46
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[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://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<https://datatracker.ietf.org/doc/draft-ietf-cdni-https-delegation-subcerts/>

There is also an htmlized version available at:
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<https://datatracker.ietf.org/doc/html/draft-ietf-cdni-https-delegation-subcerts-02>

A diff from the previous version is available at:
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<https://author-tools.ietf.org/iddiff?url2=draft-ietf-cdni-https-delegation-subcerts-02>


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


_______________________________________________
CDNi mailing list
[e-mail]<mailto:[e-mail]>
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<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]<mailto:[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<http://www.cnil.fr/>
_______________________________________________
CDNi mailing list
[e-mail]<mailto:[e-mail]>
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