Re: [CDNi] FW: New Version Notification for draft-fieau-interfaces-https-delegation-subcerts-01.txt

[Kevin Ma <[e-mail]>]

Hi Christoph,

  Sorry for the delayed response.  The Metadata interface uses standard
HTTP caching mechanisms to control the dCDN's usage of the metadata.  There
is nothing that prevents the uCDN from setting the cache control to a very
short duration or none at all.  It's a bit of an end around on the original
intent of the Metadata interface, but it would work?

thanx!

--  Kevin J. Ma

On Wed, Aug 17, 2022 at 5:22 AM Christoph Neumann <
[e-mail]> wrote:

> Hi Kevin, all,
>
>
>
> The mechanism you are describing would be ideal, i.e., the dCDN simply
> requests metadata object whenever required and the uCDN serves the metadata
> accordingly.
>
> However, I’m not quite sure how you would implement that with CDNI, i.e.,
> which API or interface would allow the dCDN to request metadata as needed.
>
> Do you have a specific mechanism in mind?
>
>
>
> Christoph
>
>
>
> *From:* Kevin Ma <[e-mail]>
> *Sent:* vendredi 29 juillet 2022 16:11
> *To:* Christoph Neumann <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [CDNi] FW: New Version Notification for
> draft-fieau-interfaces-https-delegation-subcerts-01.txt
>
>
>
> Hi Christoph,
>
>
>
>   I was wondering if we could get away with just a single metadata
> object?  If there is no expectation that the credentials read will persist
> for any length of time, could the dCDN just request the metadata object and
> use whatever is returned?  There is still the question of how many to
> include in the payload, but if we let the uCDN decide how many, the dCDN
> could just keep asking until it got as many credentials as it wanted (which
> may all be the same or could be different).  It would be implementation
> specific on how the uCDN responds to the metadata request, i.e., how the
> uCDN generates that specific piece of metadata, which is a don't care for
> interoperability?  Now, the uCDN wouldn't know if it was asking because it
> needed more creds or because it rebooted and needed to refresh its
> metadata, but with a short-lived cred, I'm not sure it matters?
>
>
>
> thanx.
>
>
>
> --  Kevin J. Ma
>
>
>
>
>
> On Sat, Jul 9, 2022 at 11:11 AM Kevin Ma <[e-mail]>
> wrote:
>
> Hi Christoph,
>
>
>
>   Thanks for the response.  Some additional thoughts:
>
>
>
> > The maximum expiration time of a delegated credential is 7 days. If we
> stay in this order of magnitude (i.e.  a credential lasts a few days), FCI
> could do the job
>
> > So bottom line: FCI could work, but it we will not be very dynamic
> (e.g., if credentials that last a few hours).
>
>
>
> Do we have any data on whether implementers would want really short
> durations?  It would be nice to be data driven here, if possible.  I can
> certainly see the perceived value of rotating as quickly as possible as it
> reduces the potential for criminal enterprise; I could also see using the
> cert expiration in a lazy customer managed key revocation scheme.  Are
> there specific use cases you have in mind?
>
>
>
> > My proposal: Maybe we could start with the FCI based mechanism, knowing
> that it will have limitations in terms of dynamicity, and in the meantime
> work on how to specify/tackle more dynamic delegated credential fetching
> mechanisms
>
>
>
> (As an individual) If we think we need higher dynamicity than FCI can
> provide, then I would just skip to just trying to figure that out.
>
>
>
> (As a chair) I would be interested in hearing what others in the WG think.
>
>
>
> thanx!
>
>
>
> --  Kevin J. Ma
>
>
>
>
>
> On Tue, Jul 5, 2022 at 4:42 AM Christoph Neumann <
> [e-mail]> wrote:
>
> Hi Kevin,
>
>
>
> The interface we are proposing to fetch the delegated credentials is
> indeed very simple. Only a req/resp on an URL.
>
> If I understand you correctly you think this is still outside the scope of
> CDNI.
>
> But I’m not quite sure where to define it elsewhere (also because the
> mechanism is quite simple).
>
> I could not find any other existing standard our mechanism that would
> allow us to fetch the delegated credentials.
>
>
>
> Regarding FCI:
>
> The maximum expiration time of a delegated credential is 7 days. If we
> stay in this order of magnitude (i.e.  a credential lasts a few days), FCI
> could do the job: the dCDN monitors the number of credentials that expires
> in the next day, and ask for new ones by announcing this number of required
> delegated credentials via an FCI object (the uCDN will very probably query
> the FCI within the next day).
>
> However, before the first configuration of the dCDN from the uCDN the dCDN
> does not really know how many servers will be used for the uCDN services
> and contents and consequently does not really know how many delegated
> credentials may be needed. I.e., the “first” FCI announcement will be
> something like the number of caching servers available by the dCDN (or the
> number of servers per footprint).
>
>
>
> So bottom line: FCI could work, but it we will not be very dynamic (e.g.,
> if credentials that last a few hours). If we go for FCI, the only MI object
> that would stay is the MI.DelegatedCredentials.
>
> If we want a more dynamic mechanism, we need a simple req/resp interface.
>
> My proposal: Maybe we could start with the FCI based mechanism, knowing
> that it will have limitations in terms of dynamicity, and in the meantime
> work on how to specify/tackle more dynamic delegated credential fetching
> mechanisms (and try to figure out where the right place is to specify
> these).
>
>
>
> Christoph
>
>
>
>
>
> *From:* Kevin Ma <[e-mail]>
> *Sent:* lundi 4 juillet 2022 16:38
> *To:* Christoph Neumann <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [CDNi] FW: New Version Notification for
> draft-fieau-interfaces-https-delegation-subcerts-01.txt
>
>
>
> Hi Christoph,
>
>
>
>   Adding a new interface to CDNI is definitely out of scope of the current
> charter, and I'm not sure that it really makes sense as part of CDNI.  It
> would be a fairly basic req/resp, so from that perspective, I understand
> why the proposal went with metadata as opposed to an interface.
>
>
>
>   The FCI proposal for advertising how many certs are required is
> interesting.  My one concern (other than security) would be about the
> load.  How often does the required number of subcerts change, and how often
> do the subcerts themselves change and need to be re-retrieved?
>
>
>
>   I think that if an existing interface was already specified for
> retrieving the subcert data, having the metadata convey just a pointer to
> that interface would be much cleaner.  But, the metadata is expected to be
> somewhat ephemeral, so I guess there isn't a reason the data couldn't be
> represented/conveyed as metadata.  My primary concern is still the fact
> that key material is being passed, and that potentially opens up a can of
> worms from a security perspective.
>
>
>
>   I think the discussion of these design choices could certainly be done
> as part of a working group document.  We can try to get a secdir opinion.
>
>
>
>   Are you leaning in a particular direction?
>
>
>
> thanx!
>
>
>
> --  Kevin J. Ma
>
>
>
>
>
>
>
> On Tue, Feb 15, 2022 at 12:12 PM Christoph Neumann <
> [e-mail]> wrote:
>
> Hi Kevin,
>
>
>
> Thanks for your comments.
>
>
>
> MI.DelegatedCredentials may or may not be part of the Metadata Interface
> (MI) described in RFC8006 (In theory, it should not part of it, I agree
> with you here, at least as it is in the current proposal) but it should be
> somehow part of CDNi .
>
>
>
> The way to retrieve MI.DelegatedCredentials as defined in the proposal is
> a bit particular. As only the dCDN knows how many delegated credentials
> (MI.DelegatedCredentials) it needs , it must fetch/request as many
> MI.DelegatedCredentials as required. On the other side, the uCDN may decide
> to respond with different or identical MI.DelegatedCredentials payloads.  I
> also note that there is an error in the current text which can be a bit
> confusing: page 4: second paragraph, we should read:
>
>
>
> “The MI.ConfDelegatedCredentials contains a URI (credentials-location-uri)
> that allows the dCDN to download delegated credentials. The expected
> behavior of this URI is that each time that the dCDN accesses this URI a
> *MI.DelegatedCredentials* object containing a delegated credential with
> its corresponding private key is delivered.”
>
>
>
> I reckon this workflow is not typical to RFC8006 which would favor a
> separate/new interface for describing that process. This drives to the
> possibility of only adding MI.ConfDelegatedCredentials to MI (RFC8006) .
> However, if we cannot describe the protocol to fetch the
> MI.DelegatedCredentials object and its payload structure (i.e. private key
> +  DelegatedCredential as defined in [I-D.ietf-tls-subcerts]) as part of
> CDNi, the MI.ConfDelegatedCredentials becomes pointless. Ideally, we should
> generate a new CDNi interface dedicated to subcert describing the
> MI.DelegatedCredentials payload and the protocol between the uCDN and dCDN.
>
>
>
> There is however a possible complementary solution to this. The dCDN may
> advertise about supporting the subcert capability through a dedicated new
> FCI object named e.g., FCI.delegatedCredentials. The latter would indicate
> the number of required [different] delegated credential objects. The uCDN
> when configuring the dCDN would then use an MI object (we can name it
> MI.ConfDelegatedCredentials) to communicate the delegated credentials (i.e.
> private key +  DelegatedCredential) via an array of MI objects. I.e,
> MI.ConfDelegatedCredentials would be defines as:
>
> Property: array of MI.DelegatedCredentials objects.
>
>
>
> The MI.ConfDelegatedCredentials object would have to be
> updated/communicated by the uCDN each time any or all of the delegated
> credential’s validity is going to expired and/or each time a new
> FCI.delegatedCredentials object is updated/created.  With that way to do we
> stay compatible with the RFC 8006 spirit, do not need an extra CDNi
> interface and provides a complete/coherent mechanism for configuring the
> dCDN with the delegated credentials.
>
>
>
> Any thoughts on this latter proposal?
>
>
>
> Christoph
>
>
>
>
>
> *From:* Kevin Ma <[e-mail]>
> *Sent:* vendredi 11 février 2022 07:04
> *To:* Christoph Neumann <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [CDNi] FW: New Version Notification for
> draft-fieau-interfaces-https-delegation-subcerts-01.txt
>
>
>
> Hi Christoph,
>
>
>
>   (As Chair) I think it is fair to call for adoption of the draft, since
> it was just a split, though I think it would be good to reaffirm that the
> WG has an appetite for this work, since it has been a while since we agreed
> to adopt the original draft.  If folks could please confirm on the list
> that they believe TLS subcerts are still useful to support in CDNI, that
> would be great.
>
>
>
>   (As an Individual) The actual requirements to support TLS subcerts seem
> pretty minimal (see my comments on the draft below).  Assuming the TLS
> subcerts draft is on track to be published (I see that the AD recently
> requested a revision), I am in favor of adopting the draft.
>
>
>
> thanx!
>
>
>
> --  Kevin J. Ma
>
>
>
> comments:
>
> ---------
>
>
>
> - does "MI.DelegatedCredentials" need to be defined in this draft?  It is
> not transferred via the MI?  is "MI.ConfDelegatedCredentials" sufficient
> for CDNI's purposes?
>
> - in the call flows, it looks like only steps 3 and 4
> for "MI.ConfDelegatedCredentials" are related to CDNI?  perhaps we could
> make that even more clear, so that there aren't a lot of questions about
> the security of what's being proposed?
>
> - the draft needs security and privacy sections (the security section gets
> easier if we are clear that the draft only really defines
> the "MI.ConfDelegatedCredentials" object which is a simple link and
> subcerts does all the heavy security lifting; the privacy section gets
> easier if we remove MI.DelegatedCredentials and let the subvert draft deal
> with passing around a "private key")
>
>
>
>
>
>
>
> On Wed, Jan 26, 2022 at 11:33 AM Christoph Neumann <
> [e-mail]> wrote:
>
> Dear all,
>
> I submitted a new version of the draft on CDNI Metadata for Delegated
> Credentials (see below).
>
> As discussed and agreed in the CDNi working group, this draft resulted
> from splitting the original CDNi extensions for HTTPS delegation draft
> (draft-ietf-cdni-interfaces-https-delegation) into two:
> - one that handles STAR/ACME type delegation, which remained in
> draft-ietf-cdni-interfaces-https-delegation
> - one that handles delegated credentials, described in
> draft-fieau-interfaces-https-delegation-subcerts
>
> The delegated credentials draft is currently handled as an individual
> submission, and I would like to ask for adoption of this draft in the CDNi
> working group.
>
> Further, feel free to comment the draft on the mailing list.
>
> Best regards,
> Christoph
>
> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: mercredi 26 janvier 2022 17:00
> To: Christoph Neumann <[e-mail]>; Emile Stephan <
> [e-mail]>; Frederic Fieau <[e-mail]>;
> Guillaume Bichot <[e-mail]>; Stephan Emile <
> [e-mail]>
> Subject: New Version Notification for
> draft-fieau-interfaces-https-delegation-subcerts-01.txt
>
>
> A new version of I-D,
> draft-fieau-interfaces-https-delegation-subcerts-01.txt
> has been successfully submitted by Christoph Neumann and posted to the
> IETF repository.
>
> Name:           draft-fieau-interfaces-https-delegation-subcerts
> Revision:       01
> Title:          CDNI Metadata for Delegated Credentials
> Document date:  2022-01-26
> Group:          Individual Submission
> Pages:          9
> URL:
> https://www.ietf.org/archive/id/draft-fieau-interfaces-https-delegation-subcerts-01.txt
> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-fieau-interfaces-https-delegation-subcerts-01.txt&data=05%7C01%7CChristoph.Neumann%40broadpeak.tv%7C41dd13281410447ea86208da716c303d%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637947006743639821%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=%2F0yP129mhL2VXmmfkcvsJrBzGpzg4LYAPi1TcSg4IuQ%3D&reserved=0>
> Status:
> https://datatracker.ietf.org/doc/draft-fieau-interfaces-https-delegation-subcerts/
> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-fieau-interfaces-https-delegation-subcerts%2F&data=05%7C01%7CChristoph.Neumann%40broadpeak.tv%7C41dd13281410447ea86208da716c303d%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637947006743639821%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=h5VZmwTSeetBgSETL%2F3iZz2S5eQfHRyamzE479ssIyM%3D&reserved=0>
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-fieau-interfaces-https-delegation-subcerts
> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-fieau-interfaces-https-delegation-subcerts&data=05%7C01%7CChristoph.Neumann%40broadpeak.tv%7C41dd13281410447ea86208da716c303d%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637947006743639821%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=1%2F%2FdJRbUjXiEi5y7SfhXXLqP4A4Mrxvk%2FBE1QF7XRI4%3D&reserved=0>
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-fieau-interfaces-https-delegation-subcerts-01
> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-fieau-interfaces-https-delegation-subcerts-01&data=05%7C01%7CChristoph.Neumann%40broadpeak.tv%7C41dd13281410447ea86208da716c303d%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637947006743639821%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=hLVIhtyw3WfDRSnBOso7m%2Bc77y6%2Bm9LiZgt%2FmNMi%2BJ8%3D&reserved=0>
>
> 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 Secretariat
>
>
> _______________________________________________
> CDNi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cdni
> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcdni&data=05%7C01%7CChristoph.Neumann%40broadpeak.tv%7C41dd13281410447ea86208da716c303d%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637947006743639821%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=KrXKne126Mx6zQtzgjrSwKU4mdn3Wy0e4vA%2BDC3%2ByYM%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 www.cnil.fr
> <https://fra01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cnil.fr%2F&data=05%7C01%7CChristoph.Neumann%40broadpeak.tv%7C41dd13281410447ea86208da716c303d%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637947006743639821%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=0L%2BsZ7yQ3eZopW6mOCT8O9EABLh3vYF37r7eKCGPxGU%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 www.cnil.fr
>