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

From: Kevin Ma <[email-masked]>
Date: Sun, 7 Nov 2021 00:01:56 -0400

Hi Phil,

  Thanks for getting the updated draft out.  A couple typos/nits:

  - section 2.1.10: "for example in" -> "for example, in"
  - section 3.2.1: "MAY bt" -> "MAY be"
  - section 4: "after and access" -> "after an access"
  - section 4.4: remove "against the key issuer with"
  - section 5.2: "Sigbned" -> "Signed"

--  Kevin J. Ma

On Mon, Oct 25, 2021 at 7:12 PM <[email-masked]> 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
> WG of the IETF.
>
>         Title           : URI Signing for Content Delivery Network
> Interconnection (CDNI)
>         Authors         : Ray van Brandenburg
>                           Kent Leung
>                           Phil Sorber
>         Filename        : draft-ietf-cdni-uri-signing-22.txt
>         Pages           : 42
>         Date            : 2021-10-25
>
> Abstract:
>    This document describes how the concept of URI Signing supports the
>    content access control requirements of Content Delivery Network
>    Interconnection (CDNI) and proposes a URI Signing method as a JSON
>    Web Token (JWT) 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 User Agent (UA).  The
>    mechanism described can be used both in CDNI and single Content
>    Delivery Network (CDN) scenarios.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-cdni-uri-signing/
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-cdni-uri-signing-22
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-uri-signing-22
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni
>

---

From: Phil Sorber <[email-masked]>
Date: Mon, 8 Nov 2021 19:55:03 -0700

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

On Sat, Nov 6, 2021 at 10:02 PM Kevin Ma <[email-masked]> wrote:

>> This draft is a work item of the Content Delivery Networks
>> Interconnection WG of the IETF.
>>

---

From: Chris Lemmons <[email-masked]>
Date: Tue, 9 Nov 2021 01:00:15 -0700

Fixes for nits, regrettably also including the same ones you just
fixed in 69: https://github.com/PSUdaemon/URISigningSpec/pull/70

Updates that I _think_ fix the weird figure text? I'm not certain this
is the best way to do it, but the existing way looks odd. Look at the
diff linked earlier and check out the figure titles.
https://github.com/PSUdaemon/URISigningSpec/pull/71

The much-belated text I promised a while back on 6570:
https://github.com/PSUdaemon/URISigningSpec/pull/72

On Mon, Nov 8, 2021 at 7:55 PM Phil Sorber <[email-masked]> 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 WG of the IETF.
>>>
>>>         Title           : URI Signing for Content Delivery Network Interconnection (CDNI)

---

From: Phil Sorber <[email-masked]>
Date: Tue, 9 Nov 2021 08:46:46 -0700

Thanks, I merged two of these, but I think we should have a little more
time to think on #72 before we merge it, just because it's been so debated
and I don't want to keep changing it.

---

From: Chris Lemmons <[email-masked]>
Date: Wed, 10 Nov 2021 00:38:10 -0700

To save a click, here's the text:

The URI Signing Package will be found by parsing any path-style parameters and
form-style parameters looking for a key name matching the URI Signing
Package Attribute.
Both parameter styles MUST be supported to allow flexibility of operation.
The first matching parameter SHOULD be taken to provide the signed
JWT, though providing
more than one matching key is undefined behavior. Path-style
parameters generated in the
form indicated by Section 3.2.7 of [RFC6570] MUST be supported.
Form-style parameters generated in the form indicated by Section 3.2.8
of [RFC6570]
MUST be supported.

The last two sentences are what I'm proposing we add. This was the
simplest variation I could come up with that doesn't add a whole bunch
of construction rules to this document, but provides at least one
clear MUST-accept implementation for each style that allows a dCDN to
be certain that it knows how to find the URIs.

On Tue, Nov 9, 2021 at 8:46 AM Phil Sorber <[email-masked]> wrote:
>
> Thanks, I merged two of these, but I think we should have a little more time to think on #72 before we merge it, just because it's been so debated and I don't want to keep changing it.
>

---

From: Kevin Ma <[email-masked]>
Date: Wed, 10 Nov 2021 13:05:03 -0500

Thanks for the text Chris,

  Is there a reason to only reference 3.2.8 and not 3.2.9 for form-style
parameters?

  There is some redundancy in the MUSTs.  What about:

The URI Signing Package will be found by parsing any path-style parameters
[RFC6570] and form-style parameters [RFC6570] looking for a key name
matching the URI Signing Package Attribute.  Both path-style parameters
(generated in the form indicated by Section 3.2.7 of [RFC6570]) and
form-style parameters (generated in the form indicated by Sections 3.2.8
and 3.2.9 of [RFC6570]) MUST be supported.  The first matching parameter
SHOULD be taken to provide the signed JWT, though providing more than one
matching key is undefined behavior.

thanx!

--  Kevin J. Ma

---

From: Kevin Ma <[email-masked]>
Date: Wed, 10 Nov 2021 13:06:44 -0500

note: we could also use direct section references...

---

From: Chris Lemmons <[email-masked]>
Date: Wed, 10 Nov 2021 18:42:30 -0700

Agreed, and your version uses even fewer words, which I like. And the
only reason not to reference 3.2.9 is an error on my part. It should
be included. It feels slightly odd to include a normative reference
parenthetically, but it's not wrong. It definitely reads better.

On Wed, Nov 10, 2021 at 11:06 AM Kevin Ma <[email-masked]> wrote:
>>   Is there a reason to only reference 3.2.8 and not 3.2.9 for form-style parameters?
>>
>> The URI Signing Package will be found by parsing any path-style parameters [RFC6570] and form-style parameters [RFC6570] looking for a key name matching the URI Signing Package Attribute.  Both path-style parameters (generated in the form indicated by Section 3.2.7 of [RFC6570]) and form-style parameters (generated in the form indicated by Sections 3.2.8 and 3.2.9 of [RFC6570]) MUST be supported.  The first matching parameter SHOULD be taken to provide the signed JWT, though providing more than one matching key is undefined behavior.
>>
>> thanx!
>>
>> --  Kevin J. Ma
>>