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

"Mishra, Sanjay" <sanjay.mishra@verizon.com> Fri, 29 July 2022 13:52 UTC

Return-Path: <sanjay.mishra@verizon.com>
X-Original-To: cdni@ietfa.amsl.com
Delivered-To: cdni@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7CBAC15A72A for <cdni@ietfa.amsl.com>; Fri, 29 Jul 2022 06:52:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.511
X-Spam-Level:
X-Spam-Status: No, score=-4.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BITCOIN_YOUR_INFO=1.997, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, PDS_BTC_ID=0.498, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=verizon.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6-NuPNnbWJm for <cdni@ietfa.amsl.com>; Fri, 29 Jul 2022 06:52:28 -0700 (PDT)
Received: from mx0b-0024a201.pphosted.com (mx0b-0024a201.pphosted.com [148.163.153.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27A16C15A734 for <cdni@ietf.org>; Fri, 29 Jul 2022 06:52:04 -0700 (PDT)
Received: from pps.filterd (m0104974.ppops.net [127.0.0.1]) by mx0a-0024a201.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 26TBC8dg029373 for <cdni@ietf.org>; Fri, 29 Jul 2022 09:52:02 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.com; h=mime-version : references : in-reply-to : from : date : message-id : subject : to : cc : content-type; s=corp; bh=JS5aUITG8lycQpLO3Gw8UdrPpvIrHq1jgHYphVTCbmU=; b=qaEilrbfuSaY5Re41cVWXT2aXKl3f6QScwNr5zrbktYx1eK3HK5dxNpp+EiUnooxSOQt ljXvs6Ve0hWOxK4pWhK+UGtA81+8aEaiph7cu7e/p86dOmt2K5gDqe+GJsbv6QdDF2Gl GTmK94RlbSaGf2X/gdv2sW7F1w7pbrsLEyU=
Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by mx0a-0024a201.pphosted.com (PPS) with ESMTPS id 3hm3mtngpf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for <cdni@ietf.org>; Fri, 29 Jul 2022 09:52:01 -0400
Received: by mail-qk1-f199.google.com with SMTP id de4-20020a05620a370400b006a9711bd9f8so3583068qkb.9 for <cdni@ietf.org>; Fri, 29 Jul 2022 06:52:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JS5aUITG8lycQpLO3Gw8UdrPpvIrHq1jgHYphVTCbmU=; b=tmlOqtVVev8CdK6t1rMtoJYv/AAbV6TsSc5RZWp5GN7R/74xorRIfWZFbg36+ft4g4 hJC2pw/iwtBtks3VwdHds5i93Id4sWbfF9saQuV2SY1FfXaYwFh/a2qwyJINow7cvsK2 9gykokSl1XWWOfJIHKui03oYrV/U3+oJivuiRdP3GURAxPRJMcbwu25clioVKBn9NNuH nOz/s1EFDMXXQ5ALAlAK4nofe/56Q0yceQuJEv6fsGj7GekO5Yx8ObYTSL4DnUecO/nH 9fSJwx7NqNmQm3MIdf8Uf7vlCBSf+Rb1ujv4Idk4HKluTMtNEqm5sREmfIDo5aeF4mJq piSQ==
X-Gm-Message-State: AJIora8Xnp1FS1US5PjmdW7pP41WdXEvhmmfUV7k4z7n+kIKNsnfYl5v 9q4MQ6/FDni184ZNg3toCS4XhtySuqu6Glr7NXQmSqTV7gQncCAuOUKlQNbPwAwvE5GquiKyFmY 0ORM6LwY99nk1s/xKXgA=
X-Received: by 2002:a05:620a:4891:b0:6b5:e281:afdf with SMTP id ea17-20020a05620a489100b006b5e281afdfmr2713830qkb.249.1659102715163; Fri, 29 Jul 2022 06:51:55 -0700 (PDT)
X-Google-Smtp-Source: AGRyM1tx4lPtf7q0X/Tf3P9RAyaU16qUQ8w/xNZNw8fngMaX4ZEw6P2sF99GdigFy0X/t2hlaHI861RjDWrYuMAI5nc=
X-Received: by 2002:a05:620a:4891:b0:6b5:e281:afdf with SMTP id ea17-20020a05620a489100b006b5e281afdfmr2713800qkb.249.1659102714509; Fri, 29 Jul 2022 06:51:54 -0700 (PDT)
MIME-Version: 1.0
References: <164321280803.8419.9611477208216008922@ietfa.amsl.com> <PRAPR10MB5273E44C9F88EBE2882AEBC08F209@PRAPR10MB5273.EURPRD10.PROD.OUTLOOK.COM> <CAMrHYE0TaHxBD7PH7Gc36T6zJWHo4kWQxHCDR4s_mWw0C2Ss1A@mail.gmail.com> <PRAPR10MB5273B098872588130F6A47E08F349@PRAPR10MB5273.EURPRD10.PROD.OUTLOOK.COM> <CAMrHYE0bXS4qvGwD49t_2QrCwRt4f9T+fPbFi-w-n69xfkYtUQ@mail.gmail.com> <AM9PR10MB41529F2F26BC09DCDD646FD98F819@AM9PR10MB4152.EURPRD10.PROD.OUTLOOK.COM> <CAMrHYE26KaOBZ14PoemreXXoRhCNjmyf3EMx8e9hwwsFaJgvVg@mail.gmail.com>
In-Reply-To: <CAMrHYE26KaOBZ14PoemreXXoRhCNjmyf3EMx8e9hwwsFaJgvVg@mail.gmail.com>
From: "Mishra, Sanjay" <sanjay.mishra@verizon.com>
Date: Fri, 29 Jul 2022 09:51:43 -0400
Message-ID: <CA+EbDtBqFkvM6=M+MVLkKLNjiEF6s+CUaeyxXeM18a8ueVjVng@mail.gmail.com>
To: Christoph Neumann <Christoph.Neumann@broadpeak.tv>
Cc: "cdni@ietf.org" <cdni@ietf.org>, Kevin Ma <kevin.j.ma.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000f1d59b05e4f1f335"
X-mailroute: internal
X-Proofpoint-GUID: YC4blJD-2P27tXX5pef48TVru-fjxqT-
X-Proofpoint-ORIG-GUID: YC4blJD-2P27tXX5pef48TVru-fjxqT-
Archived-At: <https://mailarchive.ietf.org/arch/msg/cdni/j-cabaQB1-GksrNBEoDW5fdpe2Q>
Subject: Re: [CDNi] [E] Re: FW: New Version Notification for draft-fieau-interfaces-https-delegation-subcerts-01.txt
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" <cdni.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cdni>, <mailto:cdni-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cdni/>
List-Post: <mailto:cdni@ietf.org>
List-Help: <mailto:cdni-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cdni>, <mailto:cdni-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jul 2022 13:52:32 -0000

Hi Christoph - Leaving aside the discussions on using FCI,  I have some
minor nits to the document:

1. Sec 4: Remove the extra space -> "MI.DelegatedCredentials ."
2. Sec 4.2: use "a" instead of "an" -> "to an uCDN"
3. Sec 5: Remove "." at the end ->"Description: Array of delegated
credentials."
4. Comment #3 applies to other parts of the document for similar cases.

Thanks
Sanjay



On Sat, Jul 9, 2022 at 11:12 AM Kevin Ma <kevin.j.ma.ietf@gmail.com> 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 <
> 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://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-3D05-257C01-257CChristoph.Neumann-2540broadpeak.tv-257C8b13163efecf4c81e0a708da5dcad7d5-257C0ebe44eac9c9438da0407e699f358ed4-257C0-257C0-257C637925423647998561-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C3000-257C-257C-257C-26sdata-3DRgRHcbvAH1wNsTG3WVxQYkKPBqQJyTLh0uWiBdj8j-252B4-253D-26reserved-3D0&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=zVmgyNnD1nB8NbVjrxspZQ90lEBUUWpNY4ZNoHvzZA3J519hB0DA16_1MlOOAG2n&s=P5-MoAPdGG_EESFudyPxCJyn5WBDUy620M3DeQG7ZgQ&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-3D05-257C01-257CChristoph.Neumann-2540broadpeak.tv-257C8b13163efecf4c81e0a708da5dcad7d5-257C0ebe44eac9c9438da0407e699f358ed4-257C0-257C0-257C637925423647998561-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C3000-257C-257C-257C-26sdata-3DBtLMbicItqAPo3gTHkTG20eVpu7LmnHLT3i5uYU5Vig-253D-26reserved-3D0&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=zVmgyNnD1nB8NbVjrxspZQ90lEBUUWpNY4ZNoHvzZA3J519hB0DA16_1MlOOAG2n&s=p99vi6pSNpY7BXTH75IQAbCp9zye0VXBACAYkBo-ujg&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-3D05-257C01-257CChristoph.Neumann-2540broadpeak.tv-257C8b13163efecf4c81e0a708da5dcad7d5-257C0ebe44eac9c9438da0407e699f358ed4-257C0-257C0-257C637925423647998561-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C3000-257C-257C-257C-26sdata-3DCb9Za4AgjXJWj5wwiDTjQo6Vvq5Z-252Fd-252BXWqWvPpHdl-252Bk-253D-26reserved-3D0&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=zVmgyNnD1nB8NbVjrxspZQ90lEBUUWpNY4ZNoHvzZA3J519hB0DA16_1MlOOAG2n&s=GYYG4jOA3ZvT64g_XGDy8xISl468vFBxnZiRJDVQQRw&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-3D05-257C01-257CChristoph.Neumann-2540broadpeak.tv-257C8b13163efecf4c81e0a708da5dcad7d5-257C0ebe44eac9c9438da0407e699f358ed4-257C0-257C0-257C637925423647998561-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C3000-257C-257C-257C-26sdata-3DPntkcVDGoNnFsmaiGeG7zuuMAtCEjs8zja05F4HW5Mk-253D-26reserved-3D0&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=zVmgyNnD1nB8NbVjrxspZQ90lEBUUWpNY4ZNoHvzZA3J519hB0DA16_1MlOOAG2n&s=g0ODNCAor8hAzXQS6trJsUA6li3xmD74lFog_mImsqc&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-3D05-257C01-257CChristoph.Neumann-2540broadpeak.tv-257C8b13163efecf4c81e0a708da5dcad7d5-257C0ebe44eac9c9438da0407e699f358ed4-257C0-257C0-257C637925423647998561-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C3000-257C-257C-257C-26sdata-3Dvl2YIYd2avXU-252FLCVOXSqVxJV-252BG4ByhH4e4p59R1ao48-253D-26reserved-3D0&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=zVmgyNnD1nB8NbVjrxspZQ90lEBUUWpNY4ZNoHvzZA3J519hB0DA16_1MlOOAG2n&s=7vD4FDlE5Eth18B-LsrJwTy98W1txkmTFBYXImzKfYY&e=>
>>
>> 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
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.cnil.fr&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=zVmgyNnD1nB8NbVjrxspZQ90lEBUUWpNY4ZNoHvzZA3J519hB0DA16_1MlOOAG2n&s=gRvr-ZuQ3fuV92DeqDdh0gcWUuXD2ETF7aufc6trHIU&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=zVmgyNnD1nB8NbVjrxspZQ90lEBUUWpNY4ZNoHvzZA3J519hB0DA16_1MlOOAG2n&s=uIz4Rbth2FOfJDVDqhxZ0Nh1FqVWUNgUvcnKQmS5Dq4&e=
>