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

Henry Story Henry.Story at Sun.COM
Fri Feb 27 13:23:22 CET 2009

On 27 Feb 2009, at 12:08, Nikos Mavrogiannopoulos wrote:
> Henry Story wrote:
>> 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.
> 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?

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,


> regards,
> 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:
[6] http://lists.w3.org/Archives/Public/semantic-web/2008Mar/0206.html
[7] https://sommer.dev.java.net/AddressBook.html

More information about the foaf-protocols mailing list