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

On 7 Dec 2011, at 16:13, Kingsley Idehen wrote:

> On 12/7/11 9:49 AM, Henry Story wrote:
>> 
>> 
>> On 7 Dec 2011, at 15:32, Kingsley Idehen wrote:
>> 
>>> On 12/7/11 8:47 AM, Henry Story wrote:
>>>> 
>>>> 
>>>> On 7 Dec 2011, at 14:07, Kingsley Idehen wrote:
>>>> 
>>>>> On 12/7/11 7:47 AM, Henry Story wrote:
>>>>>> 
>>>>>> 
>>>>>> On 7 Dec 2011, at 13:15, Kingsley Idehen wrote:
>>>>>> 
>>>>>>> On 12/7/11 4:36 AM, Henry Story wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 7 Dec 2011, at 01:36, Peter Williams wrote:
>>>>>>>> 
>>>>>>>>>  
>>>>>>>>>  
>>>>>>>>> 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.
>>>>>>>> 
>>>>>>>> Ah good. So originally when I was arguing that Kingsley had misread you I was right. You could have supported my view at that time.
>>>>>>>> As you were silent I started taking on Kingsley's position.
>>>>>>> 
>>>>>>> IIS and IE are sort of doing the same thing. I am saying that IE will not work with Certs. that aren't signed by a Cert. rooted on its host machine or a network server (depending on your Windows network setup). 
>>>>>> 
>>>>>>> Not working means that the TLS handshake will fail.
>>>>>> 
>>>>>> Ok, so you are saying with Peter Williams that unless IIS Trusts the Signer of the Certificate it receives, the handshake will fail. So IIS would need to know the Singing authority of every web site.
>>>>> 
>>>>> No, it just needs a CA trust chain. Thus, you can make you own by generating a CA cert. and storing it in the keystore as a new CA root. Basically, you end up with the default CA trust chain that comes with Windows plus new chains you construct yourself via your own root Certs. 
>>>> 
>>>> yes, but then your IIS instance would only be able to accept Certificates signed by yourself right?
>>> 
>>> No, any cert. signed with a CA cert. that has been persisted to the OS keystore as a Root CA. This is really about Windows admin first. Nothing to really to with WebID per se., bar IdPs understanding this requirement. 
>>> 
>>> WebID isn't anti CA, it simply says: you can play ball with self-signed certs. The problem arises when trying to follow the self-signed meme verbatim in a Windows setup. That's where there is impedance that is a result of not reflecting Windows expectations as expressed by IIS and IE.
>>> 
>>>>  Since you are the one in possession of the new CA root you just stored in your keystone. 
>>> 
>>> You can send me a cert. and I can also add that to my store as long as it is a CA cert.

If we are at that level we break the whole WebID flow. The whole problem of CA based certificate authentication is that it has to be done through the verification of CAs which we need a list of. This is what made CA signed client certificates unworkable on the larger web. 

>>> 
>>>> 
>>>> In particular Peter Williams is asserting that your IIS instance would not be able to accept a certificate signed by the CA Root I created and stored in my keystore, not that is without having as a policy to add any CA you find automatically to your trust store.
>>> 
>>> As per comment above, it just has to be registered. On your machine you do it yourself. If you machine is part of a domain controller setup (network or forest of domain controller regulated networks) you need to lodge the certificate in the appropriate store.
>>> 
>>>> The danger of doing that is that unless you change the logic of how all windows apps works with trust stores, you would be essentially disabling all of Windows security by doing that. An evil person ( Dr Evil ) could just create a new CA certificate, sign a WebID certificate with it, authenticate on your IIS with the WebID Cert, and then know that its root CA would be in your trust store. All the other pieces of Windows software that would then automatically rely on that CA certificate  Dr Evil had generated and trust every certificate Dr Evil signed.
>>> 
>>> Not really, remember, this is WebID, if the relation lookup fails it's all useless. Again, this is really more about guidance for IdPs making certs for Windows users re. IE and IIS.
>> 
>> Peter Williams' point it that you need to add Dr Evil's CA to your trust store, the same trust store all other Windows apps rely on if your connection is not going to fail. If you do that his point is that you break Windows security logic, as other applications that use the trust store written by M$ perhaps will not know about the WebID protocol.
> 
> 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 suppose that what Peter means by "rooted in the Windows Host is that he means the CA is in the trust chain.

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

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.

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


> 
>> 
>>> 
>>>> 
>>>> 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"?

> 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.
If that is the case then WebID cannot get going on 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?

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



> 
> 
>> 
>> In the meantime I think there is not requirement in the W3C to use IIS, and there is no requirement for Windows users to use it either.
> 
> Same applies to Apache, Virtuoso, or any other HTTP server. 
> 
>> Indeed legally they would not be allowed to do that. So this is no different form discovering that certain things about WebID are difficult to do in Jetty for example. Not all server software is the easiest to work with currently. But we are not trying to write a spec that works without changing any software. It is easier to change server software then it is to change all the web browsers in the world, as it is a decision individuals can make by themselves. So people who want to participate now in WebID should choose software that works now.
> 
> And they can right now without any platform bias. 
> 
>> As it gains momentum I am sure Microsoft will do the needed work. It is just as with HTML5. When the spec goes most browsers do not support HTML5. At the same time it is important that most browsers support most of it already, and that servers not have to be completely rewritten.
> 
> Really irrelevant to the matter. Why introduce problems that do not exist? Why are you singling out Microsoft unnecessarily? This spec isn't about Microsoft, Open Source, or anyone other entity. It's about a spec for Web scale verifiable identity via URIs that leverages combined exploitation of PKI and Trust Logics. 

I am not singling out Microsoft for anything other than the curren issue at hand. Peter Williams has claimed clearly and vocally that you cannot
use IIS with WebID without breaking Windows security. 

I can tell you about issues with current implementations of Jetty for example. That would not be singling out jetty. It is just a question of the topic of the conversation.




> 
> Kingsley
>> 
>> 
>> Henry
[snip]