Re: mitigating Webid (+ TLS') single point of failure

On 6/11/13 3:28 PM, Melvin Carvalho wrote:
>
>
>
> On 11 June 2013 20:20, Henry Story <henry.story@bblfish.net 
> <mailto:henry.story@bblfish.net>> wrote:
>
>     Melvin, you forget that you could also use .onion or .garlic urls
>     if you really don't want to rely on DNS.
>
>     As for the rest I think it is interesting. But it seems like a lot
>     of work, which will require
>     working on a logic of trust, and much more. Perhaps a Phd thesis?
>
>
> You really think it's that much work?  OK, then how about this:  we 
> each take the keys of people in our friends list, and cache the 
> reverse lookup for them ... ?

Make an RDF document that has statements describing how the keys and 
WebIDs are associated (a reverse lookup is just a relation). Done.

Kingsley
>
>
>
>     On 11 Jun 2013, at 18:30, Melvin Carvalho
>     <melvincarvalho@gmail.com <mailto:melvincarvalho@gmail.com>> wrote:
>
>>     The WebID + TLS flow has one single point of failure, and that is
>>     that you have to trust the profile page.  If the profile page is
>>     somehow compromised, or the victim of a MITM attack your whole
>>     authentication process could be compromised.
>>
>>     Now some people say you can add trust by adding an SSL
>>     certificate, or in the future, perhaps DNSSEC.  However, this can
>>     be unsatisfactory, because A) it's costly, B) you are just
>>     shifting the single point of failure around.  Other projects have
>>     pushed back against using WebID for this reason.
>>
>>     A more effective technique might be to distribute trust across
>>     the whole web.
>>
>>     When the TLS handshake takes part, the sever can be
>>     mathematically sure, that the public key it receives is authentic.
>>
>>     The *standard* flow is to add a forward follow-your-nose lookup
>>     from the certificate to your profile page. But what if we, as a
>>     community, were to distribute the trust across many many servers,
>>     using the read write web.
>>
>>     Instead of a FORWARD (follow your nose) lookup, you can do a
>>     REVERSE lookup on the public key, using the di: (digest) URI
>>     scheme.  A neat feature of the di: spec is that it also has a
>>     /.well-known/di directory where you can put digests and and get
>>     back a document.
>>
>>     It may be fairly simple to set up a single directory that allows
>>     users to go in and update their info on your server.   You may
>>     even charge a small fee for it.
>>
>>     In this way a server does not have to rely on a single point of
>>     failure as the relationship between a key and a user will be
>>     distributed in many places.  In this way you can perform extra
>>     checks as required to verify the authenticity of a login, as
>>     needed...
>>
>>
>
>     Social Web Architect
>     http://bblfish.net/
>
>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen