Re: ExplorerKeygen - keygen element for IE

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

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.

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

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

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.

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


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

Kingsley
>
>
> Henry
>
>>
>>>
>>>>
>>>> This is all about you taking control of your machine or having your 
>>>> machine adhere to trust chains in a Windows network which can even 
>>>> take the form of a forest with many domain controllers etc..
>>>>
>>>> From a WebID perspective the impact area boils down to IdPs being 
>>>> able to produce a signing cert. (i.e., CA cert) and a signed 
>>>> certificate. You can be the notary and the certificate signer re. 
>>>> Windows.
>>>>
>>>>> If that is the case then until someone provides a patch for IIS to 
>>>>> allow it to work with Null Trust Authorities, then IIS cannot use 
>>>>> WebID.
>>>>
>>>> Of course it can. It just requires the steps above.
>>>>
>>>>> I am sure if we can do this with Apache and Java they can do it 
>>>>> to, but since they built it into the kernel - against the 
>>>>> arguments of various leading technologists - things are going to 
>>>>> be more difficult to change there. Which is not that much of a 
>>>>> problem for us now.
>>>>>
>>>>>
>>>>>> As I said, in our brief chat yesterday, I am about to revisit all 
>>>>>> the scenarios on Windows re. IE.
>>>>>
>>>>> There is the IIS server issue discussed above, and the IE Client 
>>>>> Certificate issue discussed by Bergi below. These are two 
>>>>> different issues I think. Both of them merit attention.
>>>>
>>>> I just need time to make updated demos and notes. This will come 
>>>> when we are done with iOS5 and Mac OS X variants of what we are 
>>>> doing with Facebook, Twitter, LinkedIn etc..
>>>
>>> Ok, What is the best  screen cast you have of your solution?
>>
>> I need to make a new collection of screencasts. The current ones are 
>> very very old.
>>
>> We are working on many things in parallel right now, once I have a 
>> moment I'll knock up a new batch of screencasts covering a variety of 
>> WebID exploitation scenarios across OS and browser combos.
>>
>> BTW -- re. Firefox, there is a .NET extension that Microsoft delivers 
>> that enables it work with the native OS keystore. Thus, you use 
>> <keygen/> with Firefox and the Cert. and its associated private key 
>> end up in the Windows keystore. Again, since this was delivered in a 
>> strange manner (i.e., these feature appears as an after effect of an 
>> upgrade for something unrelated), I also need to revisit this re. my 
>> next batch of demos, notes, and screencasts.
>>
>> Links:
>>
>> 1. http://technet.microsoft.com/en-us/library/bb727068.aspx -- how 
>> you import, export or request certs on Windows via its native keystore
>>
>>>
>>> Henry
>>>
>>>>
>>>> Kingsley
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> 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)
>>>>>>>
>>>>>>> So I think this is a good challenge for Windows Security 
>>>>>>> specialists. Perhaps we should have a challenges section of the 
>>>>>>> wiki.
>>>>>>> There would be this challenge, and the other one would be: how 
>>>>>>> to get Bergi's keygen script to not require users to go and set 
>>>>>>> registry values if their machine is set up for tight security.
>>>>>>
>>>>>> We seek a one-click solution triggered by a link for making Certs 
>>>>>> on Windows that terminates with Cert. storage in the native 
>>>>>> Windows keystore. Then we need to be able to test against any 
>>>>>> WebID verifier. This is what our Wizard has delivered since its 
>>>>>> inception more than a year ago.
>>>>>
>>>>> So good we then have two solutions. The solution of using the 
>>>>> built in ActiveX component that Bruno Harbulot told us about 2 
>>>>> years ago, and your client solution. We should compare them for 
>>>>> usability, and see where each one shines.
>>>>>
>>>>> It's good that we have 2 options.
>>>>>
>>>>> I think you did a screen cast. Perhaps bergi can do a screen cast 
>>>>> of creating a certificate on Windows 7.
>>>>>
>>>>> Henry
>>>>>
>>>>>>
>>>>>> Kingsley
>>>>>>>
>>>>>>>> ..
>>>>>>>>
>>>>>>>> Getting IE to perform https client authn and release a 
>>>>>>>> supporting client cert to some non-native WIndows webserver 
>>>>>>>> (e.g. tomcat running on a windows socket) is a matter about 
>>>>>>>> which others made claims. They can stand by them, or not.
>>>>>>>>
>>>>>>>> ---------
>>>>>>>>
>>>>>>>> I spent some time this week playing with sip URIs and TLS used 
>>>>>>>> in SRTP (and ZImmermans alternative secure transports). Also 
>>>>>>>> got to play with cisco phones that use CTLs and certs, binding 
>>>>>>>> them to particular call agents, and using particular validation 
>>>>>>>> protocols during call processing and multi-media channel setup. 
>>>>>>>> More later. It will be fun to see how the semantic web might 
>>>>>>>> cooperate with the world of SIP URIs, in running webid-style 
>>>>>>>> trust domains for the key management protocols that might 
>>>>>>>> complement those used today, supporting SRTP.
>>>>>>>>
>>>>>>>> anyway, back to research vs programming.
>>>>>>>>
>>>>>>>> > Date: Tue, 6 Dec 2011 22:49:17 +0100
>>>>>>>> > From:bergi@axolotlfarm.org <mailto:bergi@axolotlfarm.org>
>>>>>>>> > To:henry.story@bblfish.net <mailto:henry.story@bblfish.net>
>>>>>>>> > CC:public-xg-webid@w3.org <mailto:public-xg-webid@w3.org>
>>>>>>>> > Subject: Re: ExplorerKeygen - keygen element for IE
>>>>>>>> >
>>>>>>>> > Am 06.12.2011 10:42, schrieb Henry Story:
>>>>>>>> > > Great work Bergi!
>>>>>>>> > >
>>>>>>>> > > Were you able to create a certificate with this from 
>>>>>>>> Internet Explorer and then
>>>>>>>> > > log into fcns.eu <http://fcns.eu/>? Peter Williams declared 
>>>>>>>> this was impossible to do last week.
>>>>>>>> >
>>>>>>>> > Sure. I only tested my own endpoint, but that shouldn't matter.
>>>>>>>> >
>>>>>>>> > >
>>>>>>>> > > I think you should definitively copy and paste this e-mail 
>>>>>>>> into a wiki page
>>>>>>>> > > linked to from our new HOWTO page. This looks like the place 
>>>>>>>> to do ti from
>>>>>>>> > >
>>>>>>>> > > 
>>>>>>>> http://www.w3.org/2005/Incubator/webid/wiki/Creating_Certificates
>>>>>>>> >
>>>>>>>> > I added a Internet Explorer section.
>>>>>>>> >
>>>>>>>> > I would be nice if someone with a English version of Windows 
>>>>>>>> could add
>>>>>>>> > some screenshots, especially for the "The drawback of this 
>>>>>>>> solution"
>>>>>>>> > section to show people how to enable this component.
>>>>>>>> >
>>>>>>>> > >
>>>>>>>> > >
>>>>>>>> > >
>>>>>>>> > > On 6 Dec 2011, at 00:04, bergi wrote:
>>>>>>>> > >
>>>>>>>> > >> Internet Explorer doesn't support the keygen element out of 
>>>>>>>> the box. The
>>>>>>>> > >> only way to generate certificate request in the browser is the
>>>>>>>> > >> X509Enrollment ActiveX component. I've written some 
>>>>>>>> JavaScript code
>>>>>>>> > >> which brings nearly full keygen compatibility to IE. It's 
>>>>>>>> based on
>>>>>>>> > >> IEKeygen.js Bruno Harbulot wrote for Clerezza, but it's a 
>>>>>>>> little bit
>>>>>>>> > >> more generic.
>>>>>>>> > >
>>>>>>>> > > very nice.
>>>>>>>> > >
>>>>>>>> > >>
>>>>>>>> > >> What must be changed:
>>>>>>>> > >> It should require just a conditional include on the client 
>>>>>>>> side:
>>>>>>>> > >> <!--[if IE]>
>>>>>>>> > >> <script type="text/javascript" 
>>>>>>>> src="explorer-keygen.js"></script>
>>>>>>>> > >> <![endif]-->
>>>>>>>> > >> On the server side PKCS10 support must be added, which is 
>>>>>>>> in our case
>>>>>>>> > >> more or less just a different packaging of the public key. 
>>>>>>>> I'm using
>>>>>>>> > >> OpenSSL in my PHP code. If you look at the function
>>>>>>>> > >> buildCertificateSpkac and buildCertificatePkcs10 in
>>>>>>>> > >> OpenSslCertificateBuilder.php you will see it's nearly the 
>>>>>>>> same code.
>>>>>>>> > >>
>>>>>>>> > >> The drawback of this solution:
>>>>>>>> > >> Microsoft doesn't trust it's own ActivceX components. This 
>>>>>>>> means the
>>>>>>>> > >> page must be in the trusted zone or the user has to change
>>>>>>>> > >> initialization of untrusted ActiveX components settings 
>>>>>>>> from disabled to
>>>>>>>> > >> ask.
>>>>>>>> > >
>>>>>>>> > > I think this is the case for the Windows 7 only. I think I 
>>>>>>>> tried this a
>>>>>>>> > > year ago on some other windows and it did not ask me for all 
>>>>>>>> this.
>>>>>>>> > > It will be interesting to have people try this out 
>>>>>>>> themselves, and
>>>>>>>> > > send us feedback.
>>>>>>>> >
>>>>>>>> > I also added a note on the wiki page.
>>>>>>>> >
>>>>>>>> > >
>>>>>>>> > >>
>>>>>>>> > >> A little bit more in detail what the JavaScript code does:
>>>>>>>> > >> On page load it searches for a keygen element and adds a 
>>>>>>>> combobox for
>>>>>>>> > >> the key length selection after the keygen element to the 
>>>>>>>> DOM. The key
>>>>>>>> > >> length will be written to the keylength attribute in the 
>>>>>>>> keygen element.
>>>>>>>> > >
>>>>>>>> > > I suppose that is to imitate the way keygen works. I did not 
>>>>>>>> check but
>>>>>>>> > > does keygen really send the key length in the form to the 
>>>>>>>> server, or is
>>>>>>>> > > it not just used to create the public key?
>>>>>>>> >
>>>>>>>> > Yes, it's to imitate the keygen behavior of other browsers. 
>>>>>>>> The combobox
>>>>>>>> > itself doesn't even get a name attribute, which makes it 
>>>>>>>> invisible to
>>>>>>>> > the form and the .serialize() function of jQuery.
>>>>>>>> >
>>>>>>>> > >
>>>>>>>> > >> Also the action attribute in the form element gets renamed 
>>>>>>>> to ekaction
>>>>>>>> > >> to avoid submitting the form. The submit button is replaced 
>>>>>>>> with another
>>>>>>>> > >> button that calls some JavaScript code. If the newly 
>>>>>>>> created button is
>>>>>>>> > >> pressed, the JavaScript code will call the ActiveX 
>>>>>>>> component and create
>>>>>>>> > >> a new certificate signing request. For the CSR a new hidden 
>>>>>>>> input field
>>>>>>>> > >> will be created. The jQuery .serialize() function is used 
>>>>>>>> to get the
>>>>>>>> > >> form data in www-form-urlencoded format and Ajax is used to 
>>>>>>>> send the
>>>>>>>> > >> data to the server. Than the response is forwarded to the 
>>>>>>>> ActiveX
>>>>>>>> > >> component. And finally the certificate is installed in the 
>>>>>>>> Windows Keystore.
>>>>>>>> > >
>>>>>>>> > > very nice!
>>>>>>>> > >
>>>>>>>> > >
>>>>>>>> > >>
>>>>>>>> > >> The JavaScript code is MIT licensed, the PHP code GPL 3.
>>>>>>>> > >
>>>>>>>> > >
>>>>>>>> > >
>>>>>>>> > >>
>>>>>>>> > >> Link to the SVN repo:
>>>>>>>> > >> 
>>>>>>>> https://www.axolotlfarm.org/svn/bergi/bergnet/php/certbuilder/trunk/
>>>>>>>> > >>
>>>>>>>> > >
>>>>>>>> > > Social Web Architect
>>>>>>>> > > http://bblfish.net/
>>>>>>>> > >
>>>>>>>> > >
>>>>>>>> >
>>>>>>>
>>>>>>> Social Web Architect
>>>>>>> http://bblfish.net/
>>>>>>>
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>>
>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> Social Web Architect
>>>>> http://bblfish.net/
>>>>>
>>>>
>>>>
>>>> -- 
>>>>
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>
>>> Social Web Architect
>>> http://bblfish.net/
>>>
>>
>>
>> -- 
>>
>> 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
>>
>>
>>
>>
>
> Social Web Architect
> http://bblfish.net/
>


-- 

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