W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2011

Re: Feedback on draft-burke-content-signature-00.txt

From: Bill Burke <bburke@redhat.com>
Date: Fri, 25 Mar 2011 19:34:26 +0000
Message-ID: <4D8CEE14.9080807@redhat.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:37 GMT