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

Manu Sporny <msporny@digitalbazaar.com> Sun, 21 April 2013 21:18 UTC

Return-Path: <msporny@digitalbazaar.com>
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 3657D21F8B5F; Sun, 21 Apr 2013 14:18:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level:
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 XNXlNVAwMeUz; Sun, 21 Apr 2013 14:18:19 -0700 (PDT)
Received: from mail.digitalbazaar.com (unknown [216.252.204.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFC321F8682; Sun, 21 Apr 2013 14:18:19 -0700 (PDT)
Received: from [192.168.100.5] by mail.digitalbazaar.com with esmtp (Exim 4.72) (envelope-from <msporny@digitalbazaar.com>) id 1UU1eF-0003sw-U2; Sun, 21 Apr 2013 17:18:13 -0400
Message-ID: <5174578E.70601@digitalbazaar.com>
Date: Sun, 21 Apr 2013 17:18:06 -0400
From: Manu Sporny <msporny@digitalbazaar.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20120510 Icedove/10.0.4
MIME-Version: 1.0
To: Cyrus Daboo <cyrus@daboo.name>
References: <5170652F.60609@digitalbazaar.com> <87A0FB6A602993DC8BFA8CC3@caldav.corp.apple.com>
In-Reply-To: <87A0FB6A602993DC8BFA8CC3@caldav.corp.apple.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 22 Apr 2013 00:18:06 -0700
Cc: IETF HTTP Auth <http-auth@ietf.org>, Web Payments CG <public-webpayments@w3.org>, IETF Apps Discuss <apps-discuss@ietf.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: Sun, 21 Apr 2013 21:18:20 -0000

On 04/19/2013 11:33 AM, Cyrus Daboo wrote:
>> 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.

Thanks for the pointer to the draft. I skimmed it and I agree that there
are a number of very interesting similarities.

> 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.

Yes, it seems like a very applicable technology for your use case. The
one thing I missed is whether or not DKIM allows multiple identities per
user in a domain? Does it let users create as many sub-accounts as they
want and associate keys with them? Anything is possible, what I'm asking
is if this is something that is standardized. Access to DNS places a
pretty high bar and we were hoping to lower that by a significant amount
with Web Keys.

>From my understanding, DKIM defines a domain-level digital signature
authentication framework. WebKeys defines a identity-level digital
signature authentication framework.

Where DKIM uses the DNS system to discover key information for a domain.
Web Keys uses the Web and Linked Data formats to discover key
information for a particular identity.

> 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).

Yes, Proxy header modification is a problem for Web Keys and HTTP
Signatures now. We think we have some working solutions, but won't know
for sure until we get some deployment experience with the protocol (or
someone that has already been through that pain point can let us know
what we're doing wrong).

I agree with you. We need to take a serious look at DKIM and your spec
and figure out if we missed something obvious with Web Keys and HTTP
Signatures. Glancing through your spec sparked a few ideas, so I'm
looking forward to a thorough read and review of it wrt. Web Keys and
HTTP Signatures.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
http://blog.meritora.com/launch/