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

[Kevin Ma <[e-mail]>]

Hi Chris,

  Thanks for laying those out.

  (As an individual) Of the two proposals, I prefer option 1, as I think it
is better to have some expectations listed in the spec and not just punt it
to an out-of-band requirement.  I don't see an issue with adding a
normative reference to RFC6570 and stating those expectations.  I don't
think we're terribly far off from that with the existing text.  And given
the previous last call discussion with Mark, I'm hopeful he would approve.

  (As a chair) Phil, do you, or any others in the WG have any thoughts on
this proposal?

thanx.

--  Kevin J. Ma

On Sun, Jul 25, 2021 at 1:11 AM Chris Lemmons <[e-mail]> wrote:

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