Re: [saag] Liking Linkability

Ben Laurie <benl@google.com> Fri, 19 October 2012 11:21 UTC

Return-Path: <benl@google.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 9A28221F8532 for <saag@ietfa.amsl.com>; Fri, 19 Oct 2012 04:21:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level:
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 v4tQMXbPVP8P for <saag@ietfa.amsl.com>; Fri, 19 Oct 2012 04:21:49 -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 41F9F21F846F for <saag@ietf.org>; Fri, 19 Oct 2012 04:21:49 -0700 (PDT)
Received: by mail-we0-f172.google.com with SMTP id u46so223300wey.31 for <saag@ietf.org>; Fri, 19 Oct 2012 04:21:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=jzuSGLhgrPRyVoanRI3/AVjVPiaISms9g/EGnO22mi8=; b=hW+/zrPAwq9dlTTG6ULuYAgdfWOeh9+nT/fYYgx5w2EmuJ6ScsdiW4238Mcyh1UDLd 3a7qJEhwMpr/l7ZzKbU+1EyqQaAGwDvuhiv28KWWRnMWbsnfSmp09BViLHKC4rPAYM6e kV7dpq9HDaRayYJGMpJdYROQ5PimckuEIfwp8owG/cyUmfm8fOJ5quWg/9l/IYnJdGeb XG0BiBHKsCUlV0oqmR0REeDI+NZfDr/zKBGFkflzy3AXD94L9J2+qn5cEGZaGe2OE0qu tz7RNEYHIR8lakR25zenkwz+YPrzMwzmVI8puIoTD7Q1fcwapOgEQGYmOQ5Gr/9vQmvt 9irA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=jzuSGLhgrPRyVoanRI3/AVjVPiaISms9g/EGnO22mi8=; b=RSxsgVYj+YbHgfa2/fFKiFW/7ktuf5mRUpNjQHwKKIhYLH09ciwaS/B7Uxo85YiDWB bOgAN0Tit6Q/GpStxYCv5lsNUEnbK5JWnS5qgUr7sK3tACJH54x2kywM+Ov8A32BTprg VHG0xxzHoLcTudY81fGYgEvqnRHRlVYiEohJfKJ+34D2I5sPxtIaubGwy+TyXpJylJvg tZmx+xR3aVcnBe2yH0BUK7ileU+GMTZlViW6aZsKYL64EzAs6pcpg/PpwxUoM4cXwb8e FyZEEVVKzUpNAcbdC1JPicomVkevR86obuchyY7gb5Mw2lGzHc0/8AtEPmcCOChldUiI nz6A==
MIME-Version: 1.0
Received: by 10.216.131.161 with SMTP id m33mr657098wei.13.1350645707821; Fri, 19 Oct 2012 04:21:47 -0700 (PDT)
Received: by 10.216.236.201 with HTTP; Fri, 19 Oct 2012 04:21:47 -0700 (PDT)
In-Reply-To: <508033C3.1010205@openlinksw.com>
References: <88F98DFD-EF7D-4444-A9C2-FB8E15F5DA89@bblfish.net> <3757D928-C3AE-4630-98E7-E30B5CC604B0@cisco.com> <C8B17065-FD7A-4E4C-B423-4FAB02A48A6D@bblfish.net> <7E1636E02F313F4BA69A428B314B77C708217189@xmb-aln-x12.cisco.com> <7ABCD095-4B09-40DD-A084-1BBE761CA72F@bblfish.net> <CABrd9SRqZN5Bm6rHmduUxXW4ED0yPTxU148Y3txLPjPhbA=hpQ@mail.gmail.com> <50802328.70205@openlinksw.com> <CABrd9SS2cdB6QrWPPzH51L5vphiokZqBJ6nbJ4gOg2uFcwTYUQ@mail.gmail.com> <508033C3.1010205@openlinksw.com>
Date: Fri, 19 Oct 2012 12:21:47 +0100
Message-ID: <CABrd9SSYscbBiNzDZikgHr3hxuD+OV91coZCck7V-6Kknz+kVQ@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: Kingsley Idehen <kidehen@openlinksw.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQlxC8b588d/u3D5rjPVes0WYMx/7SL/Tl4wEZ06w11zq8eJQijo8dSTJX9LVRd8rfjpYkGmEdXel58ecj8f+r99iQMQRV6G+tyB9k6aLHvN9qAcDy2lWJu8hiXmeaXa0AEe54hNfiGMFl6zBkMMDQE2NaWkJ0Tu59T6H1D4GZ0kX7XFdnO0lWGSgViub6GI6vnFw82/
Cc: "public-philoweb@w3.org" <public-philoweb@w3.org>, "public-identity@w3.org" <public-identity@w3.org>, "saag@ietf.org" <saag@ietf.org>, "public-privacy@w3.org" <public-privacy@w3.org>, "Klaas Wierenga (kwiereng)" <kwiereng@cisco.com>, "public-webid@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: Fri, 19 Oct 2012 11:21:50 -0000

