[Freedombox-discuss] FOAF developers taking FreedomBox into their equation
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
There are three parties involved in a WebID authentication, as i
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?
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?
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".
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.
Thus, it seems to me that the WebID scheme has only pushed the question
of centralized certificate validation off by one level, rather than
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1030 bytes
Desc: OpenPGP digital signature