Re: [pkng] More thoughts: Privacy

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 18 November 2009 10:21 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: pkng@core3.amsl.com
Delivered-To: pkng@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F4683A6924 for <pkng@core3.amsl.com>; Wed, 18 Nov 2009 02:21:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.293
X-Spam-Level:
X-Spam-Status: No, score=-0.293 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dn2fBRr0UCEE for <pkng@core3.amsl.com>; Wed, 18 Nov 2009 02:21:15 -0800 (PST)
Received: from mail.newbay.com (87-198-172-198.ptr.magnet.ie [87.198.172.198]) by core3.amsl.com (Postfix) with ESMTP id 451CE3A6809 for <pkng@irtf.org>; Wed, 18 Nov 2009 02:21:14 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.newbay.com (Postfix) with ESMTP id 12AA71003F4CB for <pkng@irtf.org>; Wed, 18 Nov 2009 10:21:12 +0000 (GMT)
X-Virus-Scanned: amavisd-new at newbay.com
Received: from mail.newbay.com ([127.0.0.1]) by localhost (mail.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfNpgjm1zoUB for <pkng@irtf.org>; Wed, 18 Nov 2009 10:21:11 +0000 (GMT)
Received: from mail01.newbay.com (mail01.newbay.com [192.168.12.25]) by mail.newbay.com (Postfix) with ESMTP id 93DB81003EB73 for <pkng@irtf.org>; Wed, 18 Nov 2009 10:21:11 +0000 (GMT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail01.newbay.com (Postfix) with ESMTP id 5A09A7C125 for <pkng@irtf.org>; Wed, 18 Nov 2009 10:21:11 +0000 (GMT)
X-Virus-Scanned: amavisd-new at newbay.com
Received: from mail01.newbay.com ([127.0.0.1]) by localhost (mail01.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlE9q1fF1LLw for <pkng@irtf.org>; Wed, 18 Nov 2009 10:21:08 +0000 (GMT)
Received: from [192.168.3.55] (unknown [192.168.3.55]) by mail01.newbay.com (Postfix) with ESMTP id A66E27C124 for <pkng@irtf.org>; Wed, 18 Nov 2009 10:21:08 +0000 (GMT)
Message-ID: <4B03CA94.1070707@cs.tcd.ie>
Date: Wed, 18 Nov 2009 10:21:08 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Thunderbird 2.0.0.23 (X11/20090812)
MIME-Version: 1.0
To: pkng@irtf.org
References: <4B030FF1.8030200@Dartmouth.edu> <4B03112C.8070304@stpeter.im> <4B031654.3090004@Dartmouth.edu>
In-Reply-To: <4B031654.3090004@Dartmouth.edu>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [pkng] More thoughts: Privacy
X-BeenThere: pkng@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Public Key Next Generation \(PKNG\) Research Group" <pkng.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/listinfo/pkng>, <mailto:pkng-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/pkng>
List-Post: <mailto:pkng@irtf.org>
List-Help: <mailto:pkng-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/pkng>, <mailto:pkng-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Nov 2009 10:21:16 -0000

I agree that whatever PKNG does should support privacy to
the extent possible. (Hence the "selective field
confidentiality" item in my looong wish-list earlier.)

Its not clear that that'll be tremendously useful in that
many cases, but I can at least think of some. For example,
if a cert-like blah-thing were to allow me to encrypt any
field, and if I had tls-extractor stuff working, then a
TLS client could send the blah-thing with some fields
encrypted in a TLS handshake (assuming that we can squish
the blah-thing into a TLS handshake) and later on send
the decryption key to the TLS server encrypted under
a key derived from the TLS extractor stuff. (Or I guess
if we want to imagine messing more with TLS, then
something derived from the pre-master secret could have
been used by the client to encrypt parts of the blah-thing,
and a TLS ClientHello extension could signal that to
the TLS server.)

A side-effect there would be that it would then be safe
to send the blah-thing in the initial handshake, and so
there'd be no need for TLS renegotiation, and so we'd
avoid the currently topical TLS renegotiation bug.

S.

Massimiliano Pala wrote:
> Hi Peter,
> 
> I understand that is a matter of Policy. Unfortunately the user has no
> control over what the provider of the OCSP service does with the data
> that might track one's activities (and potentially location) throughout
> the day.
> 
> Some organizations like government agencies might overlook this problem
> and leak data that is supposed to be kept secure. The OCSP is an example,
> but my point was that if we can manage to introduce a
> user-machine-enforceable
> (not relying only on policies decided by someone else once and for all)
> we could have better coverage of the USER's need. And, also, we would
> simplify policy writing and agreements for 3rd parties provided services.
> The same simplification would occur in managing federated identities and
> access to external resources - whenever possible, of course!
> 
> Just my 2-cents.
> 
> Later,
> Max
> 
> 
> On 11/17/2009 04:10 PM, Peter Saint-Andre wrote:
>> I think this is a policy issue for providers of PK* services (just as it
>> is for providers of email services, IM services, microblogging services,
>> and all the rest). Now, I agree that better disclosure of policies will
>> help humans make more informed decisions (if they care to be informed).
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> pkng mailing list
> pkng@irtf.org
> https://www.irtf.org/mailman/listinfo/pkng