[even more OT] CLI for noobies: The keys to GnuPG

[Albrecht Dreß]

--cWoXeonUoKmBZSoM
Content-Type: text/plain; Format=Flowed; DelSp=Yes; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Am 01.07.04 15:57 schrieb(en) Clinton MacDonald:
> Albrecht:
>=20
> (I feel a rant coming on -- feel free to move on to the next message if =
=20
> you feel this is off topic.)

Of course not, Clint - I read *everything* you post to this list!
=20
> Albrecht Dre=C3 wrote:
> You are right, of course! I was oversimplifying in my earlier e-mail. We
[snipped discussion about encryption]
> "paper trails."

Exactly what I wanted to say. Only my english is much worse than yours, so =
=20
I left it to you ;-))

> I remember setting up GPG for Apple's Mail.app on my Mac OS X box, once.
[snipped description of weird Apple Mail crypto install]
> rather long passphrase. I turned it off.

Ouch. This kind of software is of course a show stopper. Unfortunately, =20
some programmers don't know what "user-friendly" means (apart from the =20
comic strip, of course)... With Linux (Open Source in general) IMHO the =20
situation is somewhat better (see below).

> [1] one standard encryption scheme must be agreed to by the appropriate =
=20
> governing bodies (such as has happened with secure Web transactions)

There are currently three IETF standards around (it's your choice if you =
=20
want to call them "standards" as they are three and not one, though):

* RFC 2440 or OpenPGP uses (surprise) PGP or GnuPG keys to sign and/or =20
encrypt single-part mails or single parts of multipart messages. It is =20
supported by, inter alia, kmail, balsa (natively), pine or outlook (using =
=20
special plugins). This RFC is rather old and has some shortcomings, so its =
=20
better to use

* RFC 3156 (sometimes called PGP/MIME) which puts the signed and/or =20
encrypted stuff (which may be a complete message with a complicated =20
structure) into a special "container", again using PGP/GnuPG keys. This =20
scheme is really very robust and should be the method of choice, also as =
=20
it is supported by most Linux MUA's (Mozilla, Balsa, Evolution, kmail and =
=20
sylpheed come to my mind).

* RFC 2633 (S/MIME) uses similar MIME structures as '3156, but with keys =
=20
which are comparable to SSL certificates.

> [2] a third party must be entrusted with keys for escrow (apparently, =20
> this is a major stumbling block for businesses)

Yes, but this applies only to S/MIME, where the key is signed (like ssl =20
certificates are) by a "Certificate Authority" (CA), and you must trust =20
the root certificate of the signer. Therefore, this is a method commonly =
=20
used by governments (e.g. the German government sponsored the integration =
=20
of S/MIME into kmail, as some ministries are switching to OpenSource) or =
=20
big companies which may even be their own CA.

PGP/GnuPG uses the distributed "Web of trust" instead. In short, assume =20
you don't trust my key (why should you?), but you have a friend whom you =
=20
trust (=3D=3D his key) fully. Now your friend trusts my key, so he signed i=
t =20
whith his one. At this point you may build a "chain" to trust my key at =20
least marginally.

> [3] all the "major" e-mail clients (for some definition of "major") must =
=20
> adopt the standard more or less at the same time

It works perfectly with '3156 - sending from Mozilla on [spit] Win2k at =20
work to Balsa/Linux at home, for example. Ans meanwhile all "major" OSS =20
MUA's support encryption (see list above).

> [4] the implementation would have to be as seamless as that in every Web =
=20
> browser, where we need not even know we are interacting with a secure =20
> site unless we look at the little padlock icon -- no command line!

In Balsa, for example, you have two buttons "Sign" and "Encrypt" in the =20
composer, which you may even preset depending upon your e-mail identity. =
=20
If you want, you have to enter the passphrase only once per session, as =20
either Balsa's built-in cache remembers your passphrases, or you install =
=20
pinentry (from the unstable GnuPG branch) to get a system-wide cache. Upon =
=20
receiving signed and/or encrypted mails, they are automagically signature =
=20
checked and/or decrypted. It's really as simple as just clicking sign/=20
encrypt on or off, and two passphrase (one for signing, and one for =20
decryption) once per day!! Oh, and if you received a signed mail, but you =
=20
don't have the key, there's a button to get it from a key server. Believe =
=20
me, you will *never* even see the command line!

An for the nasty key management (e.g. if you want to tune the trust of a =
=20
key), there are gpa or seahorse - again, no command line.

<rpm>
I hope some of the YDL packagers will read this - it would be great if =20
they had the necessary packages (GnuPG, gpgme and gpa, plus Balsa/Evo/...) =
=20
in 4.0!
</rpm>

> Unfortunately, by "major" e-mail client ([3]), we are probably talking
[snipped discussion about TTP]
> their Hailstorm initiative for this very reason).

This is a really good and important point. And it's the reason why Open =20
Source people usually have more trust into PGP/GnuPG as in S/MIME. See #2 =
=20
above - that's how it works, and you will *never* need a third party!

> The Mozilla folks might be able to do this, either in Mozilla or in
[snipped Mozilla discussion]
> customers have requested encryption to make a business case for this. =20
> Sigh.

Enigmail is a fine RFC3156 plugin for Mozilla - works perfectly with =20
Linux, MacOS X and Microsnot... Note that you still have to get and =20
install GnuPG separately, though.

> an additional step to sending every e-mail. Sigh.

Well, that depends - see #4 above!

> Thanks for listening to my rant, folks!

=2E..which is always interesting and welcome!

Cheers, Albrecht.


--=20
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Albrecht Dre=DF  -  Johanna-Kirchner-Stra=DFe 13  -  D-53123 Bonn (Germany)
       Phone (+49) 228 6199571  -  mailto:albrecht.dress@arcor.de
_________________________________________________________________________

--cWoXeonUoKmBZSoM
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA5FlMn/9unNAn/9ERAkklAKDCUTJ4H5LKU/lSQfYGnhFtBW27MgCcCBpQ
MSdVLobDyk33LAyZl5pj3jk=
=hqsb
-----END PGP SIGNATURE-----

--cWoXeonUoKmBZSoM--