Thursday, September 4. 2014
Some weeks ago I decided to check the new implementation of the Web Cryptography API that was just enabled in chrome 37 beta. If you remember I talked about this standard some months ago in a quick entry and I wanted to continue in a more technical post. As soon as I started I felt that the API is quite bad documented and I did not find any example for what I wanted to check. I was trying to implement a similar solution to the one I presented in the applet series (that series implemented a signed email solution using an applet). I checked and re-checked the API and I did not find a clear method to use a certificate key (a key of one of my certificates previously imported in the browser). At first sight only two ways were admissible:
Using the importKey with some strange format or arguments.
Using another standard (apart from webcrypto-api but related) called WebCrypto Key Discovery which has a getKeyByName method.
Those options were only ideas and it was impossible to find any example or comment about what I was trying to do. All the examples over the Internet use a previous generated key (some of them export the key and re-import it to be re-used without creating another one) but no one tries to use the key of an imported certificate and, even less, a certificate / key pair hidden inside a PKCS#11 library in a crypto-device like in the last post of the Java applet series.
A bit tired after some hours trying to find answers I decided to post a question to the chromium lists and, surprisingly, PhistucK answered me saying that this use-case was not taken into account and that the WebCrypto Key Discovery API was not implemented in chromium. It was surprising, I had just not thought about that possibility, how can a webcrypto-api not consider user certificates? I suppose that I fell into that mistake because all the times I faced cryptography in a web environment the task was related with user certificates (document signing, voting events, email signing or encryption,...). I simply did not consider any other situation.
The same morning I discovered a youtube video uploaded by Inventive Designers which clarified the situation to me. Using user certificate keys is out of any specification, neither webcrypto api nor webcrypto key discovery cover that situation. I exchanged some emails with people of the company and they explained that W3C is moving forward with the webcrypto-api and there is a workshop to define next steps and goals. They have submitted a proposal for document signing and they will attend to the workshop trying to incorporate it as a new feature inside any standard. So they are pushing but, in their own words: "There is interest of other people in the WG (working group), but browser vendors are still not keen to add this feature. Depending on the outcome of the workshop this may change...". At the moment I have seen that Inventive Designers have implemented a chrome plug-in to present a proof of concept of their idea. (At first glance the plug-in only works on Mac and seems to retrieve certificates from internal system certificate store. I suppose that Mac is similar to Windows and it stores user certificates at system level. Besides I think that this implementation needs direct access to the internal private key.)
I do not know, I feel a bit depressed. I thought that the WebCryto API was the final solution for cryptography in the browser but it resulted in a big disappointment. The API covers none of the use-cases in which I have been involved in my professional life. I suppose that it has some value in other areas but it is absolutely useless in document signing. At least there are some people trying to complete the work and integrate this important feature in the standard.
Let's see what happens in the workshop!
So, have you been at that workshop? What did you find out?
You can check by yourself the decisions.
It seems that the web cryto api is not thought for digital signing. I extended this entry a bit later with another one which explains a bit more what are the limitations right now with this api:
Thanks for reading!