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

Re: combined field value, Re: Working Group Last Call: draft-ietf-httpbis-message-signatures-13

From: Justin Richer <jricher@mit.edu>
Date: Mon, 31 Oct 2022 14:33:27 +0000
To: Julian Reschke <julian.reschke@gmx.de>
CC: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <7BE7AA9D-2EFB-44AA-AB56-9C23E0F55AFF@mit.edu>
Hi Julian, thanks for this writeup of this issue. Multiple-valued fields have been potentially trouble from the start of this work many years ago.

After re-reading the text in RFC9110 section 5, but especially 5.3, the normalization rules are consistent with the advice of " For consistency, use comma SP”, but an intermediary could in fact combine field values without spaces on the way through. I think what we want to do is something like:

	HTTP fields that are known to be  "list-based fields” by the signer or verifier which have multiple values MUST have all values combined using the delimiter of “comma <SP>” as suggested by RFC9110. <warning about set-cookie goes here>

So it’s still the “combined value” but it’s got very specific rails around it. What do you think of this approach?

I agree that we might want to revisit this text in the HTTP semantics document, too. In my own limited practical experience, whenever the libraries I’ve used offer a pre-combined value, it always does the combination with “comma <SP>”, as shown in both examples and in the non-normative recommendations. I think that the fact that the examples do the same, in spite of the normative text technically allowing other options, is a practical consideration for implementors.

 — Justin

> On Oct 28, 2022, at 12:24 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 27.09.2022 01:01, Mark Nottingham wrote:
>> ...
> <https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-13.html#section-2.1>
> says:
> > Unless overridden by additional parameters and rules, the HTTP field
> value MUST be canonicalized as a single combined value as defined in
> Section 5.2 of [HTTP].
> ...but later on it specifies...:
> > Concatenate the list of values together with a single comma (",") and
> a single space (" ") between each item.
> ...which is inconsistent with Section 5.2's definition of "combined value":
> >  When a field name is repeated within a section, its combined field
> value consists of the list of corresponding field line values within
> that section, concatenated in order, with each field line value
> separated by a comma.
> Not good. This message-signatures spec can likely work-around this by
> not referring to the definition of "combined field value" from 5.2 --
> but we may have to discuss this as an issue in the core spec (which goes
> on with an example where SP is indeed inserted, and Section 5.3 which
> explicitly allows that).
> Best regards, Julian

Received on Monday, 31 October 2022 14:34:07 UTC

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