How to get a certificate signed by multiple certification authorities

Sort of. Here is a way to do it, but I don’t a practical use for this hack right now. But it is fun anyway 🙂

Here we go!

I was thinking about ways to distribute trust, and played a bit with CA generation and OpenSSL, when it occured to me: it depends more on a key pair than on a certificate! If I consider that I trust a key instead of a certificate, I begin to see a way (certificates are only restrictions on the trust between keys).

It is really easy to get multiple certification authorities to sign a certificate for the same key (even for the same subject name in some cases). You send the certificate signing request to two certificate authorities, and you get two certificates, for the same keys and same subject names. But the issuer, dates, serial and signature are different. That’s why a certificate has only one certification chain.

But what will happen if I delegates the certification to another key? Here is the idea:

  • create a first key pair
  • create a CSR for this key pair, and add the certification authority extension
  • ask the certification authorities to sign this CSR
  • you now have multiple certificates, for one key pair, all of them with the same subject name, and with certification authority powers
  • create a second key pair
  • create a CSR for this key pair, with a subject name for your email/domain name/organisation/whatever
  • sign this CSR with the first key pair, and any of the CA certificates you obtained before

You are now the proud owner of a valid certificate for your domain name, with multiple certification chains going up to each of the root CAs. Why? The issuer’s subject name and public key is the same for all of the generated CAs, and they’re included in the end certificate. Any generated CA certificate can be used to verify that signature, and all the certification paths will work. Cool, huh?

Okay, but…

  • Creating a sub CA is very expensive (if you want it to be recognized by all the browsers)
  • good luck with creating multiple sub CA and getting away with it
  • Assuming that certification authorities accept it, the sub CA private key could be thrown away after signing the certificate. But who will create and delete the subCA key? you, one of the CAs?
  • In the case of TLS, serving all the certification chains will have no impact: the browsers take the first matching sub CA in the list for the verification, they will not retry with another sub CA if they don’t find a root (but if you serve one certification chain at a time, it will work).

See, I said “no practical use” 🙂

Jtalk on Rails: editing Javascript in my browser

If you don’t know JTalk yet, you’re missing something. It’s an awesome piece of work: a Smalltalk to Javascript compiler and a Smalltalk editor running in Javascript, IN YOUR BROWSERGo check it out, now!

Now that you’ve played a bit with JTalk, let’s get started.

If you’re like me, you’re a bit annoyed by WebDAV, the proposed solution to save changes to disk. And if you’re like me, you would like to use Jtalk with Rails, and because you’re a lazy ass like me, you use WEBrick instead of Apache for your development.

Let’s hack something up to replace WebDAV!

Create a Rails application

rails new jtalkonrails
cd jtalkonrails
bundle install
rm public/index.html
rails generate controller home index
printf "Jtalkonrails::Application.routes.draw do\n  root :to => \"home#index\"\nend\n" > config/routes.rb

(I should really make a script out of all my rails initialization commands, one of these days…)

Add Jtalk to your application

cd public/
wget --no-check-certificate
tar zxvf master
cp -R NicolasPetton-jtalk-20cd63e/st .
cp -R NicolasPetton-jtalk-20cd63e/js .
cp -R NicolasPetton-jtalk-20cd63e/css .
cp -R NicolasPetton-jtalk-20cd63e/ide .
rm -rf NicolasPetton-jtalk-20cd63e

JTalk stores source code in three forms: Smalltalk code, Javascript code and smaller Javascript code (“*.deploy.js”).

Jtalk hello world: the Counter example

now, edit app/views/layouts/application.html.erb so that it looks like this:

<!DOCTYPE html>
  <title>Jtalk On Rails</title>
  <%= stylesheet_link_tag :all %>
  <%= javascript_include_tag :defaults %>
  <%= csrf_meta_tag %>
  <script src="js/jtalk.js" type="text/javascript"></script>
  <script type="text/javascript"> loadJtalk()</script>
<button onclick="smalltalk.Browser._open()">Class browser</button>

<div id="counters"></div>

<script type="text/javascript">
  jQuery(document).ready(function() {'#counters'._asJQuery()._append_(smalltalk.Counter._new())});
<%= yield %>


Here, we included a button to open the code browser, and added a Counter in a div. Oh, I forgot to tell you: Jtalk works seamlessly with JQuery 🙂
Now, go check it out, and you will seee the counter and be able to increase and decrease the value displayed (yes, that’s a counter).

