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

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 <
Christoph.Neumann@broadpeak.tv> 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 <kevin.j.ma.ietf@gmail.com>
> *Sent:* lundi 4 juillet 2022 16:38
> *To:* Christoph Neumann <Christoph.Neumann@broadpeak.tv>
> *Cc:* cdni@ietf.org
> *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 <
> Christoph.Neumann@broadpeak.tv> 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 <kevin.j.ma.ietf@gmail.com>
> *Sent:* vendredi 11 février 2022 07:04
> *To:* Christoph Neumann <Christoph.Neumann@broadpeak.tv>
> *Cc:* cdni@ietf.org
> *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 <
> Christoph.Neumann@broadpeak.tv> 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: internet-drafts@ietf.org <internet-drafts@ietf.org>
> Sent: mercredi 26 janvier 2022 17:00
> To: Christoph Neumann <christoph.neumann@broadpeak.tv>; Emile Stephan <
> emile.stephan@orange.com>; Frederic Fieau <frederic.fieau@orange.com>;
> Guillaume Bichot <guillaume.bichot@broadpeak.tv>; Stephan Emile <
> emile.stephan@orange.com>
> 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%7C8b13163efecf4c81e0a708da5dcad7d5%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637925423647998561%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RgRHcbvAH1wNsTG3WVxQYkKPBqQJyTLh0uWiBdj8j%2B4%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%7C8b13163efecf4c81e0a708da5dcad7d5%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637925423647998561%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=BtLMbicItqAPo3gTHkTG20eVpu7LmnHLT3i5uYU5Vig%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%7C8b13163efecf4c81e0a708da5dcad7d5%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637925423647998561%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Cb9Za4AgjXJWj5wwiDTjQo6Vvq5Z%2Fd%2BXWqWvPpHdl%2Bk%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%7C8b13163efecf4c81e0a708da5dcad7d5%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637925423647998561%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=PntkcVDGoNnFsmaiGeG7zuuMAtCEjs8zja05F4HW5Mk%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
> CDNi@ietf.org
> 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%7C8b13163efecf4c81e0a708da5dcad7d5%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637925423647998561%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=vl2YIYd2avXU%2FLCVOXSqVxJV%2BG4ByhH4e4p59R1ao48%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 privacy@broadpeak.tv.
> Local authority : Commission Nationale Informatique et Libertés (CNIL): 3
> Place de Fontenoy - TSA 80715 - 75334 PARIS CEDEX 07 or www.cnil.fr
>