Transaction PKI - To API or not to API, that is the question

["Anders Rundgren" <anders.rundgren@telia.com>]

Evaluation continued.

 

It may be of interest to know that none of the more widely used signature systems currently on the market (PureEdge, InfoMosaic, Adobe, the Swedish BankID, the Danish OpenSign, and the Austrian SecurityLayer) to my knowledge use an API approach, but rather use a container scheme.  Containers either come in the form of Java applets, and for the most sophisticated systems (including WASP), as MIME-invoked objects.

 

The reasons are many, but the most important one is probably that without a GUI application frame to put controls and similar stuff on, you rather soon run into severe security and layout difficulties.

 

A container scheme is also easier to support, document, security validate, and test than an arbitrary complex API.

 

---

In addition, only a container scheme can support a uniform "signature environment" (=cannot be arbitrarily defined by a provider), something which I consider a reasonable requirement for a process which may even be considered as legally binding.

---

 

I assume that the reason for Transaction PKI to use an API approach was due to the hope that you could call crypto functions from a web page without modifying the browser or adding extensions.  Since this has been found to be incorrect, I believe the API or container issue should be considered an open question.  In my opinion the answer is already given by looking at other implementations.

 

Anders Rundgren

Principal Engineer

RSA Security