Re: [saag] Liking Linkability
David Chadwick <d.w.chadwick@kent.ac.uk> Thu, 18 October 2012 18:17 UTC
Return-Path: <d.w.chadwick@kent.ac.uk>
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 CAAC821F847B for <saag@ietfa.amsl.com>; Thu, 18 Oct 2012 11:17:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 o+8kD8jfBN3w for <saag@ietfa.amsl.com>; Thu, 18 Oct 2012 11:17:57 -0700 (PDT)
Received: from mx1.kent.ac.uk (mx1.kent.ac.uk [129.12.21.39]) by ietfa.amsl.com (Postfix) with ESMTP id 99C2A21F8470 for <saag@ietf.org>; Thu, 18 Oct 2012 11:17:57 -0700 (PDT)
Received: from mx0.kent.ac.uk ([129.12.21.32]) by mx1.kent.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <d.w.chadwick@kent.ac.uk>) id 1TOufH-0005Il-SB; Thu, 18 Oct 2012 19:17:51 +0100
Received: from [63.133.198.91] (helo=[172.16.13.114]) by mx0.kent.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <d.w.chadwick@kent.ac.uk>) id 1TOufH-00026k-1I; Thu, 18 Oct 2012 19:17:51 +0100
Message-ID: <508047CB.9080008@kent.ac.uk>
Date: Thu, 18 Oct 2012 19:17:47 +0100
From: David Chadwick <d.w.chadwick@kent.ac.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Kingsley Idehen <kidehen@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> <508034BB.7040102@kent.ac.uk> <50803D68.9040206@openlinksw.com>
In-Reply-To: <50803D68.9040206@openlinksw.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Mailman-Approved-At: Mon, 22 Oct 2012 08:25:26 -0700
Cc: "Klaas Wierenga (kwiereng)" <kwiereng@cisco.com>, "public-identity@w3.org" <public-identity@w3.org>, "saag@ietf.org" <saag@ietf.org>, "public-privacy@w3.org" <public-privacy@w3.org>, "public-philoweb@w3.org" <public-philoweb@w3.org>, "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: Thu, 18 Oct 2012 18:17:58 -0000
On 18/10/2012 18:33, Kingsley Idehen wrote: > On 10/18/12 12:56 PM, David Chadwick wrote: >> and if the user puts his/her email address attribute in the U-Prove >> token??? > > Then they've broken un-linkability since a mailto: scheme URI is the > ultimate unit of privacy compromise on today's Internet and Web, yes I know. My main point was that using U-Prove or Idemix is employing a very sophisticated privacy protecting encryption scheme that can easily and trivially be undone by everyday users who provide their email address attributes inside the tokens. So I suspect the applicability of these tokens will be quite limited regards David bearing > in mind the state of the underground personal information networks. > Every social network uses your mailto: scheme URI as a key component. > Even if they don't share this data with 3rd parties, other pieces of the > puzzle come together quite easily due to the fundamental semantics > associated with mailto: scheme URIs i.e., you only need to have them in > an inverseFunctionalProperty relationship for entropy to drive the rest > of the profile coalescence. > > The world I envisage starts with the ability to generate (with ease) > X.509 certificates bearing WebIDs in their SAN slots. We will have many > such certificates for a variety of purposes. An email address or any > other overtly identifiable data isn't a mandatory component an X.509 > certificate :-) > > If I want to send something that's only readable by You, I would encrypt > that email via S/MIME. When I make an access policy or resource ACL I > tend not to require email addresses, for instance [1]. > > Links: > > 1. http://bit.ly/Rbnayv -- some posts about the use of social entity > relationship semantics to constrain access to my personal data space on > the Web. > > Kingsley >> >> David >> >> On 18/10/2012 17:52, Kingsley Idehen 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? >>> >>> 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. >>> >> >> > >
- [saag] Liking Linkability Henry Story
- Re: [saag] Liking Linkability Henry Story
- Re: [saag] Liking Linkability Henry Story
- Re: [saag] Liking Linkability Klaas Wierenga (kwiereng)
- Re: [saag] Liking Linkability Ben Laurie
- Re: [saag] Liking Linkability Ben Laurie
- Re: [saag] Liking Linkability Josh Howlett
- Re: [saag] Liking Linkability Sam Hartman
- Re: [saag] Liking Linkability Mouse
- Re: [saag] Liking Linkability Henry Story
- Re: [saag] Liking Linkability Ben Laurie
- Re: [saag] Liking Linkability Ben Laurie
- Re: [saag] Liking Linkability Henry Story
- Re: [saag] Liking Linkability Henry Story
- Re: [saag] Liking Linkability Ben Laurie
- Re: [saag] Liking Linkability Henry Story
- Re: [saag] Liking Linkability Ben Laurie
- Re: [saag] Liking Linkability Henry Story
- Re: [saag] Liking Linkability Henry Story
- Re: [saag] Liking Linkability Ben Laurie
- Re: [saag] Liking Linkability Ben Laurie
- Re: [saag] Liking Linkability Henry Story
- Re: [saag] Liking Linkability Henry Story
- Re: [saag] Liking Linkability Harry Halpin
- Re: [saag] Liking Linkability Melvin Carvalho
- Re: [saag] Liking Linkability David Chadwick
- Re: [saag] Liking Linkability David Chadwick
- Re: [saag] Liking Linkability David Chadwick
- Re: [saag] Liking Linkability Sam Hartman
- Re: [saag] Liking Linkability Mo McRoberts
- Re: [saag] Liking Linkability Nathan
- Re: [saag] Liking Linkability Sam Hartman
- Re: [saag] Liking Linkability Nathan
- Re: [saag] Liking Linkability Henry Story
- Re: [saag] Liking Linkability Nathan
- Re: [saag] Liking Linkability Ben Laurie
- Re: [saag] Liking Linkability Nathan
- Re: [saag] Liking Linkability Ben Laurie
- Re: [saag] Liking Linkability Harry Halpin
- Re: [saag] Liking Linkability Melvin Carvalho
- Re: [saag] Liking Linkability Ben Laurie
- Re: [saag] Liking Linkability Henry Story
- Re: [saag] Liking Linkability Ben Laurie
- Re: [saag] Liking Linkability Henry Story
- Re: [saag] Liking Linkability Henry Story
- Re: [saag] Liking Linkability Ben Laurie
- Re: [saag] Liking Linkability Henry Story
- Re: [saag] Liking Linkability Ben Laurie
- Re: [saag] Liking Linkability Melvin Carvalho
- Re: [saag] Liking Linkability Dan Brickley
- Re: [saag] Liking Linkability David Chadwick
- Re: [saag] Liking Linkability Nathan
- Re: [saag] Liking Linkability Robin Wilton
- Re: [saag] Liking Linkability Ben Laurie
- Re: [saag] Liking Linkability Ben Laurie
- Re: [saag] Liking Linkability Henry Story
- Re: [saag] Liking Linkability Robin Wilton
- Re: [saag] Liking Linkability Nathan
- Re: [saag] Liking Linkability Melvin Carvalho
- Re: [saag] Liking Linkability Melvin Carvalho