Editing the code

Click on the “Class browser” button to start the IDE. Select the “Examples” category, the “Counter” class, the “actions” method category, and the “increase method”. You will see in the text box below the source code of the increase method:

count := count + 1.
header contents: [:html | html with: count asString]

Edit that method to increase by steps of 2 instead of 1, and hit “Save”. Now, the counter on your page will increase by steps of 2.
Unfortunately, on the next page refresh, you will lose these changes. That’s why the “Commit category” button is there.
It will take the updated files (here,, Examples.js and Examples.deploy.js) and make a PUT request to their original URL.

A PUT, you said? Well, I can work something out with a PUT.

Saving the code

Let’s create a new controller, called Uploader:

rails generate controller uploader jtalk

And edit config/routes.rb as follows:

Jtalkonrails::Application.routes.draw do
  root :to => "home#index"
  if Rails.env == 'development'
    put 'st/:id' => 'uploader#jtalk'
    put 'js/:id' => 'uploader#jtalk'
    put 'js/:id.:deploy' => 'uploader#jtalk'

Now the PUT requests are redirected to our controller, but only in the development environment. You do not want to make your JS editable from the browser in a production app. DO NOT WANT!

The only thing left is the controller itself:

class UploaderController < ApplicationController

  def jtalk
    path = Rails.root.join('public')
    if(params[:format] == "js")
      path = path.join("js")
    elsif(params[:format] == "st")
      path = path.join("st")

      path = path.join(params[:id]+".deploy."+params[:format])
      path = path.join(params[:id]+"."+params[:format])
    end, "w") do |f|

    head 200


Here, we build the file path from the parameters. I use to get the file content because Rails seems to truncate the beginning of the file.


Now, go back to the web page, click on “Commit category”, and refresh the page. Your changes were saved! You can enjoy editing your frontend directly from the webpage itself, in the code browser, and more importantly, write your whole frontend in Smalltalk! It’s still missing the workflow “edit-try-debug-edit-continue”, but it already feels just like a “normal” Smalltalk environment. It feels like home 🙂

Post Scriptum

If you want to add a new category, it’s easy: create a file Mycategory.js and put it in public/js, with this content:

smalltalk.addClass('Myclass', smalltalk.Object, [], 'Mycategory');

and change your initialization from loadJtalk() to loadJtalk(new Array(“Mycategory.js”)). The new category will now appear in the code browser, and clicking on “Commit category” will create the deployment file and Smalltalk source file.

Manage your libraries with symlinks on Windows

My Windows development environment is a bit complex. I work on multiple projects, at multiple versions, with different compiler environments, and with dependencies on different libraries and versions of these libraries.

Now, how do I specify where the compiler must search the libraries, and which version to use? Most of the time, I will add it directly in the project configuration. Easy at first, but quickly,I find myself writing by hand the path to each library (and header) in each project and each configuration of this project. And then, writing by hand the different names of the libraries (mylibrary.lib, mylibraryd.lib, mylibrary-static.lib, mylibrary-MTD.lib, etc).

And when I want to update to a new version of the library? If I’m lucky, I just have to change the library and header paths (in every project using the library). If not, I also have to change the name, because of the library developer’s convention.

The first solution to these problems was to use a batch file to launch Visual Studio and MSYS, and set some environment variables in this file. I quickly ended up with one big file containing two environment variables (include path and lib path) per library, possibly more if there were some big changes in the library names. My Visual Studio configuration was cluttered with $(MYLIBRARY_LIBPATH), $(MYLIBRARY_INCLUDEPATH), $(MYLIBRARY_NAME). It is unreadable, and again, impossible to maintain.

My solution comes from the Unix world, where you have a correct organization for your development files:

  • one folder containing the subfolders include, bin and lib
  • library names including version, and a symlink (without the version number) to the latest version of the lib

Can I do that on Windows? YES \o/

Here is the trick: normal links on Windows won’t work, but the mklink tool can create symlinks. And Visual Studio will recognize those as files and folders while looking for libraries.

