Disable importing V3 public keys from keyservers

[Werner Koch]

On Fri, 10 Oct 2014 15:41, coruus at gmail.com said:

> I don't think that this is, in fact, correct. Using default settings
> (by creating a new blank home directory), GnuPG 2.0.26 (and 1.0.18)
> will import V3 keys from keyservers. (Note: my test keys have V4
> signatures.)

Sure, gpg will import those keys - but they are not usable:

  $ ~/b/gnupg-2.0/g10/gpg2 --fingerprint 
  gpg: keyring `/home/wk/b/gnupg/tmp2/pubring.gpg' created
  gpg: /home/wk/b/gnupg/tmp2/trustdb.gpg: trustdb created

This is using 2.0 HEAD with devevelopment warning notices removed and
running under a 2.1 agent.
  
  $ ~/b/gnupg-2.0/g10/gpg2 --import foo.keys 
  gpg: keyring `/home/wk/b/gnupg/tmp2/secring.gpg' created
  gpg: key 1E42B367: public key "Werner Koch <wk at gnupg.org>" imported
  gpg: key BE2CD9C1: public key "Tails developers (signing key) <tails at boum.org>" imported
  gpg: Total number processed: 2
  gpg:               imported: 2  (RSA: 2)
  
Imported as expected.  Lets look at the keys:

  $ ~/b/gnupg-2.0/g10/gpg2 --fingerprint     
  /home/wk/b/gnupg/tmp2/pubring.gpg
  ---------------------------------
  pub   4093R/1E42B367 2013-08-05
        Key fingerprint = EE B9 99 D0 78 3A 36 C8  90 8A 0B A0 72 82 93 F2
  uid       [ unknown] Werner Koch <wk at gnupg.org>
  
  pub   4091R/BE2CD9C1 2013-08-05
        Key fingerprint = DB A5 C7 C2 62 21 16 25  A9 A5 59 ED 42 5D 7D 99
  uid       [ unknown] Tails developers (signing key) <tails at boum.org>
  
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.  Everyone else wonders why this fingerprint does not match the
one on the business card etc and why it is formatted in that strange
way.  But well, if that guy want me to encrypt to this key let's do it:

  $ fortune | ~/b/gnupg-2.0/g10/gpg2 --no-encrypt-to -vear 1E42B367 
  gpg: 1E42B367: skipped: Unusable public key
  gpg: [stdin]: encryption failed: Unusable public key
  
Ooops.  Now to make it even more clear to newbies I propose a change
which leads to 

  $ ~/b/gnupg-2.0/g10/gpg2 --fingerprint 
  /home/wk/b/gnupg/tmp2/pubring.gpg
  ---------------------------------
  pub   4093R/1E42B367 2013-08-05
        Key fingerprint = 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
  uid       [ unknown] Werner Koch <wk at gnupg.org>
  
  pub   4091R/BE2CD9C1 2013-08-05
        Key fingerprint = 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
  uid       [ unknown] Tails developers (signing key) <tails at boum.org>
  
That should make it pretty clear that there is something wrong with the
key.

> If the current behavior isn't the intended one (particularly for
> import via --import), then this may be CVE-worthy; it's a classic
> protocol-format crossgrade.

No it is not: You accept an arbitrary key without checking the
fingerprint (direct or via the WoT) - any responsible user won't let you
use his old v3 key.  But to make it easier to notice a v3 key, I suggest
to do the above change (--allow-weak-digest-algos will revert that of
course).

> Is there any way to disable it completely? Only some operations seem
> to warn when using MD5.

I can't see that there is only a warning.

> (Note: I may be missing something in the code of GnuPG 2.1; I'm

The above is 2.0 and the MD5 rejection is there since 2.0.23 (June this
year).  2.1 is similar.  1.4 has only a warning.

> I'd rather see V3 import from external sources -- even for key refresh
> -- disabled entirely. There's some other code that could be removed in

This whole thing has nothing to do with keyservers or import.  The whole
idea of putting any trust in the source of the key is broken.

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.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.