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

RE: How to request a WebID?

From: peter williams <home_pw@msn.com>
Date: Wed, 6 Apr 2011 13:16:28 -0700
Message-ID: <SNT143-ds1424463E1E8A820E9A901092A50@phx.gbl>
To: "'Kingsley Idehen'" <kidehen@openlinksw.com>
CC: "'WebID XG'" <public-xg-webid@w3.org>
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.

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
> 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.


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.

> 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
>> 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 20:17:26 UTC

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