Working around SHA1 signatures in keyring

[Ingo Klöcker]

On Freitag, 26. März 2021 22:54:51 CET alejandro Cortez via Gnupg-users wrote:
> For a few years, using gpg (GnuPG) 2.0.22 / libgcrypt 1.5.3 from
> ubuntu-14.04 I signed coworker keys using Preferences: AES256 SHA512
> BZIP2 ZLIB ZIP in gpg.conf. I am currently setting up an ubuntu-20.04
> workstation with gpg (GnuPG) 2.2.19 / libgcrypt 1.8.5 and it would
> seem that my config got wiped at some point because the last two keys
> I signed (several months ago) give the following error when checking
> sigs on my new workstation:
> 
> gpg: Note: third-party key signatures using the SHA1 algorithm are rejected
> 
> I should point out that I had to add no-self-sigs-only to the
> keyserver-options as I guess the default workaround to poisoned keys
> (either in the original source or something debian or ubuntu added) is
> a scorched earth policy, which is fine but unworkable to our web of
> trust.

From gpg's NEWS file:
=====
* gpg: Prepare against chosen-prefix SHA-1 collisions in key
    signatures.  This change removes all SHA-1 based key signature
    from the web-of-trust.  Note that this includes all key signature
    created with dsa1024 keys.  (Version 2.2.18 limits this to key
    signatures newer than 2019-01-19.)  The new option
    --allow-weak-key-signatues[sic] can be used to override the new and
    safer behaviour.  [#4755,CVE-2019-14855]
=====

Of course, the option is called --allow-weak-key-signatures.

> I created some test keys to mimic the same situation and did
> the following to try to fix it:
> 
> gpg --cert-digest-algo SHA512 --expert --edit-key <key to resign>
> 
> I deleted my original signature and signed again. Then I pushed the
> test key to the keyservers and added import-clean to gpg.conf and
> refreshed the keys from a different test user and it _seems_ to work.
> Is this a sane fix? Is there a better or more proper fix?

Well, deleting your original signature is useless if you have already 
published a key with this signature. Signing the key again with SHA512 is the 
proper fix. Note, that using "gpg --quick-sign-key" may be more convenient 
than using --edit-key.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20210327/9821eae3/attachment.sig>