Proposal for a Desktop Neutral Crypto API
albrecht.dress at arcor.de
Sat Apr 2 20:21:04 EEST 2005
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,
> 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
- 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
- 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!
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
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050402/4ca9baee/attachment.pgp
More information about the xdg