Subject: Re: [Last-Call] Last Call: <draft-ietf-cdni-uri-signing-20.txt> (URI Signing for Content Delivery Network Interconnection (CDNI)) to Proposed Standard

From: Mark Nottingham <[email-masked]>
Date: Sat, 6 Feb 2021 14:17:03 +1100

I have trouble getting through this quite dense document. However, this text:

~~~
   The URI Signing Package will be found by searching the URI Query string [RFC3986] (see [RFC3986] Section 3.4), left-to-right, for the following sequence:
   o  the URI Signing Package Attribute name,
   o  an equal symbol ('='),
   o  and a sequence of zero or more non-reserved characters (as defined in [RFC3986] Section 2.3) that will be interpreted as a signed JWT,
   o  terminated by either any reserved character (as defined in [RFC3986] Section 2.2) or the end of the URI Query string.
~~~

leads me to believe that it doesn't line up with BCP190. 

Cheers,

> On 6 Feb 2021, at 10:12 am, The IESG <[email-masked]> wrote:
> 
> 
> The IESG has received a request from the Content Delivery Networks
> Interconnection WG (cdni) to consider the following document: - 'URI Signing
> for Content Delivery Network Interconnection (CDNI)'
>  <draft-ietf-cdni-uri-signing-20.txt> as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2021-02-19. Exceptionally, comments may
> be sent to [email-masked] instead. In either case, please retain the beginning
> of the Subject line to allow automated sorting.
> 
> 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 file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-cdni-uri-signing/
> 
> 
> The following IPR Declarations may be related to this I-D:
> 
>   https://datatracker.ietf.org/ipr/2603/
>   https://datatracker.ietf.org/ipr/4628/
> 
> 
> 
> 
> 
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

--
Mark Nottingham   https://www.mnot.net/

---

From: Phil Sorber <[email-masked]>
Date: Tue, 9 Feb 2021 19:25:37 -0700

Mark,

I took some time to read through BCP190 and spoke with some experienced
people offline to make sure I was as informed as possible. I also read
through RFC 6570 (URI Template) which seemed promising but has a fatal flaw
for my use case. My document relies on another WG document (RFC 8006) to
handle disseminating configuration data between the Content Service
Providers and the various levels of CDNs. The intent is that processing of
this data is done in an automated manner. So a requirement for my document
is that however I configure where the URI Signing Package is in the URI, it
needs to be able to be processed programmatically. Using URI Templates I
can take a template and variables and create a URI, but I cannot take a
template and a URI and derive the variables. The syntax makes it ambiguous.

Additionally, the text you cited is my clumsy attempt to describe how to
parse URI query parameters, and not how to generate a URI. Our parameter
key is also not specified in the document, but passed out of band. All that
is required in the document is for the recipient to be able to parse path
parameters and query parameters looking for the previously agreed upon key
name.

Furthermore, upon reading of RFC 6570 I see references to "path-style
parameters" and "form-style parameters" with no normative or informative
reference accompanying it. That would lead me to believe that my text on
how to parse these isn't needed and is only likely to cause confusion to
implementers.

So what I would like to propose as a change is that I remove my parameter
parsing text and replace it with text stating something to the effect of
"MUST parse all path-style and form-style parameters and SHOULD use the
first instance a key with the previously agreed upon name." I believe this
is still in the spirit of BCP 190.

Thanks.

On Fri, Feb 5, 2021 at 8:18 PM Mark Nottingham <[email-masked]> wrote:

>    The URI Signing Package will be found by searching the URI Query string
> [RFC3986] (see [RFC3986] Section 3.4), left-to-right, for the following
> sequence:
>    o  and a sequence of zero or more non-reserved characters (as defined
> in [RFC3986] Section 2.3) that will be interpreted as a signed JWT,
>    o  terminated by either any reserved character (as defined in [RFC3986]
> Section 2.2) or the end of the URI Query string.
> ~~~
>
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call
>

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 10 Feb 2021 14:05:18 +1100

Hi Phil,

I think that makes sense -- thanks. Happy to review text when you get to it.

Cheers,

> On 10 Feb 2021, at 1:25 pm, Phil Sorber <[email-masked]> wrote:
> 
> Mark,
> 
> I took some time to read through BCP190 and spoke with some experienced people offline to make sure I was as informed as possible. I also read through RFC 6570 (URI Template) which seemed promising but has a fatal flaw for my use case. My document relies on another WG document (RFC 8006) to handle disseminating configuration data between the Content Service Providers and the various levels of CDNs. The intent is that processing of this data is done in an automated manner. So a requirement for my document is that however I configure where the URI Signing Package is in the URI, it needs to be able to be processed programmatically. Using URI Templates I can take a template and variables and create a URI, but I cannot take a template and a URI and derive the variables. The syntax makes it ambiguous.
> 
> Additionally, the text you cited is my clumsy attempt to describe how to parse URI query parameters, and not how to generate a URI. Our parameter key is also not specified in the document, but passed out of band. All that is required in the document is for the recipient to be able to parse path parameters and query parameters looking for the previously agreed upon key name.
> 
> Furthermore, upon reading of RFC 6570 I see references to "path-style parameters" and "form-style parameters" with no normative or informative reference accompanying it. That would lead me to believe that my text on how to parse these isn't needed and is only likely to cause confusion to implementers.
> 
> So what I would like to propose as a change is that I remove my parameter parsing text and replace it with text stating something to the effect of "MUST parse all path-style and form-style parameters and SHOULD use the first instance a key with the previously agreed upon name." I believe this is still in the spirit of BCP 190.
> 
> Thanks.
>

---

From: Phil Sorber <[email-masked]>
Date: Wed, 10 Feb 2021 15:44:05 -0700

Here is the PR for this review:
https://github.com/PSUdaemon/URISigningSpec/pull/67

On Tue, Feb 9, 2021 at 8:05 PM Mark Nottingham <[email-masked]> wrote:

> > So what I would like to propose as a change is that I remove my
> parameter parsing text and replace it with text stating something to the
> effect of "MUST parse all path-style and form-style parameters and SHOULD
> use the first instance a key with the previously agreed upon name." I
> believe this is still in the spirit of BCP 190.
> >
> > Thanks.
> >
> >    The URI Signing Package will be found by searching the URI Query
> string [RFC3986] (see [RFC3986] Section 3.4), left-to-right, for the
> following sequence:
> >    o  terminated by either any reserved character (as defined in
> [RFC3986] Section 2.2) or the end of the URI Query string.
> > ~~~
> >

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 11 Feb 2021 10:47:07 +1100

Looks good, thanks. 

> On 11 Feb 2021, at 9:44 am, Phil Sorber <[email-masked]> wrote:
> 
> Here is the PR for this review: https://github.com/PSUdaemon/URISigningSpec/pull/67
>