Proposal for a Desktop Neutral Crypto API

[Nate Nielsen]

Albrecht Dreß wrote:
> Form my experience implementing GPG and S/MIME support for the Gnome
> mua  Balsa (http://balsa.gnome.org) over the past two years or so, I
> must say  that I'm perfectly happy with the newer (read: since ver.
> ~0.4.3) gpgme  releases. The *real* work here has been to implement all
> the RFC 2440/  2633/3156 specific restrictions and the specific needs of
> storage backends  (e.g. imap and partial loading). I don't think it will
> be possible to move  all this into an external application. Feeding the
> proper mime streams  into gpgme and reading back the result has actually
> been the smallest part.

For sure. This API is not meant to replace or obsolete such code which
is the lions share of email handling. As noted in the proposal this does
not handle encoding, and over the wire communication of the encrypted data.

> Something which is *not* covered there, but would be an extremely
> useful  extension, is an interface for key handling. This could in
> particular  include
> - trigger key retreival from a key server
> - treatment of received keys/certificates
> - maybe certificate and CRL management
> I would strongly support any efforts here.

These are some of the ideas that seahorse is looking to implement. The
main idea is to make public key encryption simple easy and jargon free,
without a whole lot of assumed knowledge.

Here's a few of the things we're either working on or some ideas. Note
that not all of these are new ideas.

- We're adding certificate (ie: S/MIME) functionality, along with
everything that entails.

- (Mostly) Transparent use of keys from key servers. In the 'select
recipients' dialog, offer with a single click to retrieve other matches
for the given recipient.

- Rendezvous / OpenTalk / DNS-SD sharing of keyrings. Allow people
'near' each other (ie: think rendezvous, like iChat or iTunes) to see
each others keys and import them to the local keyring if so desired
requested. In addition to being in the key manager this could also be
integrated into the 'select recipients' dialog.

- Simple way for email clients to import keys, and they immediately
become available everywhere.

- Simple way for email clients to 'send my key/certificate' along with
an email.

- Simple rules. User selects a certain set of keys for a given recipient
(ie: a mailing list, or a key that has the wrong email) and in the
future that selection is remembered.

[NOTE: Let's not get into a big discussion of these features here on
xdg. If you want to comment on the viability or stupidity of one or more
of the above, then seahorse-devel at lists.sourceforge.net is a more
appropriate place.]

In order to implement these and other features there will need to be
some sort of an API that email clients in particular would use. In any
case seahorse will probably expose an API or library of some sort,
whether it's a freedesktop.org API, or a GNOME specific API, which will
allow this forward progress to take place.

Whether or not these ideas gain traction remains to be seen. The DBUS
proposed API was just that: a proposal, request for comments, and
preview of what we're looking into.

> IMHO the main restriction is that passphrases must NEVER be held in 
> pageable memory by any process involved. However, gpg-agent and
> pinentry  do a perfect job here if they (and gpg/gpgsm) are installed
> suid root. It  is even possible to run pinentry from a virtual terminal
> to enter the  passphrase to be sure that X is not involved.

This is an implementation detail (although important) and has nothing to
do with the proposed API.

> I don't think agents should be treated on this level at all. The
> current  solution gpg(sm) <-> gpg-agent <-> pinentry works perfectly, is
> well  tested and guarantees the maximum security possible. Is there
> *any* reason  to invent something new (apart from the fact that it's
> installation is not  trivial)? Passing passphrases through a series of
> other apps and  processes, maybe even using insecure (pageable) memory,
> doesn't seem to be  an approriate approach to me.

Again an implementation point, and one that has been addressed in all
current public key crypto implementations. But this does not affect any
such API, although it does make the 'shared library approach' more
complicated.

> In general, keep things as simple as possible here... Every additional 
> layer makes auditing the whole system more complex and might add
> possible  vulnerabilities. I even don't like entering passphrases in an
> X app in our  corporate network, as the keystrokes are passed through so
> many layers (I  use the ncurses pinentry on a vt instead). I agree,
> though, that this will  be only a minor threat on your home box.
> 
> Just my € 0.01, though!

Thanks, the security concerns are definitely valid in this field. For
what it's worth, it would be interesting to have someone like you audit
new seahorse features for security flaws.

Cheers,
Nate