Proposal for a Desktop Neutral Crypto API

[Albrecht Dreß]

Am 02.04.05 10:54 schrieb(en) Brad Hards:
> >  - Continuity in the user experience.
> I can't really comment until we see how many apps implement it. Also,
> because
> the focus is so narrow, I'm not sure that can work anyway.

Given the list in the original message, I must admit that I don't think it  
will be *too* useful for some of them...

- kmail: Ägypten works perfectly, with the whole set of S/MIME and OpenPGP  
extensions, including smartcards etc... Why should they ever want to  
switch?
- Thunderbird/Seamonkey: remember that the majority of users still use  
them with MacOS X or [spit] Winbloze. Using two different "backends" seems  
not to be a good idea, though, and I don't see the point why enigmail  
should talk directly to gpg on the Mac/Win, but use dbus on Linux, which  
would, btw, add an other dependency.

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.

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.

> >  - Security.
> See below.

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.

> > > * are you trying to replace existing key agenst (eg for ssh or GPG)?
> >
> > That's up to the implementation. Seahorse for example has
> > 'seahorse-agent' which is a GNOME integrated GPG agent. But that has
> > nothing to do with this API per se.

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.

> > Perhaps I'm missing something on the security though. Was there a
> > specific security flaw or short coming you've thought of?
> You have to pass the plaintext information across it. Sure, the keys are
> hidden away, but that isn't the whole problem.

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!

Cheers, Albrecht.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Albrecht Dreß  -  Johanna-Kirchner-Straße 13  -  D-53123 Bonn (Germany)
        Phone (+49) 228 6199571  -  mailto:albrecht.dress at arcor.de
    GnuPG public key:  http://home.arcor.de/dralbrecht.dress/pubkey.asc
_________________________________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050402/4ca9baee/attachment.pgp