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

[Kevin Ma <[e-mail]>]

Hi Chris,

  Do you have a solution proposal?

thanx.

--  Kevin J. Ma

On Sat, Jul 24, 2021 at 3:12 PM Chris Lemmons <[e-mail]> wrote:

> 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
>