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:http://lair.fifthhorseman.net/~dkg/tls-centralization/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 everyone.
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 -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: Digital signature
_______________________________________________ Freedombox-discuss mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/freedombox-discuss
