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

Julian Reschke <> Fri, 28 October 2022 14:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 030CCC14CE30 for <>; Fri, 28 Oct 2022 07:21:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.061
X-Spam-Status: No, score=-5.061 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pRT0Yny7eAQr for <>; Fri, 28 Oct 2022 07:21:12 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id ACF23C14CF08 for <>; Fri, 28 Oct 2022 07:21:12 -0700 (PDT)
Received: from lists by with local (Exim 4.94.2) (envelope-from <>) id 1ooQBb-00DG5W-2R for; Fri, 28 Oct 2022 14:18:15 +0000
Resent-Date: Fri, 28 Oct 2022 14:18:15 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <>) id 1ooQBa-00DG2w-5Q for; Fri, 28 Oct 2022 14:18:14 +0000
Received: from ([]) by with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <>) id 1ooQBY-003YfA-GU for; Fri, 28 Oct 2022 14:18:13 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=s31663417; t=1666966679; bh=W88meRqNqdoV+w8mcjnT6PosvMNkfKSTOXtcqmrfIpQ=; h=X-UI-Sender-Class:Date:Subject:To:References:From:In-Reply-To; b=Hguh17ztKQDstyXRENS98FjWmkBYAtOBb2Yt2FzaazrbO4XowyTN3HnbEUOZERD6w 5k6a6LMM2cue+VlZDgkjAaED5PLCoxdjfS5JiiEFjUCAX/b8vDC+cXOODc2N91WQg/ JGNKUHuyQ7B+Cb6EYF3oblXPMOgKUfXXDWiTWLHagXW1GyeOa3HlYKyMJzrnOTis1s u2bqxwilKJeL6rOpsBvUobUXRPgBpj3c5fgtOEJ+Vjyu1Ew5d1o6AEKHKnyf+8OIL7 QpVjPr+GkM0ZGDojAfwtOxsqCWr0DqQmA3JHzdW3B+OXtHWPU90N3rbRD4qrwGVWXW Cl1ItMLiHgAdg==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [] ([]) by (mrgmx104 []) with ESMTPSA (Nemesis) id 1M5wPb-1oh1en3RiV-007UQd for <>; Fri, 28 Oct 2022 16:17:58 +0200
Message-ID: <>
Date: Fri, 28 Oct 2022 16:17:58 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0
Content-Language: en-US
References: <> <> <>
From: Julian Reschke <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:U6qUekC+sBctuUXKnTbB66xCsdZj1d/2R+dyfo/oWH7C7JVpeBG E8uMJk93eKmW1lS554nCFcxZZfW5yP43+vgwcUXn3+IyGvho2jKbcAu3ppZ28JmB62nZb1I LYZOpSetHccXpwWQhrlOsjK9WXI2PnsvAo0oPVGJuMTIffah/sEmP+YVZ5hLgoQLNYxxcxq AZOUFcnzh+3Fv+uwQpZzg==
UI-OutboundReport: notjunk:1;M01:P0:ud+GFKYwXJ8=;41/ITrxS9A2XrEl/qdQJju3pMfy /fuA7Ytpsgf9cx1czd1ePAThWwV9fHi8YyL5IwXM2to6DuFDIBMX2H2dOX2jitOzI6De5ncBr Y0gfV3rPq9qmuQykJlx4O/B/MtfRy95G8IP+5dXDVISX+yjJszarami7BGOVFWYdBNt7ZVrcv 8jsbn1JggOTJmidzITpp2+P9AWdIVTxOYJFwRdA8MEr9lif+AAXn0PRi+RSwRGsYDbQdCUvz1 Vnt/Gd1QLb/N57a1WLmVgAQ/A35Nz5IjN6qOTaiiX5spMlb1diEl1lFFVh42yhGLplwjqnYMb nIR3tgtiaYyDJQFerJRGaNd0QgN4xGqkGLQlJVMCphlJtayaq9Uq7YHQMCFYH40jxnvbOOxUh PaZh4XpMKJYpkgm5t+jMEt1ubRFU5tnnweegtb0Pz6cIF0YDuDfnI4uyLk6uOBhWCc3jz3Qhx QI13Skh9W287YNsF07TbqxeGCQ8AL2NRzJ8voPISfT70EKeJEDw6sE0rd3O7xO1SxUOXwNrxe 2xFddbLYRVWxV99jhhy92xhOf4FGKVl7asQREme4231K62x40xwxFlZ7QWep2odpxvBOVCmKO H2bSqeXvegdUIIOpiwneTOt2HM1/7aD704Of9iRIir5IDLGCdcrzO/lLDLSfWvo8+kKjfmU8s +kWK+3iLvKFUHq5wlgNE+vnLjtPMjxmy7J9rIRYlJ6mof4yyUYqoNPy3IQ/eRrX7gPxoVlrY1 aTHnezoLK5hc7qAh97IpA95yubcoCJNq/c2jgrSGFA/YKL1uRLguRTncjTGwjJYdbwHwTyqxy rQSOeYazuYSqU7P1Wb5xKOcT0ziXVo8GeceUStGfr/udvjrhEISUuVNnLMBc49iCQO7txaQnd /v+ZHlsrBXYoDqzs+LBis45en8Qd04IH88GwRNFHijZWelwwHUztEBLOBaPiJVzWqBXaXGExU dqQIlQ==
Received-SPF: pass client-ip=;;
X-W3C-Hub-DKIM-Status: validation passed: (, signature is good
X-W3C-Hub-Spam-Status: No, score=-5.8
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1ooQBY-003YfA-GU ed8662ed54a5bf733c0f8e4a210307c1
Subject: Re: Working Group Last Call: draft-ietf-httpbis-message-signatures-13
Archived-At: <>
X-Mailing-List: <> archive/latest/40501
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 27.10.2022 16:33, Justin Richer wrote:
> 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

Well, this is tricky.

If you normalize by unescaping, you assume that any usage of
percent-encoding can be removed without losing information. IMHO that is
no the case.

For the path example: a path segment "a%2fb" in general is different
from the "a/b"; minimally in how it will behave in a conforming URI
implementation doing reference resolution.

Maybe the problematic part here is:

"The value is normalized according to the rules in [HTTP], Section
4.2.3. 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."

But that's not what HTTP, Section 4.2.3 says:

"Characters other than those in the "reserved" set are equivalent to
their percent-encoded octets: the normal form is to not encode them (see
Sections 2.1 and 2.2 of [URI])."

So percent-unescaping is only "safe" when restricted to characters that
are not in the "reserved" set (and "/" is in the reserved set).

Best regards, Julian