Opportunistic Encryption [Was: Keys not trusted]
Tue May 13 18:36:02 2003
-----BEGIN PGP SIGNED MESSAGE-----
At 17:52 2003-05-13 +0400, you wrote:
>On Sunday 11 May 2003 04:55 pm, Ingo Kl=F6cker wrote:
>> IMO making the usage of unverified keys too easy (i.e. the user
>> just has to click away a warning) will result in a weakening and a
>> slower growth of the web of trust.
>We should support web-of-trust
>solutions (i.e. use OpenPGP), but we shouldn't ban opportunistic
>encryption in order to force the growth of the Web-of-Trust.
Agree, but I do prefere the robot-CA model for "granny encryption".
>1) Keysigning parties are never going to catch on with the masses.
> It's an expensive operation. Protocols that require expensive
> operations (purchasing a certificate, attending keysigning
> parties, etc.) will never catch on with the masses.
> In order to protect the masses, we need opportunistic encryption.
> Opportunistic encryption may not prevent active attacks, but it
> kills the common case (eavesdropping). To eliminate active
> attacks, we have direct key signing, keysigning authorities
> schemes, and the Web-of-Trust.
Or rather a simple verification binding the key to the e-mailadress
like the robot-CA.
>2) As implemented today, the Web-of-Trust is bad for privacy.
> Advertising e-mail addresses combined with a list of your closest
> contacts (via signatures) works well for an authentication
> protocol, but it's not a good privacy protocol.
True, I'm waiting for the spammers to "tap" the key servers. It can be
done, that's why it will be done eventually. On this list there was a
discussion how to not put the "real" e-mail address in the UID of the
key, but rather a dummy e-mail address "firstname.lastname@example.org"
That might be a problem with the robot-CA model!
>Allow all forms of authentication including no authentication at all.
>Make adding keys and creating local signatures, directly from the
>mail client [with or without the help of an external program], as
>easy as humanly possible.
>3 Authentication Levels:
>L1) No protection (unencrypted, key not available)
>L2) Passive attack protection (encrypted, key not verified)
>L3) Active attack protection (encrypted, key verified)
I would like to add the robot-CA protection i.e. the e-mail address
connected to the key. (The robot signs the key, encrypts it and sends
it to the e-mail addresses in the UID:s of the key. Only a person
having access to both the e-mail account and the secret key can use
the signatures. http://www.toehold.com/cgi-bin/rcacgi )
>The difference between (L2) and (L3) could be clearly visable to the
>user with clever icons. I strongly believe that we can solve this
>problem without confusing the user or giving them a false sense of
>Outstanding Question: How to pick an unauthenticated key?
>If I'm replying to a signed message (and the reply-to address matches
>a UID on the signing key), I would pick the key used to sign the
>received message. If I'm starting a new message, the choice is less
>obvious. When multiple keys with no trust path exist, David Shaw
>proposes that we encrypt to all valid keys. Shaw's solution kills
>the common case of passive eavesdropping (i.e. it's better than what
>we have now). Refinements to Shaw's proposal using some form of
>caching might be possible.
A robot-signature might be useful as it connects the key to the e-mail
> - Yenot
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
-----END PGP SIGNATURE-----