- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Fri, 14 Jun 2013 07:01:49 -0400
- To: public-webid@w3.org
- Message-ID: <51BAF81D.2050500@openlinksw.com>
On 6/13/13 8:16 PM, Melvin Carvalho wrote: > > > > On 14 June 2013 02:11, Kingsley Idehen <kidehen@openlinksw.com > <mailto: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 >> <mailto: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 <mailto: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 >>>> <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. >>> >>> >>> 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. Kingsley > > > Kingsley >> >> >> >> -- >> >> 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 <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 Friday, 14 June 2013 11:01:52 UTC