Now, how would I organize my development environment? I chose to use (and abuse) symlinks, to create include, lib and bin folders for each project and configuration, and use generic names for the libraries.

  • I create a folder containing include, lib and bin
  • in the  include/ folder, I put symlinks to the header file or the subfolder for each library I will use in that project
  • in the lib directory, I create symlinks to the library version I want, one symlink per static/dynamic, MT/MD, Debug/Release version. But I could create one lib folder per static/dynamic, etc. A bit complex, but feasible (most of the time, I use only debug and release version, so it’s still manageable).

With this setup, I only set the INCLUDE and LIB environment variables, and I use directly the library names I need.

Here is an example script I use to create different library folders for x86 and x64 libs:

echo "Building include and library directories for Windows %PLATFORM%"

@mkdir %PLATFORM%
@mkdir %PLATFORM%\include
@mkdir %PLATFORM%\lib

@mklink /D %PLATFORM%\include\boost %BOOST%\boost
@for %%i in (%BOOST%\lib\*.lib) do (mklink %PLATFORM%\lib\%%~ni.lib %%~fi)

@mklink /D %PLATFORM%\include\cpptest %CPPTEST%\include\cpptest
@for %%i in (%CPPTEST%\lib\*.lib) do (mklink %PLATFORM%\lib\%%~ni.lib %%~fi)

I set up the BOOST and CPPTEST environment variables in another file. Then, I launch Visual Studio from another script which includes it.

There may be better ways, and that system will evolve in the future, but I’m pretty comfortable with it right now 🙂

Depending on my needs, I may grab from the bottom of my disk the package manager I wrote back in school, and make a big solution to download, build and link libs and personal projects. But later, I have some procrastination planned right now.

Yet another authentication scheme

Recently, I was asked to design a new authentication protocol for a web service. I know that I shouldn’t do reinvent the wheel, so I immediatly proposed OAUTH. It turns out that it can’t be used in this situation. Here are the constraints:

-calls to the webservice must be authenticated: I can keep the tokens and signature from OAUTH here. The problem is: how do I get that token?

-calls are made from devices or applications without access to a webbrowser (embedded devices, phones, etc.). The redirection dance of OAUTH is not acceptable here

-communications are done over an untrusted network, without SSL.

-I can’t use application keys and secrets to encrypt and sign the authentication process: clients include open source software and smartphone applications. You can’t hide a secret key in these.

-the protocol has to be simple to implement, on a lot of languages

-the server must not store the password in cleartext (I shouldn’t have to precise this…), the client must not store the password

Summing it up: no preshared keys, no browser, no SSL, untrusted networks, no passwords stored, and an OAUTH-like environment once the client is authenticated (tokens, authorizations, revoking, etc)

Apparently, I should just give up. But I like to play, so I’ll try!

First, I must say that I am not an expert in security nor cryptography. But I’m really enthusiastic about these subjects, and my day job is at a company providing strong authentication solutions (no, this protocol is not related to my day job). So, I know a bit about the subject, and I know that I should ask for reviews, hence this post.

Rough ideas

We need a safe communication over an untrusted network. TLS immediatly comes to mind, but the targeted applications might not have access to a TLS implementation. I’d like to use SRP, but I don’t think I’m able to implement it correctly (and it has to be SIMPLE). Using Diffie-Hellman to establish a shared key is another idea, but it is not safe against MITM.

Here’s my idea: we don’t need to generate a shared secret, we already have it. It’s the password!

But how can I use the password if the server doesn’t store it in cleartext?

The trick: key derivation functions

Decveoplers are finally understanding that they should not use MD5 nor SHA1 to store their passwords, even with a salt, because computing power is so cheap these days that anyone could crack easily a lot of passwords.

It is now recommended to use other functrions tro store passwords. The key derivation functions are a class of functions that create a key from a password. Basically, they do it by interating a lot of times. That makes them very slow, which is an interesting property if you want to stpre passwords: it is too expensive to “crack” the password. PBKDF2, bcrypt and scrypt are well known key derivation functions. They’re simple to use and available in a lot of languages.

With these functions, I can safely store the passwords, and generate a key shared with the client.

In short: if I store kdf(password, N) with N the number of iterations, I can send any M > N to the client and ask him to compute the key, without compromising what I store.

Designing the protocol

Now that we have a way to use a shared key, we can look at what will go over the wire to establish it. If I use directly kdf(pass, M), anybody getting access to the client storage will be able to obtain the key for any L > M. So, the key establishment has to use a nonce. That way, the client will only use the password once and forget it, and store the derivated key.

