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

[Henry Story]

On 10 Mar 2011, at 19:44, Daniel Kahn Gillmor wrote:

> On 03/10/2011 06:28 AM, Jonas Smedegaard wrote:
>> I believe the key to this is the FOAF part: I can, in my FOAF file,
>> beyond declaring what friends I have and what WebID public key is linked
>> to it, also declare what CAs I trust (which might be only my very own
>> FreedomBox).
> 
> There are three parties involved in a WebID authentication, as i
> understand it:
> 
> A) the user, who wants to prove their identity
> 
> B) the TLS server to whom (A) is authenticating
> 
> C) the web server that serves up A's information.
> 
> Is this right?

yes

> 
> A connects to B using TLS, and offers a client-side X.509 cert that
> contains a URI that points to C.
> 
> I'll call the communication that runs A->B the "initial link", and the
> subsequent connection that runs B->C the "backhaul link".  If there are
> better terms in WebID land, i'd be happy to learn the common vocabulary.
> 
> My understanding is that the FOAF file is served from C to B upon
> request.  You're claiming that this FOAF file resolves the
> authentication problem.  Correct?
> 
> My question is how B validates the backhaul link.  That is, how does B
> know that they are actually talking securely to C?

Currently it would use https with CAs (and later DANE currently being developed at the IETF in DNSsec). That work very widely, and are already a lot better than what most web sites use.

Now if you can develop other methods to verify a machine, then those could be used additionally too. 

Self signed server certs could be validated by a bunch of your friends, which could set up friend DNSsecs presumably. 

> 
> If the backhaul link is unvalidated (therefore spoofable) then an
> imposter capable of such spoofing can successfully masquerade as A by
> generating and deploying a FOAF file that asserts the information the
> attacker needs for their "false A" cert to be accepted.  So i don't
> think that counts as "secure authentication".

No that would be a very weak deployment of WebID.

> 
> So let's assume that the backhaul link *is* validated.  One mechanism
> used by WebID for validating X.509 certificates without a central
> authority seems to be to follow the embedded URI
> subjectAlternativeNames.  But that can't work for validating the
> backhaul link because it would lead to infinite regress.

Not quite. The server certificate is identifying a service joe.name:443 . 
You could put that name in the server certificate subject alternative name.
Then you could apply the same principle by looking up the service in the place
one does those lookups in: DNS. Of course DNS is itself insecure, so this
only works with DNSsec, and that is what this group is working on:

  http://tools.ietf.org/wg/dane/draft-ietf-dane-protocol/

Then the pieces are tied together. Now they are you might say centralised. Though DNS is not that centralised either.

And it's open to you to find better distributed naming systems. If you do one could put another SAN in the client certificate.

> 
> Thus, it seems to me that the WebID scheme has only pushed the question
> of centralized certificate validation off by one level, rather than
> resolving it.

So we are currently resting on some existing and widely deployed infrastructure. But we do not require them. Perhaps  you can find some interesting things to explore in the direction of RFC 5081 "Using OpenPGP Keys for  Transport Layer Security"

> I don't think that an (spoofable) FOAF file on its own is sufficient to
> resolve the question here.  Am i missing something?  I'd be happy to be
> wrong.

WebID currently is about client authentication. Not really about server authentication. Though because they are symmetric, the intuitions developed in one place can be applied at the other.


	Henry

> 
> 	--dkg
> 
> _______________________________________________
> Freedombox-discuss mailing list
> Freedombox-discuss at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/freedombox-discuss

Social Web Architect
http://bblfish.net/