foaf+ssl: creating a web of trust without key signing parties

The concept of a Web of Trust is most closely associated with Phil Zimmerman and PGP. The basic idea is that by signing each other's keys, usually at things like key signing parties, people could grow the network of keys they trusted to sign or encrypt documents such as email, sign legal documents, etc... The distributed system of trust feels right, but the idea never really took off - even though the keysigning parties must have been fun - probably because they still required physical presence. Another problem with the PGP web of trust, is that the signers of your key, or your signature on someone else's key will forever be published on one of the many key servers, making it close to impossible to revoke an association once published.

In foaf+ssl we are also using a Web of Trust mechanism, but as I will show here, this does not require key signing. It should therefore be able to grow much faster, and hopefully give us the same benefits. The friendship relations are furthermore not embedded in the signature. They can be made to be only visible to those people you wish to make it visible to, and these can be changed at any moment.

I wrote this rather long post as I was starting to answer a question John Kemp asked in the comments of my duck rabbit post on the topic of authorization in foaf+ssl. As I found the answer was getting long and longer, I decided this justified its own blog entry. So I published it here instead.

John Asked a question that forced me to detail how the trust mechanism in foaf+ssl works. Here it is:

The problem (I think) with how you use the certs [in foaf+ssl] though is that the real trust (if Juliet does not know Romeo a priori) is that Juliet's friends know Romeo, and when I say "know", I don't mean that in any cryptographic sense (Juliet's friends haven't signed Romeo's key/key fingerprint for example). Why wouldn't it then be enough for Juliet to base her trust on the appearance of Romeo's OpenID in her friends' FOAF files, for example?

I like the web of trust model, but in order for there to be verifiable trust based on certs/keys, don't you also need key/cert/fingerprint signing parties?

Since this is going to require thinking carefully about the foaf+ssl protocol, we may as well have its UML sequence diagram in front of our eyes. Here it is:

Remember that at stage 5 Juliet's server knows only the following about <https://romeo.net/#romeo>

  1. The Agent connecting via ssl has access to the private key that matches the public key sent in the cert (because otherwise he could not have signed the cert, and could not have established the ssl connection)
  2. The Agent wishes to be identified as "https://romeo.net/#romeo"
  3. Dereferencing the information resource <https://romeo.net/#romeo> returns the document <https://romeo.net/> which states that anyone who can proove to have the private key for the given public key is <https://romeo.net/#romeo>

Juliet's server can then conclude that the Agent making the request is indeed <https://romeo.net/#romeo> - whoever or whatever that is. Juliet's server can be as confident in this fact as the cryptography algorithms allow her to, which is pretty good.

So at this point we have something between identification and authentication, I am not sure.

When Basing Trust on OpenId does not work

Other statements returned by <https://romeo.net/> are extra claims and are as trustworthy as statements made by <https://romeo.net/#romeo>. They may just by themselves solve some really interesting puzzles for Juliet's server that by could make it trust <https://romeo.net/#romeo> more than anyone else it ever met -- but web servers of this intelligence are unlike any I have yet seen.

More realistically, the question for Juliet's server is whether it should authorize access to the protected resource. If Juliet's friends identify Romeo indirectly via his OpenId, and using that only, with something like the following relations in N3

  @prefix foaf: <http://xmlns.com/foaf/0.1/> .
  @prefix : <#> .

  :anne foaf:knows _:bN .
  _:bN foaf:name "Romeo";
       foaf:openid <https://openid.sun.com/romeo> .

and Romeo publishes a relation he has to an OpenId too such as

  @prefix : <#> .  

  :romeo foaf:openid <https://openid.sun.com/openid> .

Then if Juliet's server wants to motivate access to the protected resource it would need to believe the following

  :anne foaf:knows :romeo .

which appears nowhere. It would have to be inferred from a statement such as

  _:bN = :romeo .

This can indeed be inferred from the statements in Romeo's file giving his OpenId, and the statement in :anne's file stating the relation of the blank node _:bN to the same OpenID, since foaf:openid is an inverse functional property. But what is the confidence Juliet's server can have in that? Well Juliet's server can be as confident of that as she is of the assertion made by <https://romeo.net/#romeo> that his openid is <https://openid.sun.com/romeo>. This can hardly be said to count as confirmatory evidence. If Juliet's server thinks like that, it might as well make the resource public. For it would be the equivalent of a prison officer freeing a prisoner solely on the basis of the claim that he is himself an officer.

Who should one trust?

On the other hand if Juliet's friend :anne had claimed that

   :anne foaf:knows <https://romeo.net/#romeo> . 

then Juliet's server would have had the piece of information needed to authorize access to the protected resource, because that information came from a trusted party.

So in summary, when Juliet's server is looking to evaluate the trust it can have in :romeo it should not ask :romeo himself . It should ask other people in the social networks she trusts. So the graphs it needs to search is everything except what is said by :romeo . Juliet's server can go on the following:

  • that it is speaking to <https://romeo.net/#romeo>
  • what Juliet believes
  • what Juliet believes of what her friends claim
  • the consequences of the claims it is able to or willing to calculate

Now the OpenId can in fact come in useful, but not directly as may have been hoped initially. Imagine that Juliet now has another resource that she only gives access to, to people known by two of her friends. If only one of her friends, say :jane makes the assertion that

  :romeo foaf:openid <https://openid.sun.com/romeo> .

but all other of her friends refer to :romeo indirectly, then her web server could use that information with the statement made by :anne to deduce that indeed at least two of Juliet's friends know :romeo.

The value of information published by Romeo

Now is it absolutely true that Juliet's server can do nothing with the information returned by the document <https://romeo.net/>? Not at all! It is just that it has to be used in an exploratory manner. Imagine a third resource that is accessible to friends of friends of Juliet's friends. We could imagine that <https://romeo.net/> had returned a list of friends for :romeo, perhaps with the following relations:

:romeo foaf:knows <https://jack.name/#jack>, <https://john.name/#john>, <https://duffy.duck/p/#dd> .

Juliet's server could decide to dereference (HTTP GET) both <https://jack.name/#jack> and <https://john.name/#john> because they were known by her friends and see if any of those claimed to know <https://romeo.net/#romeo>.

Special case: when the OpenId published by Romeo is trustworthy

This highlights then a special case where the OpenId published by Romeo can work correctly out of the box. This is when his OpenId is his foaf file. Ie when Romeo publishes something like:

@prefix foaf: <http://xmlns.com/foaf/0.1/> .

<http://romeo.net/> a foaf:PersonalProfileDocument;
            foaf:primaryTopic <http://romeo.net/#romeo> .

<http://romeo.net/#romeo> a foaf:Person;
            foaf:openid <http://romeo.net/> .
Here the foaf personal profile document is the same as the one returned when dereferencing Romeo's web id <http://romeo.net/#romeo>. It is returned in the same representation as the statements we are trusting on :romeo's public key, and assigning this relation to the same person. Since an OpenId is a resource controlled by the person whose openid it is, and since we believe that this resource is now controlled by <http://romeo.net/#romeo> I think we can safely say that Juliet's server knows :romeo's OpenId in this particular case too.

There is another case where the OpenId published by :romeo could work, even when the OpenId is not the same as the foaf:PersonalProfileDocument, but in this case it would require some verification. So let us get back to the situatuon described earlier in this post where Romeo's WebID claims that

  :romeo foaf:openid <https://openid.sun.com/romeo> .
For Juliet to believe this she would have to verify that http://romeo.net/#romeo controls https://openid.sun.com/romeo. This could be done very simply if Romeo has that OpenId page link back in some way to his foaf ID. Perhaps, as I suggested in "Foaf and Openid" this could be done simply by adding the following to the header of the OpenId page:
<link rel="meta" type="application/rdf+xml" title="FOAF" href="http://romeo.net/"/>
Juliet's web server would then be able to fetch the OpenId page, and having found the above link back to the :romeo's Personal Profile Document, it would be able to conclude that he controlled https://openid.sun.com/romeo, and so that it is a legitimate OpenId for him. With foaf+ssl Juliet's server can verify an OpenId with only one extra connection!

Web of Trust and Key Signing

All the above clearly shows that you can create a web of trust without key signing parties. Parties are nice, but requiring Key Signing parties is something that has seriously dampened the adoption of PGP and the web of trust. By just dragging and droping a URL from a web page, an email, another application into your foaf Address Book (be it web based or not), you can grow your web of trust much faster than Keysigning can. Furthermore you can change your public key when you no longer need it, loose it or whatever without needing to re-sign all your keys. This therefore adds to the security of your web of trust.

This is not to say that foaf+ssl is incompatible with key signing, btw. and it may be interesting to find out where this remains useful.

Comments:

Henry,

I would suggest you add a section or link to a post titled: What is a Hyperdata enabled Web Server?

Understanding the Hyperdata variant of Web Server is crucial to comprehending FOAF+SSL :-)

