W3C home > Mailing lists > Public > public-privacy@w3.org > October to December 2012

Re: [saag] Liking Linkability

From: Nathan <nathan@webr3.org>
Date: Wed, 24 Oct 2012 13:03:57 +0100
Message-ID: <5087D92D.8000207@webr3.org>
To: Robin Wilton <wilton@isoc.org>
CC: Ben Laurie <benl@google.com>, Ben Laurie <ben@links.org>, 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
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.
Received on Wednesday, 24 October 2012 12:05:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 24 October 2012 12:05:12 GMT