- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Tue, 11 Jun 2013 16:15:23 -0400
- To: public-webid@w3.org
- Message-ID: <51B7855B.3000605@openlinksw.com>
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 -- 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. 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 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 Tuesday, 11 June 2013 20:15:47 UTC