Re: Signing Set-Cookie

A Set-Cookie header could have a comma in it (e.g. in the Expires= or Path=
parts), which means that it's probably possible for two different
combinations of Set-Cookie headers to be concatenated/canonicalized to the
same value. I'm not certain there's an attack here, but this seems
potentially problematic enough that this should be given more consideration.

On Wed, Jun 1, 2022 at 2:39 PM Justin Richer <jricher@mit.edu> wrote:

> The Set-Cookie header syntax is weird in that it doesn’t allow for
> concatenation in the normal List syntax. The Signature spec relies on this
> concatenation for the combination of values of headers that show up
> multiple times. This discrepancy is called out in this issue:
>
> https://github.com/httpwg/http-extensions/issues/1183
>
> However, on further investigation, I don’t think this actually causes a
> problem. The concatenation process outlined in Signatures still works on
> multiple Set-Cookie values, the only weird thing is that the RESULT of that
> process cannot itself be parsed as a valid Set-Cookie header.
>
> But the thing is, it doesn’t have to be parsed. It just has to exist as a
> string in the signature base, and be re-created by both signer and verifier
> in a consistent way.
>
> I’m planning on closing this issue with a note in the appropriate section
> of the signature spec, but if there’s something I’m missing about this,
> please chime in.
>
>  — Justin
>