Re: [saag] Liking Linkability

Nathan <nathan@webr3.org> Wed, 24 October 2012 12:04 UTC

Return-Path: <nathan@webr3.org>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B42421F8B71 for <saag@ietfa.amsl.com>; Wed, 24 Oct 2012 05:04:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level:
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phXMFucG9cJF for <saag@ietfa.amsl.com>; Wed, 24 Oct 2012 05:04:41 -0700 (PDT)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5150021F8B70 for <saag@ietf.org>; Wed, 24 Oct 2012 05:04:41 -0700 (PDT)
Received: by mail-we0-f172.google.com with SMTP id u46so252786wey.31 for <saag@ietf.org>; Wed, 24 Oct 2012 05:04:40 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=VXdHd5G3wHOT0+eFYc6B1/Tsnn6j4+4gA2qbuWrCLDo=; b=BKYz0z4bOqDj/CVBadOWVnoLapz9t5Uc9B06idH2qbtf2EXDlAntRPHeh1ZA0iAoN8 ksGugVR/6ay15bYjK1a4AhbfefjhB7pSucA1A+aquutye0Zr6iLuEkDUgSBQFfEG8m2z yMNa37GCU5CKLwpUQ5hCeA4WK8+wRG0Aaluk5wl1VHqEsG9J5ipwRP0c8RegV8rkyHwS 5RMMdaaRlzVPrwJcwqU2/r9wZIrgkKErHBXF/xN8UEczU71PFr/NhncQABwHGM+2E7oz 9N4A1DXkz3VUTUe5DcpncW3kQIQV7LznMt7zKi/kZnj8we6oETJhKfOuFMU6g11WS1aK u45Q==
Received: by 10.180.101.230 with SMTP id fj6mr5421895wib.16.1351080280447; Wed, 24 Oct 2012 05:04:40 -0700 (PDT)
Received: from [192.168.1.69] (host217-44-74-203.range217-44.btcentralplus.com. [217.44.74.203]) by mx.google.com with ESMTPS id p4sm4596239wix.0.2012.10.24.05.04.37 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Oct 2012 05:04:39 -0700 (PDT)
Message-ID: <5087D92D.8000207@webr3.org>
Date: Wed, 24 Oct 2012 13:03:57 +0100
From: Nathan <nathan@webr3.org>
Organization: webr3
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Robin Wilton <wilton@isoc.org>
References: <CCA5E789.2083A%Josh.Howlett@ja.net> <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net> <CABrd9SQghpi6_rVQKxYXZDtM5HwvE7Kq7SUw5zi41ZRd3y2h9A@mail.gmail.com> <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> <CABrd9SQU1uYVaVPedokHxeYkT=759rkPFfimWK1Z8ATzo3yNFA@mail.gmail.com> <5083CCCF.2060407@webr3.org> <50842789.3080301@openlinksw.com> <50845268.4010509@webr3.org> <5084AC77.8030600@openlinksw.com> <50851512.9090803@webr3.org> <CABrd9SRNVLbWxifQAQ6iuX4qMeFmZVD6rO_q=L348G1UZzr9tg@mail.gmail.com> <50852726.9030102@openlinksw.com> <CABrd9SQ3KTqHq1hOfbLAU5hfgNyqCPK4u+ToEda+VtQ5S0utwA@mail.gmail.com> <5085360E.3080008@openlinksw.com> <50853CD8.8020005@w3.org> <5FB468E4-BDD3-4635-ACD0-A23540C08751@bblfish.net> <508562C2.1060905@w3.org> <CAG5KPzx673VKqg4=26-cvfeXZrBfK-XbURFj 8eYx_mXVkko41A@mail.gmail.com> <3EF3A430-A6C5-4ADE-92B5-0744DFFD326B@isoc.org> <CABrd9SQxy3GjKekrrCPikqRBt4z2PdzbOhzZUsDC6asZNSiu0A@mail.gmail.com> <E8AC244A-1D90-49F2-BD8A-2CF13E11D4B7@isoc.org>
In-Reply-To: <E8AC244A-1D90-49F2-BD8A-2CF13E11D4B7@isoc.org>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Gm-Message-State: ALoCoQlkKJWwpwNHQfn4tidRcENptn4gNB4zTbkxp5h4HFmsSWY2YPyg0rms8hmQ71zLOS1QsmRv
X-Mailman-Approved-At: Thu, 25 Oct 2012 08:21:39 -0700
Cc: Halpin Harry <H.halplin@ed.ac.uk>, public-identity@w3.org, saag@ietf.org, "public-privacy@w3.org list" <public-privacy@w3.org>, public-webid@w3.org
Subject: Re: [saag] Liking Linkability
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: nathan@webr3.org
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Oct 2012 12:04:42 -0000

Robin Wilton wrote:
> 
> 
> 
> 
>  
> Robin Wilton
> Technical Outreach Director - Identity and Privacy
> Internet Society
> 
> email: wilton@isoc.org
> Phone: +44 705 005 2931
> Twitter: @futureidentity
> 
> 
> 
> 
> On 24 Oct 2012, at 10:30, Ben Laurie wrote:
> 
>> On 23 October 2012 10:58, Robin Wilton <wilton@isoc.org> wrote:
>>>
>>> On 23 Oct 2012, at 09:44, Ben Laurie wrote:
>>>
>>> <snip>
>>>
>>>
>>> Not disagreeing with any of the above, but observing that:
>>>
>>> a) There's no particular reason you could not have an email per site
>>> as well as a key per site.
>>>
>>> b) Linkability it not, as you say, inherently bad. The problem occurs
>>> when you have (effectively) no choice about linkability.
>>>
>>>
>>>
>>> But it's very hard to use either of those mechanisms (separation through
>>> emails or keys) without giving some third party the ability to achieve total
>>> linkability. (In other words, both options remove effective choice).
>> I agree that emails are a problem, but not at all sure why keys are?
>> In the case of appropriate selective disclosure mechanisms, even if
>> there were a third party involved, they would not be able to link uses
>> of the keys. Also, if you insist on using linkable keys, then per-site
>> keys do not involve third parties.
>>
> 
> It may just be that I'm not getting a clear mental picture of your architecture. But here was my thinking: 
> 
> - If you use symmetric keys, you get a system which can't scale unless you opt for Schneier's idea of a key server… but then the key server becomes a point of potential panopticality.
> 
> - If you use PKI, *and* you want your communicating parties to be able to validate the certs they're relying on, then you have to design a CRL- or OCSP-like mechanism into the architecture, and again you end up with a component which is potentially panoptical. (Plus, you have to address the 20-year-old problem of how to make PKI usable by human beings, when recent history suggests that PKI only takes off where human beings are kept well away from it).

CRL is pretty much built in to WebID, if you remove a public key from 
the document pointed to by your uri-identifier, then it's no longer 
valid for use in WebID - auth can't happen, rendering the cert useless 
for WebID.