(inline) On 9 dec 2008, at 21:38, Kevin Brown wrote: > On Tue, Dec 9, 2008 at 12:13 PM, Marc Worrell <[EMAIL PROTECTED]> wrote: > > We are getting somewhere. > > Brian, thanks for the sha1/hmac-sha1 explanation. It is now clear to > me, I didn't consider a opensocial like platform. > > On 9 dec 2008, at 19:51, Brian Eaton wrote: > > On Tue, Dec 9, 2008 at 9:15 AM, John Hayes <[EMAIL PROTECTED] > >> 3. Specify exactly what will be hashed: I recommend after > >> transforming the > >> entity to bytes (no wide chars unless the endian is specified in > the > >> charset), but before transfer encoding. > > > > Definitely not. The HTTP entity body (raw octets, as defined in > > section 7.2 of RFC 2616) should be hashed. No transformation should > > ever be done. This matches the definition of content-md5 in section > > 14.15 of RFC 2616. > > +1 I prefer signing the raw octets. > > Though, reading John's reply, I can see the problem where the > application does not have access to the chuncked or compressed body. > > It seems that everyone is agreeing on this conceptually. Where we're > running into problems is with character data, which is of course the > common case. If we mandate that the content's encoding be included > in the Content-Type header, we can probably address this. This way, > for encodings like UTF16 it can be specified. Alternatively, mandate > UTF8. > > I'd certainly hope nobody really wants to sign the body after > factoring in compression and other transfer encoding > transformations. That would make the specification utterly worthless > because of intermediaries (libraries, proxies, etc.) that would need > to change it. > > In a nutshell: > > hash = sha1(convertToBytes(data, "UTF-8")) > > not > > hash = sha1(convertToTransferEncodedData(convertToBytes(data, > "UTF-8"))
I don't think the character set is that interesting, just take the octets as sent, but before compression etc. > > I agree normalizing HTTP headers is tricky. Given that it provides > > negligible security benefit and is likely to cause interoperability > > problems, we shouldn't do it. > > At least we can agree on which headers to normalize and hash. The > generic case is quite hard, in the case of Content-Type, Content- > Length, Content-Language and Content-Encoding (to name a few) it is > quite doable. > > I propose the following normalisation: > 1. Remove all whitespace characters (space, tab, cr, lf) > 2. Translate to lowercase (assuming ANSI codes) > > And for Content-Type: > 3. Split on ';', sort all parameters, reconcatenate using ';' > > And discard quotes (Content-Type: text/html;encoding="utf8"). > > Oh and encoding strings don't seem to be standardized. Is it "utf8", > "UTF8", "UTF-8", or "utf-8"? > > Is it really worth this headache? I wouldn't expect any intermediate messing with the character set definition as supplied in the content-type header. Does anybody have an example of an intermediate changing the content- type header? An alternative is that the consumer just adds some extra parameters describing the content-type sent, it is up to the provider to check this against the content-type received. - Marc Worrell --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