I would rather use a truly random key that has no relation with the password. It could be given to the client, encrypted with the derivated key. The derivated key could then be thrown away. But I still do not know if it is really necesary.

The server still needs to authenticate the client. The client will make a second call to the web service, signing it with HMAC and the key.

That’s it! It is really simple, so if there are flaws I did not see, you will surely catch them.


The protocol is based on key derivation functions, like PBKDF or bcrypt.

  • The server stores login and H = kdf(pass, N), with N integer
  • The client wants to authenticate and makes a call to the server with the login as argument
  • The server replies with M > N and i nonce
  • The client calculates k1 = kdf(kdf(pass, M)+i, 1)
  • The server calculates k2 = kdf(kdf(H, M-N)+i, 1)
  • The client calls the server with args “user=login&sign=”.HMAC(“user=login”, k2)
  • If k1=k2. The signature matches and the client is authenticated.

I hate installers

And I’m pretty sure a lot of people will agree with me. They’re an usability nightmare. They still look the same since Windows 95 (I think it’s even older than that, but thankfully, I’m too young to have known previous versions). The *click next* *click next* *click next* *click Finish* ugly grey thing is driving me crazy.

So, how can we improve user experience on installation? First, let’s recall the classic installation process.

The (ugly) state of the art

Someone tells you about this amazing new software that you just have to try. Or you just know you need it to get your work done. So, you google it a little (for the ones that are still stuck in the 20th century, you buy a pack of CDs in a shop), you quickly find the editor’s website. It’s a shiny website full of marketing tricks to persuade you that you want to download it. Or it’s Sourceforge. Whatever, you find a way to download it.

That was the easy part. You’re already bored and looking at pictures of kittens, because the download took a long time. But you really want to install the software, so you start the installer. And the nightmare begins.

  1. First, the UAC prompt (for those of us that use Vista/2008/7). It tells me that the installer needs admin rights, and that this piece of software has no verified publisher. Whatever, let’s just click ok.
  2. Before launching the real installer, the file I just downloaded uncompresses and starts another installer.
  3. First window, asking me which language I want to use. Click next.
  4. A window asking me to agree to a reaaaaaaaally long piece of US piece of shlegal text. Click next.
  5. A window asking me if I want a simple, advanced or custom installation. Click simple then next.
  6. A window asking me (it really asks a lot, can’t it figure it out without my help?) where I want to put my software.
  7. Now, if I’m lucky, the “next” button has been replaced by “install”. Or there’s yet another window to sum up my installation settings. Click install.
  8. Yay, it’s the revival of DOS for Windows users. I see a lot of file names scroll on the window, too fast for me to read their names (I don’t really care anyway).
  9. Is it done yet? No, now it asks me if I want to put the a shortcut in the quicklaunch bar, or on the desktop. Sometimes, it will even ask me if I want to launch this application on startup. Click next.
  10. If I’m really lucky, I go to the next step directly. If I’m not, it wants me to update my DirectX version, or to install the new wonderful browser bar that I really need (go back to step 3).
  11. \o/ the last screen. Asking me to choose yet another thing: do I want to read the README.txt file? Do I want to go to your website? Do I want to launch the program right away?
  12. Well, in fact, I didn’t go up to this step. I died of boredom long ago.

And this is what I have seen for the past 15 years (well, I didn’t include all the weird installation errors that I have seen). So much for innovating and improving the life of the users. The first interaction people have with software done by your company is the installer. For me, that means a lot. If they’re too lazy to get this right, I’m probably to lazy to try their software.

Now, let’s go back to the interesting question: how can we improve the user experience of installers?

The (easy) critics

I would like to say “install a Linux, use a package manager and let’s roll” (yes, I KNOW you thought of it), but since the CoApp project isn’t ready yet, we will have to find another way to please Windows users.

