Re: [saag] Liking Linkability

Melvin Carvalho <melvincarvalho@gmail.com> Wed, 24 October 2012 14:24 UTC

Return-Path: <melvincarvalho@gmail.com>
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 42B1C21F86F6 for <saag@ietfa.amsl.com>; Wed, 24 Oct 2012 07:24:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.288
X-Spam-Level:
X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 suUEXpXSNaEO for <saag@ietfa.amsl.com>; Wed, 24 Oct 2012 07:24:27 -0700 (PDT)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1655D21F86AA for <saag@ietf.org>; Wed, 24 Oct 2012 07:24:27 -0700 (PDT)
Received: by mail-ie0-f172.google.com with SMTP id 9so868858iec.31 for <saag@ietf.org>; Wed, 24 Oct 2012 07:24:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5GnuLfdNr0thDykrpZ3w6WzaCgCEsLDjihB9e99iOu8=; b=q6EP5ZWTxmalxQ/XOeXR6QWPbquxuhzzOBpeJN6n08MX48zB/KRBYvpWcYe31NLRzA CISS1e8Abta5qTNlClxAwF8B4C5T94TnhXIEFXtXW9BbNJFT4CKoF2BUKzCV5Qh2N2uL 1/UNDAR4LoSnyBAkF9CBksV2+Semu3L2/8P178GquBAJ+h0eh6op70TlLypSiKmguY3u ChhNTPGr5DTrUwBQmkj4TR2s83UAnx244ElV+T/1KbVFvb9v5Oo7hX8FBomz4yhr87kb NcQWe+P2DQtSfRQ9v9NJl8mmEuNATAOKfwT82J1ikYuqgUQRCLmEbhJ0LQ2pfle85C75 XQtg==
MIME-Version: 1.0
Received: by 10.50.193.131 with SMTP id ho3mr1082477igc.51.1351088666583; Wed, 24 Oct 2012 07:24:26 -0700 (PDT)
Received: by 10.42.247.129 with HTTP; Wed, 24 Oct 2012 07:24:26 -0700 (PDT)
In-Reply-To: <5087F51D.3040503@openlinksw.com>
References: <CCA5E789.2083A%Josh.Howlett@ja.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> <3EF3A430-A6C5-4ADE-92B5-0744DFFD326B@isoc.org> <CABrd9SQxy3GjKekrrCPikqRBt4z2PdzbOhzZUsDC6asZNSiu0A@mail.gmail.com> <E8AC244A-1D90-49F2-BD8A-2CF13E11D4B7@isoc.org> <5087D92D.8000207@webr3.org> <5087F51D.3040503@openlinksw.com>
Date: Wed, 24 Oct 2012 16:24:26 +0200
Message-ID: <CAKaEYhKhkeNLe6LC5fgtjcZZ-L4FbpXDujRzn3zpwNOgNY=HBg@mail.gmail.com>
From: Melvin Carvalho <melvincarvalho@gmail.com>
To: Kingsley Idehen <kidehen@openlinksw.com>
Content-Type: multipart/alternative; boundary="14dae934106308233a04ccced8e9"
X-Mailman-Approved-At: Thu, 25 Oct 2012 08:21:39 -0700
Cc: Halpin Harry <H.halplin@ed.ac.uk>, Robin Wilton <wilton@isoc.org>, nathan@webr3.org, 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
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 14:24:28 -0000

On 24 October 2012 16:03, Kingsley Idehen <kidehen@openlinksw.com> wrote:

> On 10/24/12 8:03 AM, Nathan wrote:
>
>> 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.
>>
>>
>>
>>
> For sake of clarity, Nathan is speaking about the WebID authentication
> protocol.
>
> A WebID on its own refers to an resolvable (de-referencable) identifier.
> The WebID protocol verifies the aforementioned identifier (entity
> denotation mechanism) via a combination of cryptography and entity
> relationship semantics oriented logic.


Kingsley, thanks for pointing this out.

I think some of the confusion arises from the fact that a webid is
sometimes not that clearly defined, and people focus on the protocol.

In particular a WebID is a URI that references an Agent (human or machine)

Similarly, email will become WebIDs using the webfinger spec (when that's
complete)

It can be argued that OAuth/OpenID identifiers are also WebID but with a
different auth protocol.

Mozilla persona, although certainly useful, would possibly not fit into the
same category, as they use a proprietary identification system.

The whole idea is that WebID brings things together at an architectural
level.  "The WebID Protocol", certs, X.509 are implementation details
really.


>
>
> --
>
> Regards,
>
> Kingsley Idehen
> Founder & CEO
> OpenLink Software
> Company Web: http://www.openlinksw.com
> Personal Weblog: http://www.openlinksw.com/**blog/~kidehen<http://www.openlinksw.com/blog/~kidehen>
> Twitter/Identi.ca handle: @kidehen
> Google+ Profile: https://plus.google.com/**112399767740508618350/about<https://plus.google.com/112399767740508618350/about>
> LinkedIn Profile: http://www.linkedin.com/in/**kidehen<http://www.linkedin.com/in/kidehen>
>
>
>
>
>
>