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

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