Subject: [pkng] More thoughts: Privacy

From: Massimiliano Pala <[email-masked]>
Date: Tue, 17 Nov 2009 16:04:49 -0500

Hi PK-NGers,

I would like to add one aspect that I think could be an important addition
to current PKIs. Indeed, what we have today is a complete disclosure of one's
identity. PKI protocols have been designed without taking into any account
privacy concerns.

As many of the ideas I read on the list are related to easily extend trust
by somehow linking together different infrastructures, I think that we shall
keep in mind that privacy is very important when linking together different
organizations/authorities.

I tried to make the point on the PKIX list (I guess most of the people here
are also subscribed to that list) about the OCSP - currently the answer in
traditional PKI is using SSL/TLS for communication between peers - but that
would not solve the problem on the OCSP server, its logs and how policies
should take care of how to handle that data. If the data on the server's log
is sufficiently anonymized, then it is easier to federate identities and
outsource services or relying on 3rd party servers.

What do you think ?

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]                   [email-masked]
                                                  [email-masked]

Dartmouth Computer Science Dept               Home Phone: +1 (603) 369-9332
PKI/Trust Laboratory                          Work Phone: +1 (603) 646-8734
--o------------------------------------------------------------------------
People who think they know everything are a great annoyance to those of us
who do.
							   -- Isaac Asimov

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 17 Nov 2009 14:10:04 -0700

> outsource services or relying on 3rd party servers.

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

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Massimiliano Pala <[email-masked]>
Date: Tue, 17 Nov 2009 16:32:04 -0500

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

-- 

Best Regards,

	Massimiliano Pala

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 18 Nov 2009 10:21:08 +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:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> pkng mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/pkng