- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Fri, 14 Jun 2013 13:19:38 +0200
- To: Kingsley Idehen <kidehen@openlinksw.com>
- Cc: public-webid <public-webid@w3.org>
- Message-ID: <CAKaEYh+=srdBB68kwS6XozgWSO_5egTr8NpEwQdi+tTjnZ5BbQ@mail.gmail.com>
On 14 June 2013 13:01, Kingsley Idehen <kidehen@openlinksw.com> wrote: > On 6/13/13 8:16 PM, Melvin Carvalho wrote: > > > > > On 14 June 2013 02:11, Kingsley Idehen <kidehen@openlinksw.com> wrote: > >> On 6/13/13 7:12 PM, Melvin Carvalho wrote: >> >> >> >> >> 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? >> >> >> 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). >> > > The "concept" that is being hashed is the Cert. > > > Yes. > > > But what is the "string" being hashed? > > > The content that describes the concept. Thus, the di: scheme URI is just > another URIs that denotes a concept such that look-up (de-reference) > resolves to description oriented content. We have a resolver for the di: > scheme URI hence the &http parameter. > We need the di: to be an IFP ... then I can do cool things like send money to your account. That means it needs to be known or standardized how you got from the Cert Concept -> String Serialization -> Digest Hash The first part is unknown, that's what I'm asking ... > > > Kingsley > > > >> >> Kingsley >> >> >> >>> >>> >>> -- >>> >>> 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 >> >> >> >> > > > -- > > 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 11:20:09 UTC