Kingsley

Posted by Kingsley Idehen on January 17, 2009 at 11:22 AM CET #

Kingsley, I go into why Linked Data is key to getting distributed social networks in my JavaOne 2008 presentation, which also covers foaf+ssl

http://blogs.sun.com/bblfish/entry/building_secure_and_distributed_social

( There's no Java in that presentation btw, it's all very high level )

Posted by Henry Story on January 20, 2009 at 10:31 AM CET #

The problem (still) is that the certificate indeed authenticates the generator of the certificate to the site receiving the certificate. It says "the bearer of this certificate is the entity doing the SSL handshake". That's all (if it is self-signed). However, \*anyone\* can generate a client certificate and embed a URL (to a FOAF file or any other resource) in it. Why should I trust that if I am Juliet? There is no link between the crypto authentication and the authentication of Romeo to Juliet. OpenID (or other such protocols like SAML) work here because some site makes an assertion about Romeo that Juliet may trust because she trusts the site that made an assertion about Romeo. Likewise she can choose to trust that her friends know Romeo (by dereferencing their FOAF files). But the site can't cryptographically trust Romeo unless it (or its CA) signed Romeo's cert. The PGP model (where each party cryptographically trusts the other) would also make sense here. Otherwise, you may as well say "my FOAF URL is http://evil.com/foaf" and do all the embedding in a \*self-signed\* cert that you want. It still can't be cryptographically \*trusted\* by anyone.

