- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Thu, 15 Oct 2015 00:48:37 -0400
- To: W3C Credentials Community Group <public-credentials@w3.org>
- CC: public-webid <public-webid@w3.org>
On 10/14/2015 05:30 PM, henry.story@bblfish.net wrote: > I found the following in > http://www.w3.org/Protocols/rfc2616/rfc2616.txt > > The order in which header fields with differing field names are > received is not significant. > > and a bit later > > The order in which header fields with the same field-name are > received is therefore significant to the interpretation of the > combined field value, and thus a proxy MUST NOT change the order of > these field values when a message is forwarded. Very helpful, thank you Henry. I'll try to figure out if we can refer to that text from the spec when I'm editing it later tomorrow. > So it looks like header order can be relied on. What I suppose may > still happen is a proxy add a new header of the same field name... If a proxy adds a new header of the same field name it would modify the signature string and thus invalidate the signature. Clearly, this is not ideal, but the proxy would be changing the message in a way that would look very much like a MitM attack. The way around it for the application would be to bundle the data in a separate header, "X-My-App" for example, and sign over that. The likelihood that a proxy would add a "X-My-App" header is highly unlikely. > Perhaps one can refer to that passage in the RFC to substantiate the > decision. +1, I'll try to find a place in the spec where we can point to this. Perhaps we should have a section on Proxies modifying headers. It's come up enough at this point to warrant some text being written about it. > ( I was thinking otherwise that one could organise the headers > alphabetically ) Note that there is already this text in the spec (concerning the order of headers as they appear in the 'header' parameter and how that is used to build the signing string): """ Note that the list order is important, and MUST be specified in the order the HTTP header field-value pairs are concatenated together during signing. """ https://tools.ietf.org/html/draft-cavage-http-signatures-05#section-2.1.3 -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: Web Payments: The Architect, the Sage, and the Moral Voice https://manu.sporny.org/2015/payments-collaboration/
Received on Thursday, 15 October 2015 04:49:09 UTC