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

Re: ExplorerKeygen - keygen element for IE

From: bergi <bergi@axolotlfarm.org>
Date: Tue, 06 Dec 2011 22:49:17 +0100
Message-ID: <4EDE8DDD.20208@axolotlfarm.org>
To: Henry Story <henry.story@bblfish.net>
CC: WebID XG <public-xg-webid@w3.org>
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? 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/
Received on Tuesday, 6 December 2011 21:50:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:50 UTC