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

Re: How to request a WebID?

From: Henry Story <henry.story@bblfish.net>
Date: Wed, 6 Apr 2011 22:36:06 +0200
Cc: "'Kingsley Idehen'" <kidehen@openlinksw.com>, "'WebID XG'" <public-xg-webid@w3.org>
Message-Id: <8D3961E9-19C8-4D85-96D3-7ED653D3D66B@bblfish.net>
To: peter williams <home_pw@msn.com>

On 6 Apr 2011, at 22:16, 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.

We can't deal with every use case here. Their firm should buy them wireless
with a provider that permits ssl to work everywhere. If they can't afford that
then they probably don't care about security, and I suggest they use openid.

We can let the market work around silly issues. We can't solve every issue here.


> 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.
> Ok, this is the art of making research into a product someone wants to buy.
> 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.
> -- 
> Regards,
> Kingsley Idehen	
> President&  CEO
> OpenLink Software
> Web: http://www.openlinksw.com
> Weblog: http://www.openlinksw.com/blog/~kidehen
> Twitter/Identi.ca: kidehen

Social Web Architect
Received on Wednesday, 6 April 2011 20:36:38 UTC

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