Proposal for a Desktop Neutral Crypto API

[Nate Nielsen]

Lars Hallberg wrote:
> I asume the sockets for XEmbed are optional? If not given, the
> implementation open it's own window? Think the standard shuld state that
> explicidly. As I understand, the calling program need not nesecarly even
> be an X-app?

Well, the whole point here is the interface implementation. A consistent
user experience. As others have pointed out we already have *many*
different lower level encryption libraries, backends, agents, key and
certificate caching solutions etc... These do a great job in their
respective areas.

What we don't have is a consintent UI and user experience. This is what
this API proposes to address.

The implementor of this API will obviously use the underlying libraries
and code already available. This API simply provides the point where
high level consumers of public key encryption can, using this proposed
API, hook into whatever implementation is available on the system.

Hence a DBUS service.

> I would like an implementation that have an alternative interface to
> provide user interaction thru an console. But the standard should
> probably not mandate it. But i like if the standard provided a way for
> apps runing on an tty to *sugest* to the server to use the tty for user
> interaction.

Yes, that's a good point. For high security user interaction, gpg-agent
and others already have this functionality. The implementor of this API
would call out to GPG and on a properly implemented system, gpg would
prompt via gpg-agent and if desired this could occur on a different
terminal. In any case, this doesn't have much to do with the proposed API.

> I like the server aproch, it open for a posability to store the keys
> nonreadable and alterable by the user. Making things a bit harder for
> malicius code to do a set of evil things.

Agreed, although as others have pointed out, almost anything can be
spoofed given a compromised system. But yes, the seperate process does
allow us to do some security conscious things that would be difficult
given a library.

> But that would mean all public crypto needing app You use *have* to
> use this api, but it is still a futur option to hope for :-)

In any case, seahorse is going to start working in this direction on
it's own for now. We'll see how it goes and then see if the some of the
various email clients are interested in adoption.

Hopefully the API idea will either prove or disprove itself, given time
and the collaboration of everyone involved.

Cheers,
Nate