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

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