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

On 6/13/13 7:12 PM, Melvin Carvalho wrote:
>
>
>
> On 14 June 2013 01:05, Kingsley Idehen <kidehen@openlinksw.com 
> <mailto:kidehen@openlinksw.com>> wrote:
>
>     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 .
>
>
> Thanks kingsley, so the digest is a hash of the Certificate.
>
> But if I wanted to verify that, how would I do it?
>
> Dont I need to know the serialization that you used for the digest and 
> the canonicalization method?

If you have the Cert, hash function, public key, and signature data at 
hand, you can verify the Certificate. Of course, you can do all sorts of 
things by just keeping to the basic rules for digital signature 
verification re. standard PKI (modulo CA network of course).

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


-- 

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 Friday, 14 June 2013 00:12:21 UTC