Re: [Freedombox-discuss] FOAF developers taking FreedomBox into their equation

I started replying to Boaz, and it ended up being a lot longer than what I had anticipated. As this is relevant to a couple of WebID issues I am also sending this 
to the WebID list. The issues are:

- ISSUE-45: Compare WebId with PGP/GnuPG Web of Trust
- ISSUE-52: WebID and the Freedom Box

These issues are listed here
  http://www.w3.org/2005/Incubator/webid/track/issues

In short I show below 
  - the logic of two freedom boxes setting up an initial connection using https
    (but without relying on DNS)
  - how they get to build up trust using only ip addresses and no trust anchors
  - the possibility of an httpk url scheme for WebID
  - how one can use https to do something similar
  - how to get DNS and such schemes to work together
  - how to turn every FreedomBox into a DNS(sec) honesty checking agent
  - and more 

On 12 Mar 2011, at 22:20, Boaz wrote:

> Here's what I envision.  Two people connect through their freedom
> boxes.  Their boxes try to find a path to authenticate each other
> through the web of trust.  If they succeed, great, if not, their boxes
> use self signed certificates for now, which is at least no worse than
> not encrypting at all.  In either case, the first time they make a
> phone call to each other, their boxes do a ZRTP exchange (maybe the
> people actually bother to verify the short authentication string,
> maybe they don't, at least the strings were up on their screens and
> they had the option to do it, which should deter attackers).  Now
> these two people's boxes are authenticated to each other.  Thus the
> web of trust grows one strand.  And all of this happens behind the
> scene, the real people don't need to do anything, except maybe verify
> the short authentication string.
> 
> What does everyone think about all this?

Let me rephrase this semantically/logically 

We start off in your example with 2 agents that have never communicated. Let us call them unoriginally A and B. They open up a channel of communication with each other. At the end of this crypto negotiation  A knows the following in addition to that it is communicating with some x 

x knowsPrivateKeyOf b_pubKey .

and B knows in addition to it's knowing that it is communicating with some y, that

y knowsPrivateKeyOf a_pubKey .

Here x and y are existential quantifiers: they are not names: ie. they can't be reused from session to session or transmitted between agents. But since the relation knowsPrivateKeyOf is known as an inverse functional property - that is it always identifies the same subject - then if at a later point A finds out that

B knowsPrivateKeyOf b_pubKey 

then it can deduce that B == x, and so tie the history of communication together.

Whatever else is IN the certificate can be doubted of course. But the public key is a good handle, at least in so far as it gives a means to enable further identified communication. 

Now what is missing is information about x and y.  That could be placed in the certificate, but why bother putting a lot in there? Either a or b has already received the certificate and so they will already know what is in there, and it won't interest them, or they don't. And most of what you put in the certificate will be out of date soon and it will be especially difficult to change if the certificate is signed by someone else.

All the certificate really needs is the location of further information. This could be in one of two forms: a full URI or a relative URI. It comes to the same if the URI host name is an ip address that is the same as the one from which the connection is made. So let us consider that case, in order not to introduce any external trust anchors

If A connects from 146.169.1.24 then it could say something like

<https://146.169.1.24/people/Alice#fb> knowsPrivateKeyOf a_pubKey .

Now if B receives that, it should see it as new claim. Which it could verify by downloading <https://146.169.1.24/people/Alice> as described in the WebID protocol. One would expect that document to say, among other things

<https://146.169.1.24/people/Alice#fb> a FreedomBox;
               knowsPrivateKeyOf a_pubKey . 

Since the agent responding at https://146.169.1.24 is using the same public key - b_pubKey - B knows it is communicating with the same agent. So for the moment we have no additional trusted agent needed. Perhaps the profile says the following additional stuff

<https://146.169.1.24/people/Alice#fb> serves <https://146.169.1.24/people/Alice#me> .

So that we can distinguish between the box and the person being served, Alice. Now to reduce the length of the URLs let me add

@prefix : <https://146.169.1.24/people/Alice#> .
@prefix pingback: <http://purl.org/net/pingback/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

and we can now reveal that the document additionally published

<> a foaf:PersonalProfileDocument;
   pingback:to </ping> .

:me a foaf:Person;
      foaf:blog </people/Alice/blog/>;
      foaf:phone <sip:alice@146.169.1.24> .

:fb a FreedomBox;
    serves :me .

(note <> in N3 or Turtle is a shorthand for the url of this document, referring to the document)

Ok, perhaps the phone number should not be made publically available yet. In any case it is unverified...
      
So let us put ourselves in the socket of Bob's Freedom Box. It connects to some other box and now knows that that box knows a public key, and a bunch of stuff that box claims about itself. Bob's Freedom box can create a web page for Bob-the-man to connect to that shows what that other box says about itself and its master. At that point Bob can connect using some reliable method of communication - that could for example be via the given sip connection, but it could be some other way - with the claimed Alice. What is important is just that at some point Bob the man, use such channels and be confident to some degree that he knows Alice  via that handle. When bob has called <sip:alice@146.169.1.24> and done whatever additional verification needed - Bob can add to his Profile hosted on his FreedomBox and perhaps only visible to his proven friends

