foaf+ssl: creating a web of trust without key signing parties
By bblfish on Jan 17, 2009
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
- 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)
- The Agent wishes to be identified as "https://romeo.net/#romeo"
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
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
- 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
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://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:
Here the foaf personal profile document is the same as the one returned when dereferencing Romeo's web id
@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/> .
<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
For Juliet to believe this she would have to verify that
:romeo foaf:openid <https://openid.sun.com/romeo> .
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:
Juliet's web server would then be able to fetch the OpenId page, and having found the above link back to the
<link rel="meta" type="application/rdf+xml" title="FOAF" href="http://romeo.net/"/>
: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.