W3C home > Mailing lists > Public > public-xg-webid@w3.org > April 2011

Re: How to request a WebID?

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Wed, 06 Apr 2011 17:41:51 -0400
Message-ID: <4D9CDE1F.3000604@openlinksw.com>
To: Andrei Sambra <andrei@fcns.eu>
CC: peter williams <home_pw@msn.com>, 'WebID XG' <public-xg-webid@w3.org>
On 4/6/11 5:14 PM, Andrei Sambra wrote:
> On Wed, 2011-04-06 at 16:47 -0400, Kingsley Idehen wrote:
>> On 4/6/11 4:16 PM, peter williams wrote:
>>> The single biggest road block I have is that my realtors take their personal
>>> laptop into their brokers office where they rent desk space (having just had
>>> webid working fine, over starbucks wifi); and webid stops working. That's
>>> because the larger corporate brokers run firewalls that intercept https -
>>> which breaks webid.
>>> This is the reality of my user group ; they are half corporate, half
>>> consumer; being intensely mobile. Though their laptops are windows home
>>> edition (or worse), which they connect to enterprise lans - at which point
>>> the DHCP service auto-issues the PC LAN connection a new web proxy endpoint
>>> - which then does the https interception (and thus the webid interference).
>>> To talk to the broker's sharepoint LAN site (which delivers them their
>>> broker backoffice tools), they have already imported the broker's root cert
>>> (issued by the local Microsoft CA). So the proxy (based on the same root)
>>> appears seemless to them, as it spoofs the real https sendpoint.
>>> Being consumer-grade users, they they just will not tolerate something
>>> working and not working, depending where they plugin their PC. They probably
>>> don't give a damn about the friendly broker doing the interception thing
>>> (the whole liability handoff thing is part of the realtor/broker handshake).
>>> Now, technically, we may have to develop a layer 7 bridge, in which one can
>>> post SSL messages over HTTP POST, to tunnel **past** the "interfering" TLS
>>> web proxy. This is perhaps where the ssl client built in a page's javascript
>>> comes in, I think.
>>> So Long as ONLY the client authn https handshake is tunnelled OVER the
>>> https-intercepting/interfering firewall, I don't think there would be any
>>> objection to a layer 7 SSL deployment that bypasses the intercepting proxy.
>>> Realty brokers (enforcing legal regulations on spying, snooping, data
>>> retention, etc in order to cover their very major financial liabilities) can
>>> still insist most "transactional use case" https traffic is intercepted.
>> What about IPv6 with IPSec enhanced with WebID? Could the move to IPv6
>> be an alternative route via WebID tweak of IPSec?
>>> Ok, this is the art of making research into a product someone wants to buy.
>> Yes, but also one of the more extreme since the whole world needs to
>> unshackling from myopic data silos that already pervade the Web.
>> I think being able deal with the following already hits the opportunity
>> cost palpability mark:
>> 1. Sharing resources across Depts
>> 2. Ditto across Divisions
>> 3. Ditto across InterWeb.
>> On the personal front:
>> 1. Sharing ACL protected resources across InterWeb -- photos, music,
>> videos, bookmarks, calendars, addressbooks, reports etc..
>> 2. ACL protecting comments - blogs, wikis etc..
>> 3. Smart notification services -- SemanticPingbacks vs broken Web 2.0
>> Pingback
>> 4. Inbox reclaim -- WebID enhanced S/MIME (which we've already
>> implemented successfully).
> I am actually doing research on these topics, as part of my PhD. (though
> I've recently started), so I should be able to at least get an overview
> of current possibilities and maybe propose some improvements soon. I
> will try to put together a small "paper" on it.


Keep us all posted :-)

