Re: Back to IIS -Was: ExplorerKeygen - keygen element for IE

On 12/7/11 10:54 AM, Henry Story wrote:
>> I don't agree with your characterization of his point. Its coming 
>> from a subjective place that isn't based on actual Windows usage.
>
> What am I misreading in what Peter wrote clearly here:
>
> http://lists.w3.org/Archives/Public/public-xg-webid/2011Dec/0059.html
>
> [[
> My work was about running a validation agent on IIS. Peter argued that IIS could not process a client certificate (self-signed or otherwise) that was not rooted on the windows host, on which IIS (or other native https server app) is listening. Does anyone claim this argument is invalid?
> ]]
>
> So do you claim it is invalid, or do you agree with Peter there?

I don't agree with:  *(self-signed or otherwise)* .

There is a problem if its just self-signed.

>
> I suppose that what Peter means by "rooted in the Windows Host is that 
> he means the CA is in the trust chain.

But you can have different trust chains. Hence the need for you to make 
your own root when you are the CA. Or integrate your cert into the CA 
trust chain for the Windows network.

>
>>
>> You have to perform this task with Windows user mindset in place. If 
>> I decide to register a CA Root Cert. that I have generated for myself 
>> as a notary that ultimately is used for other certificates I 
>> generate. BTW - Windows is sophisticated enough to still not use 
>> these certs for blank security policies. The system is very fined 
>> grained re. authentication and authorization policies.
>
> Ok. Good so we need to work out if these fine grained authorisation 
> policies can close the gap.

They do, that's why they exist.

The trouble is (as always) if people use default settings, then of 
course there are openings for signer/notary x.509 Certs. registered in 
the CA trust chain that could cause problems modulo WebID verification.

> Can you for example accept any CA you don't know and add it to the 
> Trust Store with the policy that ONLY one application, or ONLY WebID 
> enabled apps can use it?
>>
>>>
>>> So currently we should warn people not to use IIS until microsoft 
>>> updates its security logic to accept the more flexible WebID claims 
>>> based logic.
>>
>> No, that's simply unnecessary. Acknowledge the fact that Windows as 
>> its set of security expectations. These expectations are well know by 
>> Windows admins and even end-users. Don't make warnings about Windows 
>> if you don't use it. The net effect is that such comments will come 
>> across as ill informed FUD aimed at the platform from an anti Windows 
>> community.
>
> Now it is quite possible that Peter Williams works for Oracle in 
> disguise and is trying to spread FUD on Windows. But then we should 
> expose him.
>
> I am just trying to get to the bottom of this issue here. Remember 
>  that Peter Williams promised that by this week he would have a 
> working IIS server running with WebID. Then he gave up because of this 
> problem that he claims exists in IIS and which he also has numerously 
> claimed he is an expert of - that he know more about it than all of us 
> who are on this list put together.

He is claims are scoped to Certificates and PKI. I don't think he is 
claiming to be an expert Windows Admin per se. I believe he is saying, 
if I follow Windows security expectations here's where I end up.

Where Peter and I might differ is this issue of *(self-signed or 
otherwise)*. To me otherwise is about self-notary dimension via CA certs 
generated for yourself and placed in the CA root of your own machine or 
integrated into the Windows network in line with organization security 
policies.

>
> So If we accept that [a] Peter Williams is an expert on windows and he 
> says that [b] IIS cannot be used as is with WebID, then we must accept 
> that
> [c] IIS cannot be used with WebID.

Not true.

>
> Now I think if you can show that he is wrong on [c] that is ok. But 
> that is his challenge.

We can fine the middle ground as there is ultimately a little void that 
needs to be bridged :-)


>
>
>>
>>>
>>>>
>>>>>
>>>>> In the end this is not a big problem, because people can use 
>>>>> Apache, Java or other web servers that are less tied to the 
>>>>> kernel, and wait for Windows to update its logic which can only be 
>>>>> when WebId is very widely used, as that will be enough to justify 
>>>>> the expense required of going through the work.
>>>>
>>>> That isn't the answer, esp. as this isn't an intrinsic WebID 
>>>> problem. Its about understanding the deployment platform requirements.
>>>
>>> That is the point made by Peter Williams who claims to know this 
>>> inside out. He says that if you understand the microsoft deployment 
>>> platform you cannot deploy WebID on IIS currently without breaking 
>>> the windows security model/
>>
>> He is saying: if you simply go signed certificate, instead of:
>
> "go signed certificate" does not make sense. You are missing a word 
> there. Did you mean "self-signed"?

Sorry, self-signed (note: I type mega fast cos I multitask 100% of the 
time, lots of typos!).

>
>> 1. make a signing cert. (role: notary)
>> 2. sign certs by notary.
>>
>> Note: "You" can play the notary role. Again, so called Dr. Evil certs 
>> will have no real bearing on a Windows setup with authentication and 
>> authorization policies in place.
>
> Yes. But that is not all his claim. He also claims that all IIS 
> servers need to have that Certificate in their trust store or they 
> will break the connection.

IE does the same thing.

> If that is the case then WebID cannot get going on IIS.

I know it can, but we can start writing a module for IIS when we've 
built our own native HTTP servers for Windows. At the right time, if 
need be, I'll commission such a thing for our .NET based HTTP server 
(yet another alternative we built years ago for Windows) and have it 
share a module that can be hooked into IIS.

>
>>
>> The nuance here is this: WebID guides and narratives used to skewed 
>> towards self-signed certs. For Windows the certs. have to be 
>> notarized i.e., signed a  CA (and that can be you) and then stored as 
>> a CA root in your local keystore or appropriate domain controller in 
>> the Windows network or forest of domains.
>
> The problem is how do you distribute those CA certs?

On Windows you have:

1. Your PC
2. Your PC in a Windows network with a single Domain Controller
3. Your PC in a Windows network with multiple Domain Controllers i.e., a 
forest.

Each of the above has implications re. CA certs and placement in 
respective keystores as Root Certs (new chain) or part of existing chains.

WebID is really more about #1 running IE.

IIS comes into play when it is providing access to resources on the 
network. Like IE it works with Windows in line with its security 
oriented architecture.

>
>>
>>>
>>> Well not unless you do some serious work which Peter Williams claims 
>>> microsoft could do, and perhaps better hackers can do before hand. 
>>> Not me though as I don't know how that functions.
>>
>> It's a none issue.
>
> This is not what Peter Williams claims. Let me cite you what he says:
>
> [[
> Peter argued that IIS could not process a client certificate 
> (self-signed or otherwise) that was not rooted on the windows host, on 
> which IIS (or other native https server app) is listening.
>
> Does anyone claim this argument is invalid?
> A simple contradiction claim is fine. I would LIKE to do this, so we 
> can say windows can 100% implement webid. My proof is only 99% (since 
> my validation authority cannot process abitary client  certs, without 
> an act of pre-registration)..
> ]]
>

Windows compatibility with WebID is not an issue of debate. Even if what 
Peter said was 100% accurate. It just means that IIS module development 
has some complexities, and these could be impediments to WebID bootstrap 
for those that want to take the IIS route. Remember, FOSS folks have 
written modules for Apache too.

-- 

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