Re: [apps-discuss] Web Keys and HTTP Signatures

Cyrus Daboo <cyrus@daboo.name> Fri, 19 April 2013 15:33 UTC

Return-Path: <cyrus@daboo.name>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7708A21F8E48; Fri, 19 Apr 2013 08:33:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbGJPzd-RjyJ; Fri, 19 Apr 2013 08:33:54 -0700 (PDT)
Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 833C121F8F45; Fri, 19 Apr 2013 08:33:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 06D1541A2A7C; Fri, 19 Apr 2013 11:33:54 -0400 (EDT)
X-Virus-Scanned: amavisd-new at example.com
Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdkhLuDa--nT; Fri, 19 Apr 2013 11:33:53 -0400 (EDT)
Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 03ADA41A2A6E; Fri, 19 Apr 2013 11:33:51 -0400 (EDT)
Date: Fri, 19 Apr 2013 11:33:48 -0400
From: Cyrus Daboo <cyrus@daboo.name>
To: Manu Sporny <msporny@digitalbazaar.com>, IETF HTTP Auth <http-auth@ietf.org>, IETF Apps Discuss <apps-discuss@ietf.org>
Message-ID: <87A0FB6A602993DC8BFA8CC3@caldav.corp.apple.com>
In-Reply-To: <5170652F.60609@digitalbazaar.com>
References: <5170652F.60609@digitalbazaar.com>
X-Mailer: Mulberry/4.1.0a3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size=1912
Cc: Web Payments CG <public-webpayments@w3.org>
Subject: Re: [apps-discuss] Web Keys and HTTP Signatures
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Apr 2013 15:33:55 -0000

Hi Manu,

--On April 18, 2013 at 5:27:11 PM -0400 Manu Sporny 
<msporny@digitalbazaar.com> wrote:

> My name is Manu Sporny. I'm the current Chair of the W3C RDFa WG, JSON
> for Linking Data (JSON-LD) CG, and Web Payments CG. I am also an editor
> of various W3C specs and member of the HTML WG and RDF WG.
>
> There is a relatively new spec at W3C called Web Keys[1] that now
> supports HTTP Signatures[2]. It is being worked on as a part of the Web
> Payments[3] work. Specifically, the PaySwarm[4] specifications use Web
> Keys and HTTP request signatures.
>
> We'd like to coordinate with the IETF on this work to make sure we have
> all parties interested in solving this problem involved in the work. We
> would also like more eyes doing security audits[5] on the protocol.

> [2]
> https://github.com/joyent/node-http-signature/blob/master/http_signing.md

That draft is very similar to the approach we have used in iSchedule 
(<https://datatracker.ietf.org/doc/draft-desruisseaux-ischedule/>) - which 
is an HTTP-based calendar and scheduling messaging protocol.

We choose to re-use existing email signing technology - DKIM 
(<http://tools.ietf.org/html/rfc6376>) - primarily because the security 
model and key management were a good fit for our application. There is also 
the benefit of code re-use, and working with a protocol that is already 
deployed and used heavily in the email environment. Also, DKIM was designed 
with the prospect of being applicable to protocols beyond email technology 
- and I think with iSchedule we have proven it can work with HTTP.

I would definitely urge you to take a serious look at DKIM. There are a 
number of interesting features there that don't seem to have been addressed 
in the draft you cited. In particular dealing with both header and body 
canonicalization (headers are particular problem in HTTP due to 
intermediaries, caches etc).

-- 
Cyrus Daboo