allow-non-selfsigned-uid issue with key from keys.openpgp.org that contains no identity information

[Daniel Kahn Gillmor]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190729/66118b08/attachment.sig>