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

[Chris Lemmons <[e-mail]>]

I see at least two options. One option is something very close to what
you suggested earlier: Revise the text to have a normative dependence
on 6570 and say that implementations MUST accept parameters in the
format generated by a URI template of a particular form. This doesn't
help a processor know what to do with ambiguous input, which isn't
great, but it does at least let the processor implement in a way that
covers all valid forms. Of all the suggestions made so far, this is
the one I like the most. But I don't think it gets us out of the
trouble Mark brought up. That is, we're effectively defining a format
on a part of the URI by saying it has to be generated in a particular
form. If, however, everybody is happy with normative text requiring
the processing of template-generated URIs with usefully defined
templates, that works for me. It's a target you can aim at.

The other main option is to take the token location out entirely and
remove the MUST. You can imagine text similar to: The URI Signing
Package will be found by parsing the URI. The details of how the URI
will be parsed will be communicated out-of-band between the CSP, uCDN
and and all dCDNs.

If we take the first approach, we're effectively standardizing part of
the URI. If we take the second approach, we're not standardizing the
URI, but it's also impossible to use URI Signing without some explicit
agreement between the parties. (Some communication out-of-band is
expected, to transfer the trusted keys, so this isn't _totally_ out of
the realm of possibility.) Practically, though, there are only a few
reasonable places to look, so we're just waving our hands and assuming
without saying it aloud that everybody will use the format generated
by 6570 or something close.

There's no way to do URI Signing without having somewhere in the URI
that can be recognized as having a token in it. You can do it
explicitly or implicitly, but you have to do it. I think that what
we're doing here is in application-land instead of extension-land and
option 1 is fine. But others may not agree there.

On Sat, Jul 24, 2021 at 8:23 PM Kevin Ma <[e-mail]> wrote:
>
> 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