W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2022

Re: Review of draft-ietf-httpbis-message-signatures-13

From: Ilari Liusvaara <ilariliusvaara@welho.com>
Date: Tue, 15 Nov 2022 12:06:19 +0200
To: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <Y3Nkm4kjedFnyuoT@LK-Perkele-VII2.locald>
On Mon, Nov 14, 2022 at 08:29:28PM -0500, Kyle Rose wrote:
> * "Note that some HTTP fields, such as Set-Cookie [COOKIE], do not follow a
> syntax that allows for combination of field values in this manner such that
> the combined output is unambiguous from multiple inputs. However, the
> canonicalized component value is never parsed by the message signature
> process, merely used as part of the signature base in Section 2.5." While
> the canonicalized value is never parsed, it is critical that it be 1:1 with
> semantically distinct original values. That is, wherever two bit-distinct
> input representations are considered equivalent, the canonicalized values
> must be identical; *AND* the inverse, i.e., two input representations *not*
> considered equivalent must be transformed by canonicalization into
> bit-distinct values.ยน The reason for being precise here is that it must not
> be possible for two semantically-distinct sequences of Set-Cookie fields to
> be transformed by canonicalization into the same value, or a signature may
> be regarded as valid for an unintended message. If that is within the
> bounds of acceptable ambiguity, the safety or risks of doing so within this
> domain must be explained. (I can't tell whether the discussion in section
> 7.5.6 is sufficient to cover this.)

Set-Cookie is indeed special in way that precludes the use of the usual
field combining. Consider the following value:

"foo=bar; baz, zot=quux"

That is both valid cookie named "foo" with value "bar" and attribute
"baz, zot=quux" (yes, containing a comma and space), and the result of
standard combination of cookie named "foo" with value "bar" and
attribute "baz", plus a second cookie named "zot" with value "quux" and
no attributes.

Received on Tuesday, 15 November 2022 10:06:36 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:44:08 UTC