Subject: [TLS] foaf+tls for distributed social networks - 2 questions

From: Henry Story <[email-masked]>
Date: Wed, 25 Feb 2009 19:02:52 +0100

Dear TLS experts,

We are working on a very simple protocol for distributed identity in a  
web of trust that uses TLS in a novel way. The details of this are  
short and can be found online [1]. Here I'd first just like to ask two  
questions, to get into the heart of the problem, then I'll explain why  
these came up.

The 2 questions:
================

   1. How many browsers pre TLS1.1 act as TLS1.1 browsers with respect  
to section 7.4.4 [2]

    [[ If the certificate_authorities list is empty then the client   
MAY send any certificate of the appropriate ClientCertificateType,  
unless there is some external arrangement to the contrary. ]]

    So if a server sends an empty certificate_authorities list, how  
many browsers will in fact respond with at least one certificate?

   2. Would it be possible to create a Certificate Authority that is  
completely open? That is we would publish the public and private keys  
of this CA so that people can sign their keys themselves, reducing the  
paper work needed to create certs. Of course as a result the value of  
these certs would be minimal, since they would not really validate  
anything.

The background:
===============

1. infinite number of CAs
-------------------------

When a foaf+tls [1] server asks the client for a certificate it is  
only really interested in the following information:

    - the Subject Alternative Name URL/URI
    - the public key of the certificate

The server does not really care about the PKI hierarchy of trust, and  
can completely ignore that (though it could be useful as an extra  
piece of information). The server would like to accept certificates  
that are signed by as many people as possible. So currently we allow  
them even to be self signed certificates. This is a problem with the  
letter of TLS 1.0 which states in section
7.4.6:

    [[ If no suitable certificate is available, the client should send  
a certificate message containing no certificates. ]]

Since we want everybody to be able to put together their own  
certificates, and since nobody can know in advance all the self signed  
CAs, it would be impossible for a server to ask the client for a  
certificate in the spirit of this letter is followed.

Now if it turns out that most clients follow TLS1.1 in spirit, then we  
may just be able to proceed as is.

2. One Open marker CA
---------------------

The other solution could be to create an Open Marker CA. This CA would  
just publish it's private key, so that anyone who had certificates  
that were intended to be used as foaf+ssl certificates, could sign  
those themselves with that Open CA, without having to ask anyone.

The advantage of this would be that servers could provide a way to  
tell the clients that they were foaf+ssl enabled, and so reduce the  
risk of a random cert being sent to them. (I am not sure how many  
people do use certs in their browser, so I am not sure how much of a  
problem this is)

I look forward to any feedback you may have about this or any other  
aspects of the protocol we are developing. I'll be glad to answer any  
questions you have. I hope this summary was not too short.

	Henry Story

[1] The main paper for what we have called foaf+ssl (ssl being more  
widely known):
      http://www.w3.org/2008/09/msnws/papers/foaf+ssl.html
   The wiki page:
      http://esw.w3.org/topic/foaf+ssl
   The name is not set in stone and could be changed :-)

[2] http://tools.ietf.org/html/rfc4346#section-7.4.4

[3]  http://tools.ietf.org/html/rfc2246#section-7.4.6

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 27 Feb 2009 13:08:01 +0200

Henry Story wrote:
> web of trust that uses TLS in a novel way. The details of this are short
> and can be found online [1]. Here I'd first just like to ask two

After the explanation and seeing the protocol description I still do not
understand why you need the client certificate for what you want to
achieve. Why you don't send the information you need for foaf on the
application layer (if it is http via a cookie etc)? Why send a dummy
certificate and add some extensions on it? Also the security offerings
are not clear to me. What will that protocol offer, security-wise?

regards,
Nikos

---

From: Henry Story <[email-masked]>
Date: Fri, 27 Feb 2009 13:23:22 +0100

On 27 Feb 2009, at 12:08, Nikos Mavrogiannopoulos wrote:
>> short

Before I go into why I don't do it differently, let me clarify why we  
do it this way. So in answer to your question "Why send a dummy  
certificate and add some extensions on it?" let me show you what that  
gives me:

When the URI is taken from the Subject Alternative Name of the  
certificate sent to the browser the server at stage 3 of the diagram  
in [1] knows the following:

  - the browser has access to the private key for the public key  
listed in the X509 cert
  - the browser wishes to identify the user as having that URI
  - and of course the communication has not been tampered with (TLS)

This, it is true, is very little, but not nothing.

By then dereferencing the URI of the User using simple HTTP GET, the  
server can then get confirmation that the resource referred to by that  
URL is indeed controlled by the owner of the User Agent. This then  
ties the User to that URI.

> Also the security offerings are not clear to me. What will that  
> protocol offer, security-wise?

Well TLS provides all the security of communication we need. What  
remains is the question of Trust. How much does the server trust the  
agent making the connection with knowledge of the resource it wishes  
to server up? Trust just something that is not always captured well in  
a hierarchical manner.

So there are a number of ways the server could decide to trust the now  
identified and authenticated request. It could just check that URI  
with a list of URIs it already is in possession of. That list of URIs  
could be something published on a remote site (at a URL) which the  
server would crawl regualarly. Or the server could check a list of  
resources crawled periodically from a friend network. Or many other  
things... I go into more detail on some of the trust issues in the  
article "foaf+ssl: creating a web of trust without key signing  
parties" [2].

The TLS piece gives us identity and authentication. We then use that  
to build trust from a web of trust, rather than a hierarchical pyramid  
of trust as it more common in PKI. This it is true is unusual, but  
that may explain why nobody tried it before [3] :-)

> Why you don't send the information you need for foaf on the
> application layer (if it is http via a cookie etc)?

So what do you loose by doing it any different way? By as you suggest  
sending the URL via a cookie for example?

  a. cookies are tied to domains. So here you loose the global nature  
of the foaf+tls solution. With foaf+tls you can go to a site you have  
never visited before, and in one click authenticate yourself. [4]  
Without as with OpenId needed to remember a URL [5]

  b. how would a user add a cookie to his browser to be sent on his  
demand to any server on the internet?
     (indeed with foaf+tls the browser can give the user a choice of  
which id to present to the server on request of a client certificate)  
There is no such functionality for cookies.

  c. how would you tie the cookie, added by the user, to that browser,  
without the danger of man in the middle attacks? You need TLS. In fact  
I had initially thought of a cookie + TLS solution [6], because I  
thought we would need new UserAgents to get this working, and I was  
writing a specialized semantic web user agent anyway [7]. But of  
course once I discovered that everything I needed was provided by TLS  
I realised that my job was done.

I hope this helps answer your questions,

	Henry

> Nikos

[1] http://blogs.sun.com/bblfish/entry/foaf_ssl_adding_security_to
[2] http://blogs.sun.com/bblfish/entry/more_on_authorization_in_foaf
[3] http://blogs.sun.com/bblfish/entry/foaf_ssl_pki_and_the
[4] http://blogs.sun.com/bblfish/entry/foaf_ssl_user_story_1
[5] foaf compared to openid:
     http://blogs.sun.com/bblfish/entry/what_does_foaf_ssl_give
[6] http://lists.w3.org/Archives/Public/semantic-web/2008Mar/0206.html
[7] https://sommer.dev.java.net/AddressBook.html