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

[Playfair]

On 8/1/19 7:37 AM, Werner Koch via Gnupg-users wrote:
> On Mon, 29 Jul 2019 09:43, gnupg-users at gnupg.org said:
>> 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.
> 
> The user ID is important because the accompanying self-signature conveys
> important information about the keyblock.  For example expiration date
> and preferences.  It is true that this can also be conveyed with
> direct-key-signatures (a self-signature directly on a key which was
> mainly introduced for dedicated revocations).  However, this is a not so
> well tested feature of gpg and my educated guess is that many other
> OpenPGP implementations do not handle direct-key signatures in a way
> compatible to pgp or gpg - if at all.  Thus by relying on them we would
> sail into uncharted waters.
> 
>> Doing such a merge would be super helpful, particularly for receiving
>> things like subkey updates and revocation information from
> 
> I agree that we can add a code path to import a primary key plus
> revocation certificate but without user-ids.  PGP however, does not
> support this and is the reason why we extended the revocation
> certifciate with a minmal primary key.
> 
> Update of subkeys is a different issue and I see no solid use case for
> allowing that without user-id (cf. expiration date of the primary key).

Couldn't this issue be dealt with by the key server instead of by
OpenPGP implementations?  GnuPG can create and import keys having
non-email-address user IDs.  A string of more than 4 characters is
acceptable.  Anything remotely resembling an email address, e.g.
x at y.xyz, is okay.

If keys.openpgp.org won't publish a user ID other than a verified email
address, is its only recourse to remove the user ID?  Could it instead
substitute the hex key ID, fingerprint or a dummy string like "User ID
not verified"?  If it can't, is there any benefit in publishing a
mutilated key people can't use?  Just reject it.

Chuck


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190801/88f20dd4/attachment.sig>