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

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

From: Eran Hammer-Lahav <eran@hueniverse.com>
Date: Fri, 25 Mar 2011 08:21:18 -0700
To: Cyrus Daboo <cyrus@daboo.name>, Mark Nottingham <mnot@mnot.net>
CC: "Thomson, Martin" <Martin.Thomson@commscope.com>, Bill Burke <bburke@redhat.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234465642FEFF@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Reusing an existing (working) mechanism is always a good idea.

Understanding the use cases for signing random headers is important. Email and HTTP are very different when it comes to deployment. Yes, both suffer from similar issues with intermediaries, and HTTP headers are similar to those of SMTP, but DKIM operates in a much friendlier environment, and a much smaller development range.

If this solution can only be fully implemented at a very low level - right above HTTP as even as part of the HTTP layer - most developers will not be able to use it for a long time. I know this group likes to dismiss real-world considerations, and sometimes that's the right approach for making progress, but there is an opportunity here to provide a useful solution that is widely applicable.

Some may say that if the consumer web world (e.g. Twitter, Facebook, Yahoo, Google, etc.) doesn't use this because it too complex or too hard to deploy with all the existing crappy framework used, that's ok. Maybe it is. But it only means that people will continue to come up with yet new ways to accomplish pretty much the same thing. Oh well.

OAuth 1.0 and the 2.0 companion MAC token specs both sign HTTP requests in a limited way that is optimized for deployment. During the three years this has been in development, no use cases for signing random headers were presented.

Recent efforts (which I am strongly opposed to) are trying to define a way to normalize the HTTP request into a JSON object, base64 and sign it, and include the base64 blob with the request. This is part of the JSON token proposal. It basically means using HTTP as a stupid transport and repeating all the important details in the signed blob (including the request URI, HTTP method, etc.). The reason I am mentioning this is to demonstrate what happens when no alternative practical solution is offered.

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.

EHL

> -----Original Message-----
> From: Cyrus Daboo [mailto:cyrus@daboo.name]
> Sent: Friday, March 25, 2011 7:29 AM
> To: Eran Hammer-Lahav; Mark Nottingham
> Cc: Thomson, Martin; Bill Burke; HTTP Working Group
> Subject: RE: Feedback on draft-burke-content-signature-00.txt
> 
> Hi Eran,
> 
> --On March 23, 2011 11:47:45 PM -0700 Eran Hammer-Lahav
> <eran@hueniverse.com> wrote:
> 
> > No matter what the use cases are, most signature algorithm requiring
> > complex canonicalization of data have failed the test of widespread
> > adoption, so before we produce yet another such solutions, we should
> > figure out if this complexity adds real value.
> 
> Please take a look at DKIM which does this for email (and reasonably well by
> most accounts). In fact my preference here is to use DKIM for HTTP as well.
> Whilst DKIM is currently used for email it was designed to be generally
> applicable to similar protocols - in fact we are planning on using it for iTIP-
> over-HTTP (iSchedule:
> <http://tools.ietf.org/id/draft-desruisseaux-ischedule-01.txt>). It would be
> good to be able to utilize the existing infrastructure and experience from
> DKIM in HTTP.
> 
> --
> Cyrus Daboo
Received on Friday, 25 March 2011 15:22:06 GMT

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