- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Thu, 13 Jun 2013 13:17:59 -0400
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- CC: public-webid <public-webid@w3.org>
- Message-ID: <51B9FEC7.5090705@openlinksw.com>
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. > > Do we need to document this? If you want to make a di: scheme URI you simply follow the di: scheme specs. Thus, it's about a note in the right place. Trouble is the place isn't clear :-) Kingsley > > > > Kingsley >> >> >> >> Henry >> >>> >>>> >>>> >>>> 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/ >>>> >>>> >>> >>> Social Web Architect >>> http://bblfish.net/ >>> >>> >> >> 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 <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
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Thursday, 13 June 2013 17:18:23 UTC