[+marcw] Thanks for the feedback.
On Tue, Dec 9, 2008 at 9:15 AM, John Hayes <[EMAIL PROTECTED]> wrote: > 1. Include HTTP entity headers: Content-Type, Content-Range, Content-MD5, > Content-Language; they should be combined into a normalized base string, URL > encoded to ascii and concatenated as a prefix with the body. The content > flags can affect how the entity is interpreted > 2. Exclude HTTP transfer encoding headers: Content-Length, TE, > Content-Encoding Marc Worrell made a similar suggestion. My initial proposal was not to bother with this, I would prefer not to include HTTP headers of any type in the signature base string, because I don't see how it fits into a realistic threat model. If an application is so sensitive that the possibility of changing a content-range header creates an unacceptable security risk, that application should probably be using https instead of OAuth over http. Is there a realistic threat here? > 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. > 4. Change parameter name to: oauth_entity_signature; slightly better > indicator that oauth_signature_method applies This is not a signature, since we are not using an HMAC. oauth_entity_hash would be fine by me. > 5. Specify that oauth_entity_signature MUST be included in the > oauth_signature base string if it's present in the request since this > differs from the treatment of oauth_signature. I see it in the example, but > don't repeat the problems OAuth spec by putting critical information only in > the examples or implementation. OK. > 6. State that signing a body is useless without a complete OAuth > authorization header that establishes the requester's identity. This seems kind of vague, how will it be helpful to people implementing the spec? If we're going to give security considerations, they should be actionable. > Normalizating HTTP headers is a lot trickier than query parameters because > they may be rewritten by intermediate proxies and have multiple standard > forms with multi-line or single line representations, case insensitivity and > optional quotes. 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. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
