Disable importing V3 public keys from keyservers

[Dan Haskin]

It seems to me that if people want to read their old mail, they can simply
use GPG 1.4 . It feels like a lot of effort is being put into making sure
2.1 (mostly) works with GPG 1.4 . Even if it doesn't, it would not be hard
for someone to use GPG 1.4 to import their old keys, decrypt their mail,
and encrypt it using a new home folder and a new, better key.

v3 was deprecated back in version 1.4. This is the way it works in most
modern software <http://semver.org/>: the old feature is deprecated back in
the previous major release (1), and is erased in the next major release
(2). The DEPRECATED message in 1.4 is clear. People therefore have known
that they should probably switch away from it.  Users have been given
adequate time to re-encrypt their old mail, since this deprecation was done
a long time ago. Further, 1.4 still works and is still actively maintained,
making it easy for them to re-encrypt their old mail even after the 2.1
release.  I feel like removing it completely in 2.1 is the way to go.

Daniel Jay Haskin
http://djhaskin987.github.io/

On Fri, Oct 10, 2014 at 12:47 PM, David Leon Gil <coruus at gmail.com> wrote:

> On Fri, Oct 10, 2014 at 2:13 PM, Werner Koch <wk at gnupg.org> wrote:
> > Sure, gpg will import those keys - but they are not usable:
>
> The reason GnuPG can't encrypt to those keys is because the signature
> packet does not have the "encrypt" key usage flag set, as doing gpg
> --list-packets would show you. (I didn't set these flags in the sample
> code so that people wouldn't inadvertently encrypt to these spoofed
> keys.)
>
> If I set those bits, this works:
>
>      gpg2 --home ./test --keyserver 127.0.0.1 -r wk at gnupg.org  -e
> test/pubring.gpg
>     gpg: 621CC013: There is no assurance this key belongs to the named user
>
>     pub  3839R/621CC013 2013-08-05 Werner Koch <wk at gnupg.org>
>     Primary key fingerprint: F5 05 05 91 B3 2C F2 E2  DB 25 4C 41 D4 16 4A
> 13
>
> (It obviously isn't your key: it's >> 2048 bits.)
>
> Attached. Try it for yourself.
>
> > The real bug with faked keys is that they will clog the keyring because
> > we take the first matching _keyid_.  But the very same problem exists
> > with v4 keys.  Indeed, we better fix that problem for 2.1.0.
>
> Very much agree; this is why I'm particularly concerned about
> keyservers. (It's just an easy way for anyone on a public wifi
> network, say, to generate a key that will make verifying downloaded
> software impossible for anyone without a lot of experience using
> GnuPG.)
>
> > Aihh, those old broken v3 keys.  The usual practice of checking creation
> > date and key length in addition to the fingerprint comes to mind of old
> > timers.
>
> Agreed. Is showing fingerprints the default in 2.1.0 then? (Maybe this
> could get added to point releases too.)
>
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20141010/00a7a6ad/attachment.html>