[Freedombox-discuss] FOAF developers taking FreedomBox into their equation
On Thu, Mar 10, 2011 at 11:38:34PM -0500, Daniel Kahn Gillmor wrote:
>On 03/10/2011 08:44 PM, Jonas Smedegaard wrote:
>> If e.g. Verisign is untrusted, then remove Verisign root certificates
>> from your system and any website using that CA will no longer be
>> trusted. This should be true also for WebID.
>The problem with this approach is a nasty social problem, rooted in the
>single-issuer specification of X.509 certificates:
>In short: there is a system of perverse incentives that force people to
>keep "trusting" the untrustworthy middlemen. We need to change that.
I totally agree. And I totally agree that WebID when applied to classic
web usage do not escape the security flaws inherent in classic web -
i.e. blind trust in certain large companies like Verisign.
I also totally agree that DNSSEC do not solve this, only shifts which
essentially non-trustworthy entity must be blindly trusted for the whole
structure to work.
*But* we are not (necessarily) talking "classic web usage" here, IMO.
We have a trick at our hands called FreedomBox, which may help leverage
if used carefully.
With "carefully" I mean that we should beware of inventing custom
protocols unique to FreedomBox. We really want to communicate equally
with anyone using same technologies as us, independent of their system
being "boxed" like ours or not. And also we really do not want our
boxes to stand out too much on the internet, as that would make it too
easy for evil-doers to then treat special any communication originating
at our type of communication devices (e.g. to hunt them down, or more
elegantly to drastically lower the quality of service for such devices).
Therefore I find it preferrable if using existing protocols that work
great for the whole internet, but if that fails we can pick technologies
that work great when applied to machines under our control, even if same
technologies do not work similarly great for others.
My impression is still that a) WebID is great for FreedomBox even if
still a security hazard (albeit not worse than without it!) for others,
and b) no alternative protocol exist providing similar features as WebID
(i.e. user-friendly _and_ secure _and_ RESTful) while working great for
>> Might be that the user runs IE8 with horrible settings, but the
>> FreedomBox wanting to verify a claimed WebID does not, so that should
>> not matter to us, I believe.
>You're missing the step of what i called the "backhaul link" earlier.
>If the fb is verifying a claimed webid by visiting its stored URI, then
>it needs to verify that its pubkey matches the pubkey served by that
>URI. But to verify that it is legitimately reaching the URI, the FB
>needs to validate the certificate of the web server hosting the FOAF
>file. This leads to either:
> (a) infinite recursion, in the case where the web server's cert itself
>contains a WebID-style URI, or
It is only infinite if we allow it to be. I suspect resolvers of
classical (flawed!) hierarchical SSL/TLS chained certs also put a limit
on the amount of intermediary certificates before reaching the root is
allowed before giving up.
Similarly I imagine we can decide (despite the protocol itself having no
such limit) to not _bother_ resolve trust chains longer that e.g. 3
levels - or "hops" or "degrees" in some other lingo.
Translated into human relations: You claim that I owe you money
indirectly. The "protocol" in our hood may be that I must pay if you
can prove the chain of meney exchange among peope in our hood - but
still I may choose to refuse your claim if it takes you more than a
minute to explain the story of the missing money to me - even if time
was not part of our shared protocol.
> (b) some other certificate verification method, which Henry Story
>points out is the standard X.509 cartel today, and may move to
>DANE-style DNSSEC-backed key publication. I don't think either of
>these methods is acceptable, so that leaves us with:
This will be cool when it emerges, and we can shift to that.
Perhaps it is even usable today, similar to WebID (in my perception)
being usable today: with the condition of one piece of the puzzle is in
the handls of engineers (read: located on FreedomBoxes) so can be taught
the protocol more strictly than is possible on the wider internet.
> (c) sort out a better, decentralized certificate verification method.
>But if we're going to do that, then we've begged the question. We
>might as well use this hypothetical better certificate verification
>method directly on the client-side certs in the first place.
I suspect Monkeysphere belong here. Imagine that we provide a tool
where non-technical internet users are offered boxes that do not trust
government powers but instead trust a different external entity being
"the world's largest cloud of geek-developed web-of-trust". Sure, this
can in principle be attacked by _very_ clever superpowers using enough
agents infiltrating that web-of-trust, but is IMO better than telling
our non-technical users to become technical because they must trust
themselves, not us, and we can only tell them to go make keysigning
parties and create PGP keys like we do.
>I'm sorry i'm not offering a specific solution right now. I would be
>happy if someone else came up with one, or if i got the time to work on
>the approaches that i think are promising.
Don't be sorry - it is super cool how you seek weak points and seem to
actually know these parts.
But could you be persuaded to play along with my game of assuming we
have FreedomBoxes at our hands? Not that we magically should trust
anything thrown into our boxes, but that we can assume them to not have
_some_ of the flaws inherent to the world at large, e.g. our boxes are
*not* born with *any* root certificates! Each FreedomBox need to grow
trust in e.g. Verisign the exact same way as ad-hoc (self-signed) and
peer-managed (i.e. CAcert.org style) root certs do.
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 836 bytes
Desc: Digital signature