Let’s go point by point:

  1. About the UAC, I can’t force you to buy a code signing certificate. But if you can afford it (between $90 and $300 a year), it can make your software look a lot more professionnal. And you can use your WinQual account, which is really nice.
  2. Why would you uncompress a lot of files right now? Is your installer a Java ERP? No? Then, only uncompress the files when I ask you to install them.
  3. For this one, I have mixed feelings. The default setting shouldn’t be English, but the detected language of the OS (come on, it’s not that hard to do). One thing you have to get right: if you ask for a language, it’s not only the language used in the installer, but it will be the language used in the installed software. I shouldn’t have to choose the language two times.
  4. For the EULA, I don’t really know what I can do, as I am not a lawyer. But I’m not really sure that a legal agreement written in english and referring to US law complies to my country’s laws.
  5. This one is obvious. How many of your users will need the advanced settings? yes, the whining 0,1%. The other 99,9% will just use simple anyway, so why would you ask them to choose? And what options could be so important that you need to treat them as advanced?
  6. OK, this one is easy. Most people will not even choose another installation folder. One thing that I would really love (but there, it’s a matter of taste): don’t use a path like c:\Program Files\MyCompany\MySoftware, but c:\Program Files\MySoftware. People install a software, not an advertisement for your company. And not finding your installation folder later because you’ve hidden it deep under a meaningless folder name is definitely not nice.
  7. Oh, my installation settings. Think about it. If I’m a dumb user just wanting to install quickly, I don’t care about these. And if I care about my installation settings, I know exactly what I chose. So this one is useless.
  8. OK, the scrolling list of files. I know it’s useful if you’re debugging your installer. It’s useless for me. Just put a pretty progress bar. If you really want to display things, instead of writing “uncompressing pouet1.png, copying pouet1.png, uncompressing pouet2.png, copying pouet2.png”, write “installing shiny new themes”.
  9. I have mixed feelings about this one. I would say: let the user choose for the desktop shortcut, don’t ask for a quicklaunch icon (the user will know how to drag and drop the desktop shortcut on the bar), and definitely don’t ask to launch at startup. Be a responsible developer, don’t waste CPU cycles, and save the planet.
  10. For DirectX, do whatever you want. I would prefer that you warn me about the update before I get to step 8. For the adware bar, just stop it. If you want to make money with your software, just sell it. But if you really don’t care about user experience, go ahead and install spyware on your user’s computers. I’m sure they will love that.
  11. Do you really think people will read some quickly written presentation of your software in Notepad? No. Do I want to go to your website? Seriously, that’s where I downloaded the installer. While I’m at it, I’m trying to find some documentation on your website, but there’s nothing useful there. Do I want to launch your application? This one makes me laugh. What will happen if I click yes? In 90% of the installers, it will launch the application. With Administrator’s rights. Seriously, isn’t that obvious? So, two possible fixes: learn to drop the rights of a Windows app, or don’t even launch the application at install time.

The (really easy) fix

Well, that doesn’t look so hard to do, right?  I’ll sum up my ideal installer’s behaviour:

  1. Sign your installer with a code signing certificate recognized by Windows (you can leave that part if you have no money).
  2. Start immediatly with a good looking screen, showing the logo or a good picture of your software, and in small in a corner, the logo of your company. And a well written presentation of your application. If the installer will install other applications, warn the user there. You should have detected the language of the user befor launching. Provide a droplist to change the language on this screen, but put it out of the way (like, in the bottom left of the window).
  3. Next, the EULA. If you find a way to get rid of it (maybe put the agreement on the website, wher it’s easier to read), or to simplify it, do it.
  4. Put all the installation options on the next screen. Only show the ones the user really needs to look at. Add an “advanced settings” button, and again, put it out of the way. You have the permission to use a good looking effect to switch from simple to advanced view and vice versa. By installation options, I mean the install folder, the desktop shortcut, the eventual plugins, etc. Don’t forget to show the disk space needed for installation. The next button should now be an install button.
  5. Use a good looking progress bar, and meaningful log messages. Maybe provide an error logfile somewhere if something went wrong. You can show some good marketing messages and pictures there. I don’t guarantee that people will look at them, but if they’re waiting, try to prevent the boredom from showing up.
  6. The last screen, yes! If you really don’t want to listen to my advice, at least remember to drop the admin rights before launching the application. Instead of asking if the user wants to see the README, provide links to the documentation (on the disk, or on your website), tutorials, screencasts.

And now, that’s an installer I would like to see: 5 screens, 5 clicks in the best case, no useless clicks in the worst case. Quick and easy. Don’t hesitate to add some eye candy. Anything can look better than those grey installers we’re used to.

Oh, and a last thing, which will content a totally different sort of users: please, please, provide a silent installation, with all the options accessible from command line. the system administrators will love you.