Subject: Re: [CDNi] TR: New Version Notification for draft-fieau-cdni-interfaces-https-delegation-02.txt

From: Kevin Ma <[email-masked]>
Date: Thu, 16 Nov 2017 06:57:38 -0500

Hi All,

  As we discussed in the CDNI Session today, the chairs have begun looking
at WG rechartering and would like to gauge general WG interest in the HTTPS
delegation stuff on which Frederic has been working.

  We encourage you to read the updated draft and send mail to the list if
you have comments, questions, concerns, or just a thumbs up/down on the
proposals.

thanx!

--  Kevin and Francois

On Mon, Oct 30, 2017 at 3:33 PM, <[email-masked]> wrote:

> Dear all,
>
> I've just posted an update of the draft that proposes an extension to
> support  HTTPS delivery delegation in CDNI.
>
> Regards,
> Frédéric
>
>
>
> A new version of I-D, draft-fieau-cdni-interfaces-https-delegation-02.txt
> has been successfully submitted by Frederic Fieau and posted to the IETF
> repository.
>
> Name:           draft-fieau-cdni-interfaces-https-delegation
> Revision:       02
> Title:          CDNI extensions for HTTPS delegation
> Document date:  2017-10-30
> Group:          Individual Submission
> Pages:          13
> URL:            https://www.ietf.org/internet-drafts/draft-fieau-cdni-
> interfaces-https-delegation-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-fieau-cdni-
> interfaces-https-delegation/
> Htmlized:       https://tools.ietf.org/html/draft-fieau-cdni-interfaces-
> https-delegation-02
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-fieau-cdni-
> interfaces-https-delegation-02
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-fieau-cdni-
> interfaces-https-delegation-02
>
> Abstract:
>    The delivery of content over HTTPS involving multiple CDNs raises
>    credential management issues.  This document proposes extensions in
>    CDNI Control and Metadata interfaces to setup HTTPS delegation from a
>    uCDN to a dCDN.
>
>
>
>
> ____________________________________________________________
> _____________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni
>

---

From: Kevin Ma <[email-masked]>
Date: Thu, 16 Nov 2017 07:08:01 -0500

Hi Frederic,

  (As an individual) As I mentioned in the session today, I don't see the
advantage of the proposal to change the metadata interface to have top
level metadata objects that contain lists of (sub)paths, as opposed to the
RFC8006 method of listing all metadata that apply to a given (sub)path.
Though possibly easier for someone who only cares about that one piece of
metadata, I don't think that it scales as well to supporting the full set
of content delivery metadata for the CDN.  If there are specific reasons
that it couldn't work using the existing metadata structure, it would be
good to highlight that, as well as provided a more concrete definition of
where these new objects would sit in the structural metadata hierarchy,
what the serialization impact of that might be, and how backwards
compatibility with RFC8006 might be affected.

  As a more general question: do we have any sense of whether or not folks
are using or planning to use any of the proposed delegation methods (ACME
STAR, subcerts, etc.); and/or do we have a feel for which methods might be
most useful to CDNs?

thanx.

--  Kevin J. Ma

On Thu, Nov 16, 2017 at 6:57 AM, Kevin Ma <[email-masked]> wrote:

>> URL:            https://www.ietf.org/internet-
>> drafts/draft-fieau-cdni-interfaces-https-delegation-02.txt
>> Status:         https://datatracker.ietf.org/
>> doc/draft-fieau-cdni-interfaces-https-delegation/
>> Htmlized:       https://tools.ietf.org/html/d
>> raft-fieau-cdni-interfaces-https-delegation-02
>> Htmlized:       https://datatracker.ietf.org/
>> doc/html/draft-fieau-cdni-interfaces-https-delegation-02
>> Diff:           https://www.ietf.org/rfcdiff?
>> url2=draft-fieau-cdni-interfaces-https-delegation-02
>>
>> Abstract:
>> Orange decline toute responsabilite si ce message a ete altere, deforme
>> ou falsifie. Merci.
>>
>> As emails may be altered, Orange is not liable for messages that have
>> been modified, changed or falsified.
>> Thank you.
>>

---

From: [email-masked]
Date: Fri, 17 Nov 2017 00:31:56 +0000

Kevin Ma wrote:
>As a more general question: do we have any sense of whether or not folks are using or planning >to use any of the proposed delegation methods (ACME STAR, subcerts, etc.);
Appears that Digicert plans to use STAR per STAR co-author Thomas Fossati yesterday during STAR update at ACME WG.

>and/or do we >have a feel for which methods might be most useful to CDNs?
My sense is STAR delegation may be slightly preferred over Sub-certs given there is no client changes required and that a CA still issues a short-term cert that may be preferred by an uCDN. The Sub-certs requires changes in client (client provides an extension in ClientHello during TLS handshake and If the extension is present, the server MAY send a DelegatedCredential extension.). And a client that does not have this extension (legacy client) may require additional methods such as LURK for TLS server (dCDN) to request a cert during handshake.