:me a foaf:Person
    foaf:knows <https://146.169.1.24/people/Alice#me>,  <https://146.169.1.24/people/Alice#fb> .

<https://146.169.1.24/people/Alice#fb> serves <https://146.169.1.24/people/Alice#me>
<https://146.169.1.24/people/Alice#fb> cert:longTermPubKey a_pubKey .

Ok, up till now we have removed any trust anchors. We are just relying on ip addresses. In an ipv6 world this may not be such a problem. For the moment it is more so as there is the danger of those changing. It means that whenever you move your FB you'd have to call your friends and ask them to change their graphs. Btw: this is not necessarily so problematic as Freedom Boxes could do this automatically. But if these urls seep out of the Freedom Box world, which they could easily do, one may have a bit of a mess...

If you had a global reliable distributed public key inscription/lookup service, then one could create URLs based on it so that boxes could be moved easily. Perhaps one could create such HTTP URLs based on the existence of such a service. call these httpk urls. The could look something like this

  <httpk://lhslkdhfsdfsdfsfsfdsxxs23sfsdf/people/Alice#fb>

These would clearly not be human readable URLs, but perhaps by now people feel comfortable enough with URLs that this is not such an issue. Such a lookup service would be very very simple. If you can prove you have the public key to the private key, it adds your ip address to the pubkey->ip address lookup.

If you loose your private key or your freedom box, you just have to tell all your friends one by one about what happened, and they will have to replace all statements made about you under the old name with statements about you under the new name. This would be the same as if in DNS you lost legally the rights to your domain name, except that here, you don't have legal recourse. 

So could people subvert the public key lookup? Not really because any communication would rely on the URL, which if not authentified would not work.

Perhaps one could have DNS AND the crypto together by using the username password field in the https url? Put as username the unix name of the service so

https://https:lhslkdhfsdfsdfsfsfdsxxs23sfsdf@bblfish.net/people/Alice#fb 

could now be the url of the https service at bblfish.net. Now you can make claims about what that service is saying. You could also use DNS as it is now to give you an initial good idea of where the box is. The disadvantage is that you may have to call all your friends either if you loose your box, OR if you loose access to your DNS domain. Also I am not sure if the above url is ok so it would require some investigation.

So why are these URLs useful? Because they help us give names to what an entity says, and makes it possible to merge statements by different people easily allowing us to create a linked web of trust (as opposed to a signed web of trust) If I am known under a name people can claim they know me, and I can claim to know them, but also so that I can link to a blog posted by alice, or to her thesis, holiday pictures, etc... By using links we can grow the size of the web from a web of signed certificates to a web of signed documents and a web of everything in existence. This makes it much more useful, and so creates a huge momentum.

So for example if I get to know Alice I can add to my profile

me a foaf:Person
    foaf:knows <httpk://lhslkdhfsdfsdfsfsfdsxxs23sfsdf/people/Alice#me> .

And so for anyone who knows me if they get an invitation by alice or Bob their software can help them make the initial trust decision: their freedom box can say "Henry knows Alice, and he took some pictures of her which you can see here and here. Does this look like the alice you wanted to contact?". Then you get additional confirmation.

So the httpk url above is quite cool but not widely useable in browsers (yet). The https url with pubic key is useable, but a bit long. Can we do better?

I occurred to be that each freedom box could have a URL that lists all the public keys they have come across for each domain:port service they came across. So my profile could state 

:me publicKeyDoc </system/keys> .

which could than state

[] a Service;
   host "alice.name"
   port 443
   lastIPseen "146.169.1.24" 
   publicKey aPubKey .
[] a Service;
   host "bblfish.net"
   port 443
   publicKey ...

I suppose this would be public but need not be. The above could be a bit long though for people with a lot of friends and a caffeinated FB... So why not link to a simple lookup service

<> securequery </system/keys?> .

The /system/keys? page could just be a simple HTML form, with 4 fields
host, port, public key and perhaps ip address. Fill any out and it could return an rdfa marked up page giving an answer that is a filter of what it knows.

Oh, wait! We have just described the protocol for our key lookup service!

This service would then allow all urls published by a FreedomBox to work with current browsers, on the existing web. They would just be normal http urls.  But other Freedom Boxes could do  lookups to that service to see what public keys a specific Freedom Box had used to communicate with any service, allowing it essentially to convert any https urls into httpk urls.

Ok, in summary: what have we achieved now? Something quite cool I think.

1. Normal browsers can keep on using normal URL lookups
2. Freedom Boxes and intelligent servers, and later even browser, can find out what any server knows about the public key of every other box it connected to, so that it will be able to create warning flags if it finds a different key being used for some software.
3. Every Freedom box becomes a service for a future httpk url world

This means that the more Freedom Boxes are out there, the more pressure there will be on DNS providers to be honest, since there will be constant cross checking going on. 


  Henry

Social Web Architect
http://bblfish.net/

Received on Sunday, 13 March 2011 12:12:32 UTC