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

[Phil Sorber <[e-mail]>]

Off the top of my head, I think we’d want to limit it to sections 3.2.7 and
3.2.8. I need to think on it more and get back to you.

On Sun, Jul 25, 2021 at 13:13 Kevin Ma <[e-mail]> wrote:

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