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

Hi Christoph - Thank you for submitting the updated draft. Speaking as an
individual, I do support this work and in favor of adopting this draft (and
assuming subcert draft -
https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ - will progress
to an RFC)

The complimentary suggestion you outlined below might be workable from what
I see, that is,  dCDN advertise  MI.DelegatedCredentials through a
dedicated new FCI object named e.g., FCI.delegatedCredentials and the uCDN
when configuring the dCDN would then use an MI object (we can name it
MI.ConfDelegatedCredentials) to communicate the delegated credentials.

I do have some minor nits in the document:

sec 2.1: discribeq -> describes
sec 3: you can update reference to ACME drafts to RFC, namely RFC 8739 and
RFC 9115, specifically in the text
" There are currently Internet drafts within the TLS and ACME working
groups..."
sec 4: " With FCI the dCDN" -> "with FCI, the dCDN"

Thanks
Sanjay

On Tue, Feb 15, 2022 at 12:13 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://urldefense.proofpoint.com/v2/url?u=https-3A__fra01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.ietf.org-252Farchive-252Fid-252Fdraft-2Dfieau-2Dinterfaces-2Dhttps-2Ddelegation-2Dsubcerts-2D01.txt-26data-3D04-257C01-257CChristoph.Neumann-2540broadpeak.tv-257C31b30e046460458449b208d9ed24543b-257C0ebe44eac9c9438da0407e699f358ed4-257C0-257C0-257C637801562557792088-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3DQFaHDtkpfYfrjAYDDoIXmSdxmjt04eywDjttAdk4FLo-253D-26reserved-3D0&d=DwMFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=QjjUn69il_VLl2_ZtkdTjiIbmyAzWXLQRqnJxCj0t0wC_wR6DWLnpOfaE8JHmcRv&s=s3f77k5Em7VVOqCwNr8SRn6X03iC9nzC8lDsgEujKQ4&e=>
> Status:
> https://datatracker.ietf.org/doc/draft-fieau-interfaces-https-delegation-subcerts/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__fra01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdatatracker.ietf.org-252Fdoc-252Fdraft-2Dfieau-2Dinterfaces-2Dhttps-2Ddelegation-2Dsubcerts-252F-26data-3D04-257C01-257CChristoph.Neumann-2540broadpeak.tv-257C31b30e046460458449b208d9ed24543b-257C0ebe44eac9c9438da0407e699f358ed4-257C0-257C0-257C637801562557792088-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3D-252FPtgxFHH9o8Ze-252FwpdzoY-252FMRfUKqGhnA-252FcKNEmp7a5-252F4-253D-26reserved-3D0&d=DwMFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=QjjUn69il_VLl2_ZtkdTjiIbmyAzWXLQRqnJxCj0t0wC_wR6DWLnpOfaE8JHmcRv&s=g1N8j2Rc3vHnqvRqPH0IAVdFwM8twr_KCwzIhN1s9qs&e=>
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-fieau-interfaces-https-delegation-subcerts
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__fra01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdatatracker.ietf.org-252Fdoc-252Fhtml-252Fdraft-2Dfieau-2Dinterfaces-2Dhttps-2Ddelegation-2Dsubcerts-26data-3D04-257C01-257CChristoph.Neumann-2540broadpeak.tv-257C31b30e046460458449b208d9ed24543b-257C0ebe44eac9c9438da0407e699f358ed4-257C0-257C0-257C637801562557792088-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3DWn1-252B4HCdvDzpfYTK3ZEyXnS3Rwi-252BKn6hvusuA02hkqA-253D-26reserved-3D0&d=DwMFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=QjjUn69il_VLl2_ZtkdTjiIbmyAzWXLQRqnJxCj0t0wC_wR6DWLnpOfaE8JHmcRv&s=BsUD_gxsSYpcNVymSV9RKdwwHoB5Cdda0odiSfOf-K4&e=>
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-fieau-interfaces-https-delegation-subcerts-01
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__fra01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.ietf.org-252Frfcdiff-253Furl2-253Ddraft-2Dfieau-2Dinterfaces-2Dhttps-2Ddelegation-2Dsubcerts-2D01-26data-3D04-257C01-257CChristoph.Neumann-2540broadpeak.tv-257C31b30e046460458449b208d9ed24543b-257C0ebe44eac9c9438da0407e699f358ed4-257C0-257C0-257C637801562557792088-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3DcG1nvUUcogl7El1rhkA14b1Lltcca-252FpDazw8JTSj6PA-253D-26reserved-3D0&d=DwMFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=QjjUn69il_VLl2_ZtkdTjiIbmyAzWXLQRqnJxCj0t0wC_wR6DWLnpOfaE8JHmcRv&s=_h7Jzulev3K3_KSLtGrsLxdKZlZOwbIt0pkisosIldY&e=>
>
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__fra01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.ietf.org-252Fmailman-252Flistinfo-252Fcdni-26data-3D04-257C01-257CChristoph.Neumann-2540broadpeak.tv-257C31b30e046460458449b208d9ed24543b-257C0ebe44eac9c9438da0407e699f358ed4-257C0-257C0-257C637801562557792088-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3Db1aEa-252FVaj-252Fkyzf8zUJGCX8cUwfWKezIdQLWHA41uMlE-253D-26reserved-3D0&d=DwMFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=QjjUn69il_VLl2_ZtkdTjiIbmyAzWXLQRqnJxCj0t0wC_wR6DWLnpOfaE8JHmcRv&s=6f-Vb6IwmHwLh63CJhtn2plNPPirspfcJO7akno7p70&e=>
>
> _______________________________________________
> CDNi mailing list
> CDNi@ietf.org
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_cdni&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=QjjUn69il_VLl2_ZtkdTjiIbmyAzWXLQRqnJxCj0t0wC_wR6DWLnpOfaE8JHmcRv&s=r5k5X_b-klPZtRJY_mFktNZ1ofc8eLRXweTh-GMMyBI&e=
>