Re: How to request a WebID?

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.

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

Received on Wednesday, 6 April 2011 21:16:12 UTC