Not arguing pro or con using this for HTTP message signing, but clarifying a few points:
On Tue, Feb 9, 2010 at 9:59 AM, Richard L. Barnes <[email protected]> wrote: > Could you clarify how you think it's relevant? > > ISTM that the major parts of the document are: > -- Format for encoding a signature on arbitrary binary data > -- Key discovery process > > I don't think it really makes sense to use the magic envelope format for > signing HTTP requests, mainly because there's no need to replicate the data > (since TCP guarantees that the recipient gets same sequence of bytes that > was sent). Only if you consider the 'recipient' and 'sender' to be the actual machines talking to the raw sockets. But fewer and fewer people are doing that today. Everyone is at least relying on an HTTP library (so the chunked encoding details are hidden from you), and most everybody is sitting on top of a stack or embedded within a framework that they can't easily change. E.g., by the time a message goes through Apache and to a JSP servlet container, it may well have already normalized data and converted character sets (by default you definitely get data converted to UCS-2 of course). And then of course there are proxies :). > The only things in the signature besides the data are the > encoding/algorithm IDs and the signature, which is a small enough, > constrained enough set of information that the encoding isn't a huge deal. > > In particular, the magic signature system doesn't address what parts of the > HTTP request get signed, and how they get normalized -- the hard question of > OAuth. All it really does is raise the idea of just blindly signing bytes, > which might be a good idea here: Just take the whole HTTP request with the > OAuth header removed and sign/verify it as a sequence of bytes. That sort of > signature probably wouldn't survive things like proxies, though. > The Magic Signature spec is unabashedly an enveloping system that takes the bytes and armors them. If you are dealing with a system that MUST understand your signature algorithm, you then don't have any need to send the original bytes, just the armored ones. (And do you really want someone relying on unsigned bytes?) At which point, if you're doing HTTP requests, you're effectively tunneling an HTTP request (the important part) inside a request payload. It's very, very ugly, and (it seems to me) is basically replicating SSL but at the wrong layer. > > Are you proposing to use the key discovery process? Even there, it doesn't > seem like there's a whole lot of utility, given that the other major work of > this group is defining a key management system. > I do hope that the key discovery process (starting from an identifier for an author/sender identifier) is something that is re-usable and generic. And specifically, if I have an OAuth public key signed message, along with an identifier for the service that signed it, I would very much like to use this mechanism for discovering public key(s) for the service. Since we can represent both services and people as URIs this seems fairly straightforward and reasonable. > > Just confused, > --Richard > > > > > On Feb 9, 2010, at 8:15 AM, Eran Hammer-Lahav wrote: > > >> http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html >> >> This is relevant to our discussion about how to apply signatures to HTTP >> requests. >> >> EHL >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
