RE: ExplorerKeygen - keygen element for IE

If someone wants to take java server applciation loaded with the jsse library and run it on windows... this is easy to do. It does not make a NATIVE implementation though. similarly, downloading openssl compiled for win32 and running s_client and s_server does not count a "native". Thats all non-native, non-Microsoft systems code. what those of us in the windows world want to do is bog-standard IIS and SSL (rather than run a jsse-app, or an openssl-app, or any OTHER NON_NATIVE ssl). You know, you install the server roles of the Win32 ; go to its web server configuration tools; turn on the SSL mode of the website given minting of a server cert; set the little flag that induces SSL client certs to be requested and required; and then load a script when serving an HTTP resource, that processes any client cert presented . At that point, the script runs a query that parses 2 strings from a data stream in some format, and these are compared for equivalence against similar strings from the client cert, using the SPARQL ASK method. The trials I made against the webidauth site last week were all IE with client certs minted from a bog standard windows CA. Presumably, IE was talking to some php script stting on some listener hosted on some linux platform. If the php script was running in a php interpreter executed on the win32 or posix or unix subsystem of the Windows platform, that this is great. But, that would not really count as "native" - which is the cue and the test. By native, I meant IIS and normal windows SSL used in a million sites. Ive been assuming folks were not super-parsing my words, or being actively malicious in argument. Yes, running php in the posix or unix subsystem of the windows microkernel could be deemed "native". But, is it using the kernel's https driver? This is what I want. If one can show that php running under posix or unix can satisfy my rule, ill KEEP LOOKING for the same feature in the win32 subsystem under which IIS runs. I assume we WANT a million classical Microsoft  IIS websites (running on the win32 subsystem) to be doing ALL of webid (and not merely the 99% of the webid use cases ...that Ive managed to do, so far). Nothing to do with the title (keygen); but then neither were any of my claims about IIS. My issue with IIS is present even if mozilla is the browser, and Henrys CA is the party that provisions keys and certs (and webid profiles) to mozilla. Until I PRE-REGISTER that cert or it issuer's root with the windows system hosting IIS, I dont know how to make IIS/Windows/kernel complete the SSL handshake (and deliver the client cert to my script running on IIS). And that act or PRE-REGISTRATION means windows/IIS fails to COMPLETELy implemennt webid - which precludes the requirement for "pre-registration" of such (PKI-ish) roots and/or user certs etc.  From: home_pw@msn.com
To: bergi@axolotlfarm.org; henry.story@bblfish.net
CC: public-xg-webid@w3.org
Date: Tue, 6 Dec 2011 16:36:37 -0800
Subject: RE: ExplorerKeygen - keygen element for IE








 
 
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?  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)..
 
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
> To: henry.story@bblfish.net
> CC: 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? 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/
> > 
> > 
>