In the draft-fieau-cdni-interfaces…, we do not want to preclude solutions but focus on changes in MI and FCI such that any model can be seamlessly supported.

-Sanjay

From: CDNi [mailto:[email-masked]] On Behalf Of Kevin Ma
Sent: Thursday, November 16, 2017 8:08 PM
To: [email-masked]
Cc: [email-masked]
Subject: [E] Re: [CDNi] TR: New Version Notification for draft-fieau-cdni-interfaces-https-delegation-02.txt

Hi Frederic,

  (As an individual) As I mentioned in the session today, I don't see the advantage of the proposal to change the metadata interface to have top level metadata objects that contain lists of (sub)paths, as opposed to the RFC8006 method of listing all metadata that apply to a given (sub)path.  Though possibly easier for someone who only cares about that one piece of metadata, I don't think that it scales as well to supporting the full set of content delivery metadata for the CDN.  If there are specific reasons that it couldn't work using the existing metadata structure, it would be good to highlight that, as well as provided a more concrete definition of where these new objects would sit in the structural metadata hierarchy, what the serialization impact of that might be, and how backwards compatibility with RFC8006 might be affected.

thanx.

--  Kevin J. Ma

On Thu, Nov 16, 2017 at 6:57 AM, Kevin Ma <[email-masked]<mailto:[email-masked]>> wrote:
Hi All,

  As we discussed in the CDNI Session today, the chairs have begun looking at WG rechartering and would like to gauge general WG interest in the HTTPS delegation stuff on which Frederic has been working.

  We encourage you to read the updated draft and send mail to the list if you have comments, questions, concerns, or just a thumbs up/down on the proposals.

thanx!

--  Kevin and Francois

On Mon, Oct 30, 2017 at 3:33 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Dear all,

I've just posted an update of the draft that proposes an extension to support  HTTPS delivery delegation in CDNI.

Regards,
Frédéric

A new version of I-D, draft-fieau-cdni-interfaces-https-delegation-02.txt
has been successfully submitted by Frederic Fieau and posted to the IETF repository.

Name:           draft-fieau-cdni-interfaces-https-delegation
Revision:       02
Title:          CDNI extensions for HTTPS delegation
Document date:  2017-10-30
Group:          Individual Submission
Pages:          13
URL:            https://www.ietf.org/internet-drafts/draft-fieau-cdni-interfaces-https-delegation-02.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dfieau-2Dcdni-2Dinterfaces-2Dhttps-2Ddelegation-2D02.txt&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=tIxfVzWntXIkWRrH_KRtGPnR7GIrMz7bg-5HrXM2_rY&s=37UEcH4OPsBHm0zheMW_ldckayPMQHt5hoMUF1i3Im4&e=>
Status:         https://datatracker.ietf.org/doc/draft-fieau-cdni-interfaces-https-delegation/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dfieau-2Dcdni-2Dinterfaces-2Dhttps-2Ddelegation_&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=tIxfVzWntXIkWRrH_KRtGPnR7GIrMz7bg-5HrXM2_rY&s=5NCavK16z5I9MLXsOShaxCR3iYb2qd2O6JDj82gdOcE&e=>
Htmlized:       https://tools.ietf.org/html/draft-fieau-cdni-interfaces-https-delegation-02<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dfieau-2Dcdni-2Dinterfaces-2Dhttps-2Ddelegation-2D02&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=tIxfVzWntXIkWRrH_KRtGPnR7GIrMz7bg-5HrXM2_rY&s=zTFSC4pp07KFCS1acfcv8WSFdYLRhKhXDmk5KdrEg2w&e=>
Htmlized:       https://datatracker.ietf.org/doc/html/draft-fieau-cdni-interfaces-https-delegation-02<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dfieau-2Dcdni-2Dinterfaces-2Dhttps-2Ddelegation-2D02&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=tIxfVzWntXIkWRrH_KRtGPnR7GIrMz7bg-5HrXM2_rY&s=KoL0hhiH8-cB-GtID7ksTXEOQMULpJ8m7e5hrBmiEpc&e=>
Diff:           https://www.ietf.org/rfcdiff?url2=draft-fieau-cdni-interfaces-https-delegation-02<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dfieau-2Dcdni-2Dinterfaces-2Dhttps-2Ddelegation-2D02&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=tIxfVzWntXIkWRrH_KRtGPnR7GIrMz7bg-5HrXM2_rY&s=nA6zrfRz2nY1PKMXjZLhTjL7J--IDiXEYM9UdjuSk8g&e=>

Abstract:

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
CDNi mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cdni<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_cdni&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=tIxfVzWntXIkWRrH_KRtGPnR7GIrMz7bg-5HrXM2_rY&s=CRa3wXoTu8LyUwnqdbl8uR4Mfm1vCDv_3gG6GRLZnC4&e=>