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= >
- [CDNi] FW: New Version Notification for draft-fie… Christoph Neumann
- Re: [CDNi] FW: New Version Notification for draft… Kevin Ma
- Re: [CDNi] FW: New Version Notification for draft… Christoph Neumann
- Re: [CDNi] [E] Re: FW: New Version Notification f… Mishra, Sanjay
- Re: [CDNi] FW: New Version Notification for draft… Kevin Ma
- Re: [CDNi] FW: New Version Notification for draft… Christoph Neumann
- Re: [CDNi] FW: New Version Notification for draft… Kevin Ma
- Re: [CDNi] [E] Re: FW: New Version Notification f… Mishra, Sanjay
- Re: [CDNi] FW: New Version Notification for draft… Kevin Ma
- Re: [CDNi] [E] Re: FW: New Version Notification f… Kevin Ma
- Re: [CDNi] FW: New Version Notification for draft… Christoph Neumann
- Re: [CDNi] FW: New Version Notification for draft… Kevin Ma
- Re: [CDNi] FW: New Version Notification for draft… Christoph Neumann
- Re: [CDNi] FW: New Version Notification for draft… Kevin J. Ma