Hi MFPA-- On Sun 2019-07-28 14:12:45 +0100, MFPA via Gnupg-users wrote: > I have the option "allow-non-selfsigned-uid" in my gpg.conf.
A bit of background first, since the documentation around allow-non-selfsigned-uid appears to be confusing/mistaken. the manual says: --allow-non-selfsigned-uid --no-allow-non-selfsigned-uid Allow the import and use of keys with user IDs which are not self-signed. This is not recommended, as a non self-signed user ID is trivial to forge. --no-allow-non-selfsigned-uid disables. But in fact the default (--no-allow-non-selfsigned-uid) does not actually disallow the import or use of an OpenPGP certificate with a user ID which is not self-signed; it simply strips any non-self-signed user IDs from the certificate, and then deals with the remaining trimmed-down certificate as it would have had those user IDs not been present. But none of this means that a certificate *without* any user ID at all is the same as a certificate with a user ID that happens to be unsigned. (though it's trivial to get from the former to the latter by injecting an arbitrary user ID packet into the certificate stream) before any subkey packets. > I downloaded a key from keys.openpgp.org with no identity information. > > GnuPG told me:- > gpg: Invalid key 0x84D0F6B3F5007E2C made valid by > --allow-non-selfsigned-uid > but still didn't import the key. This suggests that the message was > incorrect and the key was not made valid by the > --allow-non-selfsigned-uid option. > > I used pgpdump to visualise the packets, and could see no User ID > Packet. There was not a non-selfsigned-uid; there was no UID at all. RFC 4880 mandates a user ID in any "Transferable Public Key" (aka "OpenPGP certificate"): https://tools.ietf.org/html/rfc4880#section-11.1 However, there is an expectation of relaxing this in the next revision of the standard: https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-07#section-11.1 GnuPG currently rejects OpenPGP certificates that lack any user ID at all, in part because it is more difficult to manipulate them (they have no user ID to refer to them by), and in part because "we've always done it that way", i think. Perhaps Werner can provide more background on why GnuPG is generally resistant to holding OpenPGP certificates that have no User ID at all in its local keyring. All that said, it's possible for GnuPG to merge a uid-less certificate (including e.g. subkeys, revocation certificates, etc) with a locally-held certificate (i.e., in the "keyring") that *does* have a user ID, so long as both certificates share the same primary key. The resultant merged certificate will have a user ID, and can be reasoned about using the same logic that GnuPG already expects, even if the incoming uid-less certificate would have been ignored if it were imported into an otherwise empty keyring. Doing such a merge would be super helpful, particularly for receiving things like subkey updates and revocation information from abuse-resistant keystores like keys.openpgp.org. The good news is that there are patches outstanding for GnuPG to do so: https://dev.gnupg.org/T4393 If you're using debian or a debian-derived installation of GnuPG, those patches have been merged as of version 2.2.16-2 (ses https://bugs.debian.org/930665), and i'm currently trying to get them merged for the next stable point release of debian "buster" (see https://bugs.debian.org/932684). Hopefully GnuPG will follow suit upstream, as these patches provide critical security defenses for users who refresh their keyrings to check for revocations and subkey rotation. Regards, --dkg
signature.asc
Description: PGP signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users