RE: Major Milestone: WebID over WebSockets

I read the websockets spec, last week. And, I read what it was intended for (versus what its not). Of course, none of that stops people using it as a general purpose transport, much like folks use http as a tunnel across firewalls. Of course, deep packet inspection and TLS MITM firewalls exist - to inspect the tunneled protocols. The reason webid struggle to cross firewalls doing SSL is BECUASE of the need to inspect "illicit" protocols , tunneled. clien certs suffered, since firewalls intefere with end-end SSL handshakes. Second, crypto quality is largely a function of assurance not APIs. Windows browsers have had optional activeX controls in their build for years, that give javascript access to the platforms own Crypto API. IE is just a collection of activeX controls inside a container, and adding one more either in the build, or in the packaging a corporate entity uses, or in a web page (through the object tag), is normal. Sun microsofts used to drivel on about how threatening it was (in hogwash marketing about the inherent security of java-based browsers).  Third, crypto assurance is largely about hardware, not software. If users and programmers can tamper with the crypto (that  delivers strength to a mechanism), so can attackers - who are just other programmers. At this point one needs a point of trust on the platform, that protects the software against tampering. This is the long term crux of the argument about why IE is tied to the OS. its the root cause of my problems on the IIS side, where its crypto too is tied to hardware trust design (dont allow programmers to tamper, including application programmers).  its from hardware, to kernel, to certs to APIs that makes webid hard to implement in (excellent) windows security design. So, lets not get obsessed with crypto APIs. we have had them for years. The art is to make trusted crypto. I will forsee that MANY arguments will be made why the "leap" made for javascript source-based crypto libs will, ahem, somehow necessarily require that keying be less than spectaculrly assured. The art will be to "re-educate" folks, that keying should be "done a particualr way", always. That is, if folks get (vendor-) free'd crypto, it will come with a hobbled key management, as a counterweight. Its the nature of society that a leap in one direction on crypto tends to be compensated by a fall in another (key management or platform trustworthiness) The urge to spy runs deep. Its quite cheap to bribe the software platform vendors (and the folks architecting standards). Its been demonstrated repeatedly that many security standards were "structured" for covert goals.          
 > From: henry.story@bblfish.net
> Date: Thu, 22 Dec 2011 11:48:55 +0100
> CC: public-xg-webid@w3.org
> To: msporny@digitalbazaar.com; public-identity@w3.org
> Subject: Re: Major Milestone: WebID over WebSockets
> 
> 
> On 22 Dec 2011, at 11:37, Henry Story wrote:
> 
> > What I have initially had trouble understanding in Dave Longley's javascript implementation 
> > of WebID is how the keys generated in one server and save in a local datastore
> > get used from one server to another. That is never made clear  in any documentation I have
> > seen.
> > 
> > In a conversation some time ago with one of the developers, I learnt that essentially until
> > the browser supports javascript access to the local keystone there is a lot of jumping around
> > using perhaps even OAuth in the background. So that means that the protocols in the
> > background is in fact very complicated and probably very difficult to secure. Cryptography
> > is notoriously tricky to get right, and javascript comes itself with a huge number of security
> > issues.
> > 
> > But all is not lost
> > 
> > There is a group called the Web Crypto API that is being put in place
> >  http://www.w3.org/wiki/IdentityCharter
> 
> Sorry the correct link is here now:
>    http://www.w3.org/2011/11/webcryptography-charter.html
> And they had/have their discussions on the public-identity@w3.org . They reduced their
> aims from identity to cryptography and are in the final stages of building the charter.
> 
> 
> > 
> > And they are just developing their charter. If browsers support apis to have
> > direct access to the crypto layer then of course those back end hacks won't be
> > needed and furthermore it will be secure, in which case one could use javascript
> > to do the WebID authentication perhaps to bring in web sites that don't have 
> > TLS (hopefully a slowly diminishing number with DNSsec deployment)
> > 
> > At the same time I think we can look at this work as a way to do proofs of concepts
> > to open a discussion with BrowserId which also needs such a web cryptography layer.
> > 
> > Is Dave participating in the Crypto API group? I think that would be very useful.
> > 
> > Henry
> > 
> > 
> > On 10 May 2011, at 02:15, Manu Sporny wrote:
> > 
> >> Our CTO, Dave Longley, has been busy over the past week attempting to
> >> get our pure JavaScript crypto/TLS library updated to remove the Flash
> >> requirement from our WebID demos. He was successful.
> >> 
> >> Using a WebSockets-enabled browser, such as Google Chrome - go here and
> >> create an account (accept the invalid, demo-only SSL certificate for now):
> >> 
> >> https://webid.digitalbazaar.com/manage/
> >> 
> >> Then go here:
> >> 
> >> https://payswarm.com/webid-demo/
> >> 
> >> Select "Digital Bazaar WebID" as the provider and then "Select
> >> (WebSocket)". You will be logged in and the login works faster than the
> >> Flash-based version of our WebID implementation.
> >> 
> >> Just to be clear - this is a complete, open-source implementation of
> >> x509, TLS, and WebID using pure JavaScript and standards-based browser
> >> technologies.
> >> 
> >> You can view the source for Forge (the JavaScript x509/TLS/WebSockets
> >> library) here:
> >> 
> >> https://github.com/digitalbazaar/forge
> >> 
> >> You can view the source for the WebID demo here:
> >> 
> >> https://github.com/digitalbazaar/webid-demo
> >> 
> >> -- manu
> >> 
> >> -- 
> >> Manu Sporny (skype: msporny, twitter: manusporny)
> >> President/CEO - Digital Bazaar, Inc.
> >> blog: PaySwarm Developer Tools and Demo Released
> >> http://digitalbazaar.com/2011/05/05/payswarm-sandbox/
> >> 
> >> 
> > 
> > Social Web Architect
> > http://bblfish.net/
> > 
> 
> Social Web Architect
> http://bblfish.net/
> 
>