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

I'd like to bring this up again because I think it's a potentially
serious implementation concern and I don't see an easy way around it.
There is a MUST requirement in the latest draft:

   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.

Unfortunately, there exists no specification for path-style or
form-style parameters, so it is impossible for an implementer to know
how to reliably locate the token. This appears to be by design,
though. ( See RFC 8820: https://datatracker.ietf.org/doc/html/rfc8820
, which is now published.)

I think the intent of this wording is to imply that everybody should
use application/x-www-form-urlencoded for form-style parameters and
path-style parameters that look like "path;param1=a,param2=b", but
aren't specified anywhere in particular.

I see no way for an implementer to determine whether they've met the
requirement set out that they MUST meet as it is written.

I also wonder whether URI Signing is properly understood as an
Extension or an Application, in the terms of 8820. I think it wants to
be an Extension (for example: `a new signature mechanism for "http"
URIs`), but might be an Application in practice (`an HTTP interface to
particular information on a host`). I think important to the
discussion is that URI Signing is a mechanism added by an upstream
entity that controls the content and its format. I think this is an
important issue to resolve.

On Fri, Feb 12, 2021 at 9:24 AM Chris Lemmons <alficles@gmail.com> wrote:
>
> The latest document replaces the path parsing logic with this:
>
> > URI Signing Package (URISigningPackage): The URI attribute that encapsulates all the URI Signing claims in a signed JWT encoded format.  This attribute is exposed in the Signed URI as a path-style parameter or a form-style parameter.
>
> Unfortunately, that doesn't give implementers any idea what needs to
> be parsed. I read through the conversation on last-call with mnot
> (https://mailarchive.ietf.org/arch/msg/last-call/yIhgGSja7_OoFXK_SGQUuhMdO2o/),
> especially with regard to BCP190. I also read through RFC6570 and
> you're right, it doesn't work for our use case because it's generating
> URI, not consuming them. And it's for precisely this reason that we
> need to be specific in what is accepted.
>
> As near as I can tell, there is actually no standard anywhere that
> describes "path-style parameters". And there are multiple methods for
> defining "form-style parameters", some more recent than others and in
> varying levels of use generally on the Internet. How can a document
> have a MUST requirement that requires parsing a specific structure
> that isn't specified anywhere or even widely agreed upon?
>
> On Thu, Feb 11, 2021 at 12:32 PM <internet-drafts@ietf.org> 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-21.txt
> >         Pages           : 41
> >         Date            : 2021-02-11
> >
> > 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 are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-cdni-uri-signing-21
> > https://datatracker.ietf.org/doc/html/draft-ietf-cdni-uri-signing-21
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-uri-signing-21
> >
> >
> > 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
> > CDNi@ietf.org
> > https://www.ietf.org/mailman/listinfo/cdni