- From: Bill Burke <bburke@redhat.com>
- Date: Fri, 25 Mar 2011 19:34:26 +0000
- To: Eran Hammer-Lahav <eran@hueniverse.com>
- CC: Cyrus Daboo <cyrus@daboo.name>, Mark Nottingham <mnot@mnot.net>, "Thomson, Martin" <Martin.Thomson@commscope.com>, HTTP Working Group <ietf-http-wg@w3.org>
DKIM looks exactly like what I want. I wish I had found it prior to doing all this work to draft my own protocol. You can have multiple signatures and also add arbitrary tags. The only thing it doesn't seem to support is composing signatures from other signatures. I see this being a very useful feature in workflows where somebody needs to verify that more than one party saw the same representation. The only thing I worry about DKIM is that it imposes a key management structure and infrastructure? The users I deal with will probably want to integrate with existing mechanisms to manage keys and look them up and to verify identity (which will probably be different per user). Specially I want to apply this protocol to enterprise based systems rather than the typical Google/Yahoo/Twitter kind of thing. On 3/25/11 11:21 AM, Eran Hammer-Lahav wrote: > What would be useful is to list the use cases and requirements the author had in mind when drafting this, why signing headers is necessary, and what is lacking in the MAC token proposal that might make it more appealing. > I did look at MAC, other than being design specifically to work with OAuth, it exists specifically to verify the integrity of a message sent between one client and server. The list of use cases and requirements are expressed in a blog I wrote a few weeks ago: http://bill.burkecentral.com/2011/02/21/multiple-uses-for-content-signature/ Bill -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com
Received on Sunday, 27 March 2011 13:06:49 UTC