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

On 6/13/13 6:57 PM, Melvin Carvalho wrote:
>
>
>
> On 13 June 2013 19:17, Kingsley Idehen <kidehen@openlinksw.com 
> <mailto:kidehen@openlinksw.com>> wrote:
>
>     On 6/13/13 11:02 AM, Melvin Carvalho wrote:
>>
>>
>>
>>     On 11 June 2013 22:15, Kingsley Idehen <kidehen@openlinksw.com
>>     <mailto:kidehen@openlinksw.com>> wrote:
>>
>>         On 6/11/13 3:58 PM, Melvin Carvalho wrote:
>>>
>>>
>>>
>>>         On 11 June 2013 21:50, Henry Story <henry.story@bblfish.net
>>>         <mailto:henry.story@bblfish.net>> wrote:
>>>
>>>
>>>             On 11 Jun 2013, at 21:47, Melvin Carvalho
>>>             <melvincarvalho@gmail.com
>>>             <mailto:melvincarvalho@gmail.com>> wrote:
>>>
>>>>
>>>>
>>>>
>>>>             On 11 June 2013 21:39, Henry Story
>>>>             <henry.story@bblfish.net
>>>>             <mailto:henry.story@bblfish.net>> wrote:
>>>>
>>>>
>>>>                 On 11 Jun 2013, at 21:28, Melvin Carvalho
>>>>                 <melvincarvalho@gmail.com
>>>>                 <mailto:melvincarvalho@gmail.com>> 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 ... ?
>>>>
>>>>                 And how do you stop a man in the middle changing
>>>>                 all those pieces of info as you fetch them?
>>>>                 What is the algorith you use for trusting those
>>>>                 people? How do you tell them to update their
>>>>                 system if your keys change? What do I do in case of
>>>>                 clash? Etc.... etc....
>>>>
>>>>                 I don't think that quick answers to this point on a
>>>>                 mailing list are going to be satisfactory.
>>>>                 You need someone full time on these issues, and
>>>>                 careful work with crypto specialists.
>>>>
>>>>
>>>>             I think, as with much of security, there's no perfect
>>>>             answer to these questions. Tho for each scenario you
>>>>             can devise a strategy.
>>>>
>>>>             But the principle here is that the mirrored claims make
>>>>             things incrementally better. What's wrong with
>>>>             incrementalism?
>>>
>>>             Well great. We're all waiting to see your implementation
>>>             and the spec that goes with it.
>>>
>>>
>>>         Well it only works if people start doing it.  The algorithm
>>>         is not too hard.
>>>
>>>         1. For each of your friend's keys, each with digest (d):
>>>
>>>         2. On your host add the document
>>>
>>>         /.well-known/di/d
>>>
>>>         Containing the triple
>>>
>>>         di:d
>>>           cert : identity
>>>             <webid> .
>>
>>         We have to get around /.well-known/ due to its issues with
>>         letting users have full control, even when they don't control
>>         or possess admin privileges for a DNS server.
>>
>>         You can handle this by adding a URL parameter to the di:
>>         scheme URI. Net effect, you can point to the location of the
>>         document associated with the digest denoted by the di: scheme
>>         URI.
>>
>>         We do exactly what I just described in our X.509 cert
>>         generation services:
>>
>>         1. http://id.myopenlink.net/certgen
>>         2. http://youid.openlinksw.com
>>
>>         Example:
>>
>>         1. http://id.myopenlink.net/certgen/key/7959 -- public key URI
>>         2. http://id.myopenlink.net/c/BVH477 -- page describing the
>>         cert associated with the public key
>>         3.
>>         di:sha1;Ufn4rImd6QKET8LqDZwCkRaufLo?hashtag=webid&http=id.myopenlink.net
>>         <http://id.myopenlink.net> -- di: scheme URI with the URL
>>         parameter
>>         4.
>>         http://kingsley.idehen.net/about/html/di:sha1;Ufn4rImd6QKET8LqDZwCkRaufLo?hashtag=webid&http=id.myopenlink.net
>>         5.
>>         http://kingsley.idehen.net/about/html/di:sha1;Ufn4rImd6QKET8LqDZwCkRaufLo?hashtag=webid&http=id.myopenlink.net
>>         -- back to the original public key description.
>>
>>
>>     These links are awesome.  How did you generate the string:
>>
>>     sha1;Ufn4rImd6QKET8LqDZwCkRaufLo
>
>     SHA-1 hash function. In our case, its built into the certificate
>     generator which leverages Virtuoso's in-built layer to crypto stuff.
>
>
> So you're taking the SHA-1 of "something".  What is that something?

X.509 certificate, as expressed in the digestURI relation:

1. 
http://id.myopenlink.net/describe/?url=http%3A%2F%2Fid.myopenlink.net%2Fabout%2Fid%2Fentity%2Fhttp%2Fgraph.facebook.com%2Fkidehen%23cert51F9F8AC899DE902844FC2EA0D9C029116AE7CBA 
-- certificate description

2. http://www.openlinksw.com/schemas/cert#digestURI -- denotes the 
relation .

3. 
http://id.myopenlink.net/describe/?url=http%3A%2F%2Fwww.openlinksw.com%2Fschemas%2Fcert%23digestURI 
-- page describing the relation .

-- 

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

Received on Thursday, 13 June 2013 23:05:35 UTC