- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Fri, 14 Jun 2013 00:57:59 +0200
- To: Kingsley Idehen <kidehen@openlinksw.com>
- Cc: public-webid <public-webid@w3.org>
- Message-ID: <CAKaEYhJmR0=4bQUa2zjyy1r9q25RerLJ0shEhEjfOy8Amv+9tw@mail.gmail.com>
On 13 June 2013 19:17, Kingsley Idehen <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> wrote: > >> On 6/11/13 3:58 PM, Melvin Carvalho wrote: >> >> >> >> >> On 11 June 2013 21:50, Henry Story <henry.story@bblfish.net> wrote: >> >>> >>> On 11 Jun 2013, at 21:47, Melvin Carvalho <melvincarvalho@gmail.com> >>> wrote: >>> >>> >>> >>> >>> On 11 June 2013 21:39, Henry Story <henry.story@bblfish.net> wrote: >>> >>>> >>>> On 11 Jun 2013, at 21:28, Melvin Carvalho <melvincarvalho@gmail.com> >>>> wrote: >>>> >>>> >>>> >>>> >>>> On 11 June 2013 20:20, Henry Story <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 -- 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? > > > 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> >>>>> 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 >> 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 Thursday, 13 June 2013 22:58:28 UTC