- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Fri, 14 Jun 2013 01:12:17 +0200
- To: Kingsley Idehen <kidehen@openlinksw.com>
- Cc: public-webid <public-webid@w3.org>
- Message-ID: <CAKaEYh+ybrcB7DAPJtfznhhKDstaA8+fga2UTTaLYhUiF1_jWA@mail.gmail.com>
On 14 June 2013 01:05, Kingsley Idehen <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> 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? > > > 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? > > > -- > > 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:12:44 UTC