Re: [saag] Liking Linkability

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

R



> On email, this is a soluble problem, but not without using a
> completely different delivery mechanism.



> 
>> 
>> Yrs.,
>> Robin
>> 
>> _______________________________________________
>> saag mailing list
>> saag@ietf.org
>> https://www.ietf.org/mailman/listinfo/saag
>>