Proposal for a Desktop Neutral Crypto API

[Mike Hearn]

On Fri, 01 Apr 2005 22:58:21 +0000, Nate Nielsen wrote:
> - Caching of security sensitive information
> - A continuity in the encyption experience 

These seem like good reasons for a separate process.

> - To allow the various implementors to use different toolkits and
>    libraries and to avoid implementation details and requirements
>    leaking. This allows each desktop to implement the API according to
>    their own coding style. An important factor if this is to gain
>    traction in the myriad of applications that require encryption
>    services.

This does _not_ seem like a good reason. The libdbus API itself has a
coding style, as all APIs do. Defining an API in terms of DBUS messages
does not make it magically acceptable to everybody, or shouldn't do. It is
just yet another way to write an API.

I am also a bit concerned by the idea that each desktop (KDE, GNOME, ROX,
XFCE etc) should implement this themselves. Why is that better than one
canonical implementation?

> - It's clean and simple. Doesn't bring dependencies into the calling
>    program. 

But it does: it requires, at minimum, libdbus and security privileges to
connect to the bus. That means things like SELinux are affected. It also
really requires either threads or a libdbus-compatible main loop, unless
you don't mind blocking for potentially long periods of time.

>              Allows swapping of implementations when the user / admin /
>    distro requires. 

But a shared library with a well defined interfaces allows this too.

>                     It's much more flexible and allows new features to
>    be developed independently of the API.

How is this true of an IPC interfaces but not of a DSO interface?

> - Allows the simple integration of encryption hardware, like biometrics
>    or card readers.

Why is this easier with a separate process/server than a library?
 
> Given that many applications and desktops already each have their own
> encryption solution going, an effort like this needs to be as
> transparent and simple as possible implementation-wise in order to go
> anywhere.

OK, well you seem to have at least thought it through pretty carefully.
Maybe you should just code it up with an implementation or two and propose
it for inclusion to GNOME and KDE directly: there seems little reason to
try and produce a standard first before anybody has real world experience
with the design.

thanks -mike