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

Michael Thomas <mike@mtcc.com> Sun, 21 April 2013 21:40 UTC

Return-Path: <mike@mtcc.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 1446B21F929E; Sun, 21 Apr 2013 14:40:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 DVJbjoVjEnYy; Sun, 21 Apr 2013 14:40:10 -0700 (PDT)
Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 6916C21F8D2C; Sun, 21 Apr 2013 14:40:10 -0700 (PDT)
Received: from piolinux.mtcc.com (65-172-209-232.dsl.volcano.net [65.172.209.232]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r3LLduT2019446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Apr 2013 14:39:57 -0700
Message-ID: <51745CA7.20907@mtcc.com>
Date: Sun, 21 Apr 2013 14:39:51 -0700
From: Michael Thomas <mike@mtcc.com>
User-Agent: Thunderbird 2.0.0.14 (X11/20080501)
MIME-Version: 1.0
To: Manu Sporny <msporny@digitalbazaar.com>
References: <5170652F.60609@digitalbazaar.com> <87A0FB6A602993DC8BFA8CC3@caldav.corp.apple.com> <5174578E.70601@digitalbazaar.com>
In-Reply-To: <5174578E.70601@digitalbazaar.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1807; t=1366580397; x=1367444397; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20<mike@mtcc.com> |Subject:=20Re=3A=20[http-auth]=20[apps-discuss]=20Web=20Ke ys=20and=20HTTP=20Signatures |Sender:=20 |To:=20Manu=20Sporny=20<msporny@digitalbazaar.com> |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=s8EamIKRYfgcDQbZV7K8irnk6CgAclrNO7VNDDijtCg=; b=tVQevi6VdKP3D7+1LO0qrBaitfThrfpqkgv0VqY/Z2C0mr7X3DLE4Vl78K 4Z1ItGQHZysnjEp1JkTB86xpq+yPqwTOKCFLOUs1XC8pQIfw72UKbytxT8dK k+/xDQ2iXI9sw9BzqyMoslnAYIq4Ior6SIXkMSb9fMuEhp3lvN3Ds=;
Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com
X-Mailman-Approved-At: Mon, 22 Apr 2013 00:17:37 -0700
Cc: IETF HTTP Auth <http-auth@ietf.org>, IETF Apps Discuss <apps-discuss@ietf.org>, Web Payments CG <public-webpayments@w3.org>
Subject: Re: [apps-discuss] [http-auth] 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:40:11 -0000

Manu Sporny wrote:
> 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.


You can have any number of selectors per domain. Selectors can be delegated
as needed (or not). Whether it's a good idea to have zillions of records served
by given zone is another matter. I assume that an untrusted client has a selector.
That is another thing that's worth considering because the use case it's been
deployed with is mainly ~trustable entities. I don't see why that would be problem
off the top of my head, but it's worth thinking about.

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

DKIM uses DNS to store raw public keys. No more, no less. It is linked to
a domain insofar as the domain's owners/managers determines what is populated
in its zone files. The bigger issue in my mind is whether you need DNSSEC.
For mail signing, it was an acceptable risk to not have the keys themselves
be signed. If you require that level of protection, then it implies DNSSEC
and all of the machinery behind it. Which isn't to say it's not possible,
just TANSTAAFL.

Mike