On 18 October 2012 17:52, Kingsley Idehen <kidehen@openlinksw.com> wrote:
> On 10/18/12 12:06 PM, Ben Laurie wrote:
>>
>> On 18 October 2012 16:41, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>>>
>>> On 10/18/12 11:34 AM, Ben Laurie wrote:
>>>>
>>>> On 9 October 2012 14:19, Henry Story <henry.story@bblfish.net> wrote:
>>>>>
>>>>> Still in my conversations I have found that many people in security
>>>>> spaces
>>>>> just don't seem to be  able to put the issues in context, and can get
>>>>> sidetracked
>>>>> into not wanting any linkability at all. Not sure how to fix that.
>>>>
>>>> You persist in missing the point, which is why you can't fix it. The
>>>> point is that we want unlinkability to be possible. Protocols that do
>>>> not permit it or make it difficult are problematic. I have certainly
>>>> never said that you should always be unlinked, that would be stupid
>>>> (in fact, I once wrote a paper about how unpleasant it would be).
>>>>
>>>> As I once wrote, anonymity should be the substrate. Once you have
>>>> that, you can the build on it to be linked when you choose to be, and
>>>> not linked when you choose not to be. If it is not the substrate, then
>>>> you do not have this choice.
>>>>
>>>>
>>>>
>>>>
>>> Do you have example of what you describe? By that question I mean:
>>> implicit
>>> anonymity as a functional substrate of some realm that we experience
>>> today?
>>
>> That's what selective disclosure systems like U-Prove and the PRIME
>> project are all about.
>>
>>
>>
> Ben,
>
> How is the following incongruent with the fundamental points we've been
> trying to make about the combined effects of URIs, Linked Data, and Logic en
> route to controlling privacy at Web-scale?
>
> Excerpt from Microsoft page [1]:
>
> A U-Prove token is a new type of credential similar to a PKI certificate
> that can encode attributes of any type, but with two important differences:
>
> 1) The issuance and presentation of a token is unlinkable due to the special
> type of public key and signature encoded in the token; the cryptographic
> “wrapping” of the attributes contain no correlation handles. This prevents
> unwanted tracking of users when they use their U-Prove tokens, even by
> colluding insiders.
>
> 2) Users can minimally disclose information about what attributes are
> encoded in a token in response to dynamic verifier policies. As an example,
> a user may choose to only disclose a subset of the encoded attributes, prove
> that her undisclosed name does not appear on a blacklist, or prove that she
> is of age without disclosing her actual birthdate.
>
>
> Why are you assuming that a hyperlink based pointer (de-referencable URI)
> placed in the SAN of minimalist X.509 certificate (i.e., one that has now
> personally identifiable information) can't deliver the above and more?

Because it contains "correlation handles" to use the terminology of the quote.

> Please note, WebID is a piece of the picture. Linked Data, Entity
> Relationship Semantics and Logic are other critical parts. That's why there
> isn't a golden ontology for resource access policies, the resource publisher
> can construct a plethora of resource access policies en route to leveraging
> the power of machine discernible entity relationship semantics and
> first-order logic.
>
> In a most basic super paranoid scenario, if I want to constrain access to a
> resource to nebulous entity "You" I would share a PKCS#12 document with that
> entity. I would also have an access policy in place based on the data in
> said document. I would also call "You" by phone to give you the password of
> that PKCS#12 document. Once that's all sorted, you can open the document,
> get your crytpo data installed in your local keystore and then visit the
> resource I've published :-)
>
> Links:
>
> 1. http://research.microsoft.com/en-us/projects/u-prove/
> 2. http://en.wikipedia.org/wiki/Zero-knowledge_proof -- I don't see anything
> about that being incompatible with what the combined use of de-referencable
> URIs based names, Linked Data, Entity Relationship Semantics, Reasoning, and
> existing PKI deliver.
>
>
> --
>
> Regards,
>
> Kingsley Idehen
> Founder & CEO
> OpenLink Software
> Company Web: http://www.openlinksw.com
> Personal Weblog: http://www.openlinksw.com/blog/~kidehen
> Twitter/Identi.ca handle: @kidehen
> Google+ Profile: https://plus.google.com/112399767740508618350/about
> LinkedIn Profile: http://www.linkedin.com/in/kidehen
>
>
>
>
>