Re: [CDNi] I-D Action: draft-ietf-cdni-uri-signing-12.txt

[Phil Sorber <[e-mail]>]

I created this PR to add that paragraph back. Can you guys comment?

https://github.com/PSUdaemon/URISigningSpec/pull/22

Thanks.

On Wed, Jul 5, 2017 at 11:24 PM Kent Leung (kleung) <[e-mail]>
wrote:

> Hi Ben. Thanks for your review comments.  See my response to some of them
> below.
>
>
>
>
>
>
>
> *From:* CDNi [mailto:[e-mail]] *On Behalf Of *Ben
> Niven-Jenkins
> *Sent:* Tuesday, July 4, 2017 3:59 AM
> *To:* Phil Sorber <[e-mail]>
> *Cc:* [e-mail]
>
>
> *Subject:* Re: [CDNi] I-D Action: draft-ietf-cdni-uri-signing-12.txt
>
>
>
> Hi Phil & URI Signing authors,
>
>
>
> I read the latest draft (-12) and below are some questions / thoughts, in
> no particular order, that occurred to me while reading the document.
>
>
>
> * Why support both symmetric & asymmetric keys? What is the advantage to
> having both options versus just picking one option (probably asymmetric
> keys as they work for all use cases)?
>
>
>
> KL> There are pros and cons of using either asymmetric keys vs symmetric
> key. Key distribution limitations and relationships between CSP and CDNs
> are factors. So I think supporting both allows flexibility for deployments
> of URI signing. Existing URI signing proprietary implementations typically
> support both already.
>
>
>
>
>
> * How are the keys distributed between CDNs? I don’t see a property in the
> UriSigning Metadata object that would include (or link to) the keys (I’m
> assuming you need to support distribution of at least 2 keys to support key
> rotation)?
>
>
>
> KL> Key distribution is out of scope. I noticed following text was dropped
> when method converted to JWT. We can put this back in CDNI Overview
> section, where the asymmetric and symmetric key methods are mentioned.
>
>
>
> “Two types of keys can be used for URI Signing: asymmetric keys and
>
>    symmetric keys.  Asymmetric keys are based on a public/private key
>
>    pair mechanism and always contain a private key only known to the
>
>    entity signing the URI (either CSP or uCDN) and a public key for the
>
>    verification of the Signed URI.  With symmetric keys, the same key is
>
>    used by both the signing entity for signing the URI as well as by the
>
>    validating entity for validating the Signed URI.  Regardless of the
>
>    type of keys used, the validating entity has to obtain the key
>
>    (either the public or the symmetric key).  There are very different
>
>    requirements for key distribution (out of scope of this document)
>
>    with asymmetric keys and with symmetric keys.  Key distribution for
>
>    symmetric keys requires confidentiality to prevent another party from
>
>    getting access to the key, since it could then generate valid Signed
>
>    URIs for unauthorized requests.  Key distribution for asymmetric keys
>
>    does not require confidentiality since public keys can typically be
>
>    distributed openly (because they cannot be used for URI signing) and
>
>    private keys are kept by the URI signing function.”
>
>
>
>
>
> * How does a uCDN know whether it is OK/safe/within policy to
> re-distribute symmetric keys to a dCDN?
>
>
>
> KL> See above.
>
>
>
> * In the case of Signed Token chains, how does a CDN obtain the keys
> required to sign the new tokens in the chain as it generates them?
>
>
>
> KL> See above.
>
>
>
> Kent
>
>
>
>
>
> * Section 3.3.1 I think needs to be more explicit, I don’t know how one
> could communicate a token chain via the query string as specified in the
> document, as there is no “back channel” for the CDN to communicate the next
> token in the chain to the UA.
>
>
>
> HTH
>
> Ben
>
>
>
> On 25 Jun 2017, at 21:19, Phil Sorber <[e-mail]> wrote:
>
>
>
> Really hoping to get some feedback on this at the meeting in Prague. It's
> got all the changes that have been discussed so I'm not aware of any more
> substantive changes needed. However, lots of editorial nits I suspect.
>
> Thanks.
>
>
>
> On Sun, Jun 25, 2017 at 2:12 PM <[e-mail]> wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Content Delivery Networks Interconnection
> of the IETF.
>
>         Title           : URI Signing for CDN Interconnection (CDNI)
>         Authors         : Ray van Brandenburg
>                           Kent Leung
>                           Phil Sorber
>         Filename        : draft-ietf-cdni-uri-signing-12.txt
>         Pages           : 35
>         Date            : 2017-06-25
>
> Abstract:
>    This document describes how the concept of URI signing supports the
>    content access control requirements of CDNI and proposes a URI
>    signing method as a JSON Web Token (JWT) [RFC7519] profile.
>
>    The proposed URI signing method specifies the information needed to
>    be included in the URI to transmit the signed JWT as well as the
>    claims needed by the signed JWT to authorize a UA.  The mechanism
>    described can be used both in CDNI and single CDN scenarios.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-cdni-uri-signing/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-cdni-uri-signing-12
> https://datatracker.ietf.org/doc/html/draft-ietf-cdni-uri-signing-12
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-uri-signing-12
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> CDNi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cdni
>
> _______________________________________________
> CDNi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cdni
>
>
>