- From: Henry Story <henry.story@bblfish.net>
- Date: Wed, 6 Apr 2011 22:36:06 +0200
- To: peter williams <home_pw@msn.com>
- Cc: "'Kingsley Idehen'" <kidehen@openlinksw.com>, "'WebID XG'" <public-xg-webid@w3.org>
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. Henry > > 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 http://bblfish.net/
Received on Wednesday, 6 April 2011 20:36:38 UTC