Re: Working Group Last Call: draft-ietf-httpbis-message-signatures-13

Hi Julian,

Thanks for bringing this up. When the authors discussed both the @path and @query derived components, we struggled a bit to come up with the best way to define a canonicalized form, since both can use percent-encoding in the wild. While for the vast majority of applications it’s going to be “take whatever string is handed to me by calling getPath() and getQuery()”, and that’s going to work, we obviously need to have something more precise here for all the corner cases.

At the time of first discussion, the best advice seemed to be to account for the percent-encoding on both of these, since that’s what most libraries seemed to do automatically behind the scenes. The language that we have was intended to reflect that, but we will absolutely defer to others in the group if there’s a better way to describe this.

I agree that we should have some examples that reflect any allowable transformations, too. We’ve got an appendix for showing these kinds of things that would be a great place to showcase this, with a forward reference from the @path and @query sections.

I’m interested to hear what others think the best approach would be here.

Thanks,
 — Justin

> On Oct 26, 2022, at 1:39 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
> 
> On 27.09.2022 01:01, Mark Nottingham wrote:
>> ...
> 
> I started a review, and I'm finding mostly minor issues so far which
> I'll summarize either later or create PRs for).
> 
> One thing that *might* be non-trivial is the handling of percent-escaping.
> 
> For instance, in
> <https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-13.html#section-2.2.6>:
> 
> "Namely, an empty path string is normalized as a single slash /
> character, and path components are represented by their values after
> decoding any percent-encoded octets."
> 
> So consider:
> 
> POST /foo%2fbar HTTP/1.1
> Host: www.example.com
> 
> Unescaping %2f to "/" would yield a @path component value of
> 
> /foo/bar
> 
> is that really intended? I believe we need to have a look at the
> following cases:
> 
> - escaped characters that otherwise would delimit URI components (such
> as "?" or "#")
> 
> - escaped characters that otherwise have a special role inside a
> component (such as "/" in the path or "&" in a query)
> 
> - escaped characters that map to non-ASCII characters (do we care about
> encoding schemes, and if so, which?)
> 
> - escaped characters that might otherwise be problematic (%00 for instance)
> 
> I'm not sure yet what the correct approach would be, but whatever it is,
> it should be reflected in the examples.
> 
> Best regards, Julian
> 
> 
>

Received on Thursday, 27 October 2022 14:34:39 UTC