Re: [saag] Liking Linkability

On 24 October 2012 12:26, Robin Wilton <wilton@isoc.org> 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.

Symmetric keys obviously don't work.

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

Per-site keys don't really need the I in PKI, just the PK. Revocation
need not be centralised - I am not saying it is trivial, but it is
akin to the problem of forgotten or compromised passwords.

Also, it is possible to blacklist using selective disclosure - i.e.
detect whether a key has been revoked without revealing the key.

Received on Wednesday, 24 October 2012 11:32:34 UTC