> Andrei
>> Kingsley
>>> It has to actually work in the reality folks live in, not research reality.
>>> I don't mind selling the future a bit (to show the movement has 5+ years of
>>> momentum), but it HAS to actually work, today.
>>> Ok. Is there anything a browser vendor can do to help enable SSL engines -
>>> running in javascript?
>>> For windows for example, they can make the SSL ciphersuites available to the
>>> COM API usable by IE-hosted pages, so the platform's primitives deliver the
>>> specialized SSL HMACing, and the sessionid caching, etc
>>> -----Original Message-----
>>> From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org]
>>> On Behalf Of Kingsley Idehen
>>> Sent: Wednesday, April 06, 2011 9:21 AM
>>> To: Peter Williams
>>> Cc: WebID XG
>>> Subject: Re: How to request a WebID?
>>> On 4/6/11 11:58 AM, Peter Williams wrote:
>>>> Using the myxwiki as a test platform, I found something strange:
>>>> Having used opera to enroll and the export the credentials to a . P12
>>>> file
>>>> 1 I could complete webid using an opera browser on several versions of
>>>> windows (having imported the .p12)
>>>> 2 I could do the same with install versions of ie 8 and 9 (after .p12
>>> import).
>>>> 3 on the same pc as the ie case, my own https client will fail to complete
>>> webid - using the same certs as available to ie. (all acls, etc, were
>>> addressed). Something in the webservice client/server lib for the x509token
>>> validator  behavior  seems to prevent the cert bring used (even though it
>>> supplied as the desired cert at the API).
>>>> If I guess, it's because the cert from myxwiki is missing the pkix client
>>> authn oid. But this is only a guess. I cannot easily tell where the enforcer
>>> might be: whether it's clientside or serverside enforced.
>>> Peter,
>>> I assume you are repeating these tests using:
>>> http://id.myopenlink.net/ods ? I would appreciate QA and feedback re.
>>> that ODS based service too.
>>> You should be able to use IE, Safari, FF, Opera, and Chrome.
>>> Safari, IE, Chrome, and FF (plus .NET extension) will talk to the local host
>>> OS key store.
>>> Opera and FF (modulo .NET extension) use their own stores.
>>> Kingsley
>>>> On Apr 6, 2011, at 8:29 AM, Henry Story<henry.story@bblfish.net>    wrote:
>>>>> On 6 Apr 2011, at 17:18, Peter Williams wrote:
>>>>>> What l learned by trial is that not all browsers use the hints in the ca
>>> message of ssl. Others use it, quite literally. Both behaviours are
>>> conforming, as the message contains hints (only) by design. Your
>>> implementation may cue off the hints, or it may ignore them. Opera ignores.
>>> Ie uses. I dont know what safari does. I don't know what 10 browsers in
>>> iPhone-like phone browsers do.
>>>>> That's what we need a precise description of. Which browsers do,
>>>>> which don't. If enough do it, then it may be worth working on this. It
>>> comes up regularly.
>>>>> So I'll add to the issue that it requires working out which browsers this
>>> functions on.
>>>>>> In my https client, I uses a STD dialog of windows, also used by ie I
>>> suspect. The dialog allows several selectors, each of which constrain which
>>> of the certs in a users personal trust store are shown. (I don't know if
>>> this works on a windows phone, though.) Two options are natural (they are
>>> the kind of knowhow a security professional would be expected to show, on a
>>> certification test): using cert policy oid (as selector), using application
>>> policy oid (as selector).
>>>>>> There is another angle: whether any and all (selected) certs should be
>>> shown that match, or only those that have the netscape (or better the iso)
>>> client usage oid. But this begs yet another question: must that extension be
>>> marked critical? If it's not, an implementation is entitled to ignore it's
>>> hint. Thus unit test for client tend to be platform specific, unless one is
>>> careful.
>>>>> The Java libraries I have been working with add the netscape client
>>>>> usage oid. Anyone testing should try to get an idea of how each
>>>>> browser works currently, taking those into account. The we can see where
>>> we are starting from.



Kingsley Idehen	
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen
Received on Wednesday, 6 April 2011 21:42:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:43 UTC