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

Re: TLS-Light

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Thu, 01 Dec 2011 11:36:37 -0500
Message-ID: <4ED7AD15.3020606@openlinksw.com>
To: public-xg-webid@w3.org
On 12/1/11 7:59 AM, Peter Williams wrote:
> Ive come to the conclusion that the current and likely all 
> future versions of windows, natively, cannot be a platform for the 
> webid validation protocol - as conceived. Any native implementation 
> cannot be complete (and stay consistent with how windows natively is 
> supposed to be used). Windows will support many of the cases, but not 
> all. Per the threads title, the topic is indeed SSL (where I have lots 
> of expertise), and certs (where I have probably have the most 
> continuous years experience of anyone on the planet). Its a 
> specialized area in which handshakes, crypto and certs combine, to 
> enforce security policy in an trusted computing base. From what I can 
> tell, few folks here have any knowhow in this topic area - which is 
> quite normal - and its not driving the standard. Folks here are mostly 
> app programmers, working outside the a distributed kernel - and are 
> not too concerned with distributed operating system design.
>
> Windows and IIS 7 cannot naturally take a self-signed client cert on 
> an ssl handshake and work with it. The cert must be rooted, somehow, 
> beforehand.

Yes, and we have a Windows based Wizard that lets you do just that. Of 
course Windows will warn you continuously during the process, but it 
works. This is how we have WebID working with IE, for instance.

You are correct re. the hurdle, but it isn't insurmountable. The Wizard 
in question was built more than a year ago.

> There are lots of ways to root it (including cross-certs), but rooted 
> it must be. This is becuase windows is a B3-equivalent platform (see 
> Orange book for what that means), and information is labelled 
> (essentially) within the kernel (B1), with processes and threads being 
> similarly compartmentalized as a result (B3). Doing professional 
> crypto and information security, the kernel uses certs and keys and 
> handshakes and decipherment to enforce the rules of a trusted 
> computing based designed to impose and enforce label based integrity 
> and access controls. These are the things that harden an OS, and 
> protect one user from another in the assumed world of attacks on the 
> TCB's own code. once crypto for communications enters a kernel, it 
> hardends a network OS (or NOS). Today, the state of the art is NOS at 
> the scale of a active directory federation ("enterprise class" 
> windows). This means.. MAN scale, but not national or web scale.

Yes, but as I said not insurmountable.

>
> now none of that is a criticism of windows or the webid project. Im 
> doing actually what Im supposed to be doing - evaluating a security 
> standard core claims and design, as a engineer (vs an app programmer 
> writing scripts).
>
> There are two main impacts. First, the typical open source 15 year old 
> with the usual rancour will start bleating about how awful windows 
> therefore is, without understaning the engineering rationale for why a 
> properly engineered trusted computing base imposes such hard limits on 
> certs and key management. This will probably have the consequence that 
> folks will go back and put user mode SSL onto windows (using some 
> openssl class library) to "solve the problem" (and just undo the 
> hardening, for that class of app, for that account). Second, webid as 
> a standard has mandatory modes (self-signed certs etc) that mean *any* 
> complete implementation will always need a waiver, from assurance 
> standards. Its going to be rather hard to even formulate a webid 
> assurance standard, as webid is using keying and crypto in a way that 
> undermines conventional theories of assured crypto.
>
> The conclusion is that webid needs to stay doing what its doing; and i 
> do NOT want to see it cede its user centricity or fail to require that 
> unregistered, self-signed certs MUST be usable.

Yes. I guess I need to make a another start to finish guide re. WebID 
and IE. That's the simplest test. Without the root cert. WebID won't 
work. And that's the experience most will have out of the box which is a 
point of intertia if they aren't aware of our Cert. Generator for 
Windows, and others that hopefully come into existence.


> Digital certs on the open internet failed, and we can ultimately blame 
> the very requirements of and the concepts of TCB-based assurance for 
> that. A Webid profile is NOT a cert, and we are not doing old https 
> client authn. Webid must not be seen as being limited to what client 
> certs are limited to doing (when done correctly, as Microsoft did it).

Yes.

>
> I found the webid project fun. I learned lots about semantic 
> web technologies, met someone in Kingsely who I think will 
> revolutionize the web, and learned lots more more about the state of 
> modern windows (which can can help US real estate, still catching up 
> with the web of 5 years ago). I'm not sure there is anything left for 
> me to do, here, though. What expertise and experience I have, I think 
> I've already shared.

Maybe to play with our Wizard then attempt to convince us to make it 
Open Source :-)

Kingsley
>
>
>
>
>
>
>


-- 

Regards,

Kingsley Idehen	
Founder&  CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen








Received on Thursday, 1 December 2011 16:37:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 1 December 2011 16:37:13 GMT