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

[Chris Lemmons <[e-mail]>]

I honestly think that URI Signing is more appropriately understood as
an application than an extension of HTTP. You can't use URI Signing
without special agreement between the entity producing the URI and the
one that finally processes it. You can't for example, give a signed
URI to a CDN or other server that isn't expecting to process it.

We could make the location of the token entirely outside the confines
of the specification, allowing signers and processors to communicate
out-of-band about where the token will be. That would considerably
reduce the value and interoperability provided in the document,
though.

As it stands, there's a MUST requirement that requires that you do
something that isn't documented anywhere. It's not possible for an
implementation to know whether they are meeting the MUST parse path
parameters requirement without anything that describes what a path
parameter is.

On Sat, Jul 24, 2021 at 12:14 AM Kevin Ma <[e-mail]> wrote:
>
> Hi Chris,
>
>   (As chair) I don't disagree that it would be nice if there was an RFC like RFC6570 that explicitly described the parsing rules.  But I think the point of RFC8820 is that we should not be defining those rules in the URI signing RFC.  Does that mean we should hold off on URI signing until such time as Mark writes that other RFC?  I think Mark's acceptance of the current text during last call (https://mailarchive.ietf.org/arch/msg/last-call/PxSKvtGtlkQAf7cExIs9HtkzutI/) implies no.  That said, if there are editorial changes that would make the reading easier, we can still consider those, but I don't think we can/should add prescriptive text.
>
>   I guess I would be interested if any others in the WG have significant concerns about the ambiguity or interoperability?
>
> thanx.
>
> --  Kevin J. Ma
>
> On Tue, Jul 6, 2021 at 2:55 PM Chris Lemmons <[e-mail]> wrote:
>>
>> The problem I'm running into with 6570 is that it _only_ describes a
>> format for producing URIs, not one for understanding them. For
>> example, if you receive this URI, what is the correct behaviour?
>>
>> https://cdn.example.net/path/to/content.m3u8?foo=bar;URISigningPackage=JWT
>>
>> This was once considered best practice:
>> https://www.w3.org/TR/html401/appendix/notes.html#h-B.2.2
>>
>> Is the idea to require query strings to comply with the encoding and
>> decoding requirements of application/x-www-form-urlencoded? If so,
>> don't we run into the same problem as before with 8820?
>>
>> And it's mostly possible to reverse-engineer the path format from 6570
>> into an unwritten expectation of a format, but I'm not sure an
>> undocumented format is better than a documented one here.
>>
>> On Sun, Jul 4, 2021 at 9:21 PM Kevin Ma <[e-mail]> wrote:
>> >
>> > Hi Chris,
>> >
>> > > 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.
>> >
>> > My understanding from the discussion with Mark (https://mailarchive.ietf.org/arch/msg/last-call/PxSKvtGtlkQAf7cExIs9HtkzutI/) is that "path-style" and "form-style" refer to the corresponding descriptions in RFC6570.  Do you think it would help if we added a reference to RFC6570 and some text to the effect of "where path-style and form-style parameters conform to RFC6570 path-style parameter and form-style query expansion formats, respectively"?
>> >
>> > > I also wonder whether URI Signing is properly understood as an Extension or an Application, in the terms of 8820.
>> >
>> > I think URI Signing should be classified as an "Extension".  As you noted, RFC8820 explicitly notes "signature mechanisms", and we did explicitly discuss our use case with Mark when he first asked us to "get off his lawn" (https://mailarchive.ietf.org/arch/msg/cdni/3Zt4iDgyVhICgBjpLAlDxqL7uJI/).  Do you think an explicit declaration and reference to RFC8820 would help?
>> >
>> > thanx.
>> >
>> > --  Kevin J. Ma
>> >
>> > On Mon, Jun 14, 2021 at 1:59 PM Chris Lemmons <[e-mail]> wrote:
>> >>
>> >> 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 <[e-mail]> 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 <[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 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
>> >> > > [e-mail]
>> >> > > https://www.ietf.org/mailman/listinfo/cdni
>> >>
>> >> _______________________________________________
>> >> CDNi mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/cdni