--auto-key-retrieve fails for some keys

[Neal H. Walfield]

On Tue, 02 Nov 2021 18:35:01 +0100,
Phil Pennock via Gnupg-users wrote:
> On 2021-11-02 at 16:05 +0100, Tadeus Prastowo via Gnupg-users wrote:
> > The signature on a Linux kernel can be verified successfully using
> > `--auto-key-retrieve', but the signature on an Emacs cannot be
> > verified in the same manner because gpg is unable to retrieve the
> > needed public key automatically.
> 
> > Any idea why the --auto-key-retrieve feature fails for some keys?
> 
> % gpg --list-packets < emacs-27.2.tar.xz.sig
> # off=0 ctb=89 tag=2 hlen=3 plen=284
> :signature packet: algo 1, keyid 91C1262F01EB8D39
> 	version 4, created 1616673188, md5len 0, sigclass 0x00
> 	digest algo 2, begin of digest 77 61
> 	hashed subpkt 2 len 4 (sig created 2021-03-25)
> 	subpkt 16 len 8 (issuer key ID 91C1262F01EB8D39)
> 	data: [2048 bits]
> 
> % gpg --list-packets < linux-5.11.tar.sign
> # off=0 ctb=89 tag=2 hlen=3 plen=563
> :signature packet: algo 1, keyid 38DBBDC86092693E
> 	version 4, created 1613380292, md5len 0, sigclass 0x00
> 	digest algo 8, begin of digest dc ca
> 	hashed subpkt 33 len 21 (issuer fpr v4 647F28654894E3BD457199BE38DBBDC86092693E)
> 	hashed subpkt 2 len 4 (sig created 2021-02-15)
> 	subpkt 16 len 8 (issuer key ID 38DBBDC86092693E)
> 	data: [4096 bits]
> 
> The shorter keyids are known to be spoofable if someone is willing to
> put enough effort into repeatedly generating keys.  So I can well
> believe that without the full issuer fingerprint, gpg declines to
> automatically retrieve the key.

This doesn't make sense to me.  Sure, someone could do a second
pre-image attack on a 64-bit key id.  But, when gpg downloads the bad
certificate and checks the signature, it will consider the signature
bad.  At that point, gpg could just throw the downloaded certificate
away.  But if the signature is good, then gpg can be certain that it
has the right certificate for the signature.  (Whether the certificate
is authentic is another matter, of course.)

:) Neal