Keys not trusted

[Ingo Klöcker]

--Boundary-02=_8gkv+/+Z+ZaGTIQ
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

On Friday 09 May 2003 00:29, Yenot wrote:
> On Tuesday 06 May 2003 04:03 am, Wolfgang Bornath wrote:
> > Being fairly new in this I joined this list and received some
> > messages by people who signed their messages. I always imported the
> > keys (using the gpg option --auto-key-retrieve) and kmail tells me
> > "Message is signed by XY (blahblub) (Key-ID: 0x12345678).
> > Signature is valid but the key is not trusted."
> >
> > When I want to send a private mail to somebody like that and I want
> > to encrypt the text I see the list of my pubring but all imported
> > keys are marked red and I cannot encrypt.
>
> You're certainly not the only person with this problem. I know at
> least some of the Kmail developers read this list, so may be it would
> be useful to start a discussion on the matter. I think Kmail, and
> mail agents in general, need some way of sending e-mail to unknown
> parties.  Just because I don't know someone's real identity, doesn't
> mean that I don't want to send them mail.

You don't have to know them personally. You just have to know someone=20
who verified their identity (and then signed their key). And if you=20
want to send a message to someone who regularly signs the messages he=20
sends to a mailing-list (so that you can be more or less sure that you=20
would use the right key for encryption) then you can simply locally=20
sign this key (with "I have not checked at all." of course). The=20
problem currently is that gpg doesn't report the strength of a=20
signature. (Or does it?) It just tells you that a signature is good or=20
bad. But a good signature from a locally signed "I have not checked at=20
all." key is definitely not very valuable. It would be good if gpg=20
would evaluate the strength of a signature so that mail clients could=20
show it.

IMO making the usage of unverified keys too easy (i.e. the user just has=20
to click away a warning) will result in a weakening and a slower growth=20
of the web of trust.
Why weakening? Because people who routinely use unverified keys will=20
sooner or later sign unverified keys.
Why slower growth? Because exchanging fingerprints and signing keys=20
isn't necessary. So why bother?

> One way to pick the best key for such e-mail only acquaintances would
> be for people within various communities to all use a single robot
> authentication authority (for example:
> http://www.toehold.com/robotca).  Some members of this list, such as
> GnuPG developer David Shaw, consider this to be a bad idea.

The RobotCA simply verifies the email address. You can easily do this=20
yourself by sending an encrypted challenge to the person you want to=20
communicate with. (Yes, I know that an encrypted challenge will only=20
verify the encryption key.)

> Shaw=20
> proposes that when no trust path to an e-mail exists, the mail client
> should encrypt to all available keys for the given e-mail address
> (warning the user appropriately). Then when/if the party you sent to
> replies, you can set the definitive key based on the key they use in
> their reply.

This isn't really a good idea. You encrypt with a valid and with a=20
forged key. The message is intercepted, decrypted and answered by the=20
forger. You have been fooled.

The right way to do this is to ask the user which key should be used if=20
several keys contain the email address. The user could for example know=20
the right key from all the signatures that were made with this key on=20
mailing-list messages. If the user doesn't know the right key then=20
encryption is pointless. Prominent example: AFAIK there's a forged key=20
for Phil Zimmermann. You should definitely go to his website to get the=20
correct key instead of downloading all keys with his name and=20
encrypting to all of them.

> (For this to be accessible to non-crypto zealots, the=20
> mail agent would also need some way of locally signing a key based on
> the signature of a received mail.)

Key-Management shouldn't be done by a mail client. There are=20
applications which are much better for this, e.g. gpa and kgpg.

> I can think of a couple other ideas that would involve caching
> previously seen address/fingerprint pairs.  Maybe with an SSH like
> feature that warns when an address/fingerprint doesn't match the
> address/fingerprint previously seen.  (All my ideas have minor
> problems, so I'll wait and see what other people have to say first.)

Well, if you don't automatically retrieve missing keys then you will=20
notice if a message was signed with an unknown key because then the=20
signature can't be verfied.

> Do the developers of Kmail, Sylpheed, and/or Enigmail have a vision
> of how the mail agent of the future can increase the use of PGP for
> casual Internet communications without making major compromises on
> the security of more serious communications with known entities?

IMO KMail is already almost there. The only thing which is missing is an=20
easy way to download missing keys. And in KDE 3.2 there will be KGpg=20
which allows easy key management. If you think KMail is missing a=20
useful feature then please file a wish at bugs.kde.org.

Regards,
Ingo


--Boundary-02=_8gkv+/+Z+ZaGTIQ
Content-Type: application/pgp-signature
Content-Description: signature

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

iD8DBQA+vkg8GnR+RTDgudgRAkFrAJ9Ijh8gOROKLwHSq1IwHhPXCFNf2gCeIL5i
oeHryUvFsjqw1uOL/UV1sZU=
=MUFX
-----END PGP SIGNATURE-----

--Boundary-02=_8gkv+/+Z+ZaGTIQ--