Posted by John Kemp on January 20, 2009 at 03:27 PM CET #

John Kemp wrote:

[[
The problem (still) is that the certificate indeed authenticates the generator of the certificate to the site receiving the certificate. It says "the bearer of this certificate is the entity doing the SSL handshake". That's all (if it is self-signed).
]]

Yes, the client sends a self signed certificate with the URL to Juliet's server. Anyone can create such a certificate easily. But the foaf+ssl protocol is not finished at this point. This is just the identification stage numbered (3) in the UML sequence diagram.

[[
However, \*anyone\* can generate a client certificate and embed a URL (to a FOAF file or any other resource) in it.
]]

Yes, but that someone cannot control all the URLs in existence. The foaf+ssl protocol works because it ties an information resource to the public key published in the certificate. If Romeo does not control the <https://romeo.net/> resource, he will not be able to place information there about his public key.

This is why Juliet's server then goes and fetches the named resource in (4), and tests that resource in (5) for the public key information.

[[
Why should I trust that if I am Juliet?
]]

What Juliet's server is trusting is simply that <https://romeo.net/#romeo> controls the foaf:Document <https://romeo.net/>. Who <https://romeo.net/#romeo> is is not covered here, neither if what is written in that document is correct. Juliet's server need do nothing with the information in <http://romeo.net/> after she has verified the public key information in (5)

[[
There is no link between the crypto authentication and the authentication of Romeo to Juliet.
]]

Notice that in this post I never speak of Romeo, but only of <https://romeo.net/#romeo> or in short :romeo. Juliet's server knows nothing more than that she has a request from :romeo. This much has been cryptographically proven.

It is true that anyone can create a resource at some URL, eg <https://thieves.com/r/> somewhere, create a key pair, and place information about the public key in that file. What that person will find a lot more difficult to do is to get a number of Juliet's trusted sources to make statements that they know <https://thieves.com/r/#romeo> . To do that the impersonator would have to break into a number of Juliet's aquaintances' servers and change the information there. And if he did, assuming that Juliet's friends are all watching a little bit after each other, their respective softwares would alert her friends of this change, giving some of them time to raise an allarm bell if something suspicious was going on.

So the trust one can have in this web of information is the trust one has in the weakest link in the network of information one is reasoning with that one needs to believe the relation in question.
Sometimes there may be redundant information in different places that will strengthen one's trust. So if all my friends say they know <https://romeo.net/#romeo> and each of them is on different servers, then I would have to calculate the probability of some thief breaking into all the servers and adding that information to all of them.

Now, how strong that trust need be for accessing the protected resource should depend on the value of the protected resource. If that resource is a wiki, a simple game, information about Juliet's telephone number, she may be satisfied with something that excludes robots. If Juliet wants to make a transaction that involves a lot of money, she may be advised to take further precautions.

[[
OpenID (or other such protocols like SAML) work here because some site makes an assertion about Romeo that Juliet may trust because she trusts the site that made an assertion about Romeo.
]]

We do exactly the same thing here. The assertions Juliet uses to decide how much she should trust requests for access to her protected resources, are assertions made by her friends, made on other sites and in other documents. Notice that foaf+ssl is more fine grained than your above assertion. We are speaking of trusted resource, not trusted sites.

[[
Likewise she can choose to trust that her friends know Romeo (by dereferencing their FOAF files).
]]

yes.

[[
But the site can't cryptographically trust Romeo unless it (or its CA) signed Romeo's cert.
]]

I think you have missed the piece about Romeo needing to place at the <http://romeo.net/> resource a foaf file with information relating him to his public key. That is a cryptographic statement that only allows people who have access to the corresponding private key to authenticate with Juliet.

[[
The PGP model (where each party cryptographically trusts the other) would also make sense here. Otherwise, you may as well say "my FOAF URL is http://evil.com/foaf" and do all the embedding in a \*self-signed\* cert that you want. It still can't be cryptographically \*trusted\* by anyone.
]]

Yes, if I own evil.com I can write whatever I want there, just as people can write any nonsense they want on their home page. But they will find it a lot more difficult for people to link to them.

You can find any number of liars in any reasonably sized town. People of good morals tend to quickly discover their nature and soon distance themselves from them. Liars then end up with other liars, making it even easier to identify them. This is not foolproof, but nothing in security is.

Posted by Henry Story on January 20, 2009 at 05:27 PM CET #

Hi Henry,

I'm trying to understand FOAF+SSL and have the same issue than John. You say that : "If Romeo does not control the <https://romeo.net/> resource, he will not be able to place information there about his public key."

But if Alice contacts https://romeo.net/ to retrieve its public key, how can she be sure that she reaches the proper server (I'm thinking of DNS poisoning or other man in the middle attacks). The only way is to either have obtained romeo's public key through another mean (which one ?) or to have romeo provide a certificate signed by a party that Alice trust (need key signing parties).

Can you please elaborate on how you protect agains man in the middle attacks in FOAF+SSL ?

Thanks a lot,

-Laurent

Posted by Laurent Eschenauer on September 20, 2009 at 05:00 AM CEST #

Hi Laurent.

DNS poisoning is indeed a serious issue. Indeed it is \*so\* serious an issue, with so many implications for commerce and security, that it is forcing the introduction of DNS-SEC. This will be mandated by the United States for the Military and the governement controlled DNS by the end of the year. See many of the presentations at this year's Hacking at Random outdoor conference which I bloged about here:

http://blogs.sun.com/bblfish/entry/camping_and_hacking_at_har2009

The issue of DNS poisoning is in part mitigated by the use of https. The identity of the server is in part protected by the Certificate Authority that signs the certificate served by the server, which ties that cert to the requested domain name.

X509 itself has its own problems of course, many of which Dan Kaminsky goes into in his presentation at HAR - see the above link.

But it seems that many of these problems are a lot less serious once DNS-Sec is introduced, or so at least Dan seemed to say in questions I asked him at the end of the conference.

Posted by Henry Story on September 20, 2009 at 06:40 AM CEST #

Hmmm. If you require romeo to have a CA signed certificate in step 4, you may as well require Juliet to have one in step 2 (romeo also want to be sure he talks to Juliet).

In this case, can't this whole thing just be done in a single request authenticated by these CA signed certificates ! What is the point of FOAF+SSL then ? Am I missing something ?

Another way to solve this, without CA signed certificates, would be for Romeo (or Juliet) to obtain the public key of the other party through another mean. Like through a web of trust path across already trusted friends. This would also justify using FOAF (otherwise you don't really need it right ? XRDS could be enough to discover the public key).

It would be nice if you could point me to a more detailed use case that shows the usefullness of FOAF+SSL despites this CA signatures requirement.

Thanks for your help !

-Laurent

Posted by Laurent Eschenauer on September 21, 2009 at 11:57 AM CEST #

Hi Laurent,

We do in fact require Juliet's \*server\* to have a CA certified X509 certificate, and it is clearly best if Romeo
's \*server\* is also protected by one. In other words: Juliet and Romeo should serve their resources via https.

We don't require Certificate Authorities to certify people here, and that is the big difference. The advantages are numerous:

- It is a lot easier to get server certificates than it is to get people certificates. I don't know of a Certificate Authority that produces free certificates for people. The more information they would certify the more expensive that would get, as the CA would burden the responsibility of anything said by them, for someone they may in fact have very little knowledge of. Here we use the social network of people who really are interested in Romeo or Juliet to certify them via the links that they establish with them. We distribute the certification of people from a CA to the network of people who know someone.
- One server can furthermore serve foaf files for any number of people. So Juliet could use her server to serve profiles for her whole family, and similarly for Romeo's server.
- What can be put into a CA cert is a lot less flexible than what can be written down in RDF. In RDF one can easily create a kissed relation. I don't think the X509 thought that was will be useful enough to include in any version of X509 that has existed or that is to come.
- Changing properties in the foaf file is a lot easier than changing a certificate. Once signed a certificate cannot be changed. It would have to be re-issued. So imagine you change address. You can make that change easily in your foaf file. Not in an signed certificate. Imagine you describe your current physical location. It would cost a fortune if every time you took the train you had to ask a CA for a new certificate. If you loose or believe the private key in your foaf+ssl certificate has been compromised, then changing it is free.

So there are many advantages in allowing that one extra connection.

Posted by Henry Story on September 22, 2009 at 09:48 AM CEST #

Post a Comment:
Comments are closed for this entry.
About

bblfish

Search

Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today