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

[David]

Playfair via Gnupg-users:
> 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
> 
> 
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 

Why upload a key to a keyserver with no email address? What's the point
of doing that? You cant send an encrypted email to it - unless your
given the email first -will it work to encrypt to a publlic key with no
email?

I got 180 public keys - some are very weird (I should delete them) some
keys are for signing some sub keys are for encrypting and some sub keys
decryption - why not make a key that does it all with a oad of sub keys?

Keyservers should have strict rules on public keys - all to have a valid
email a validation email sent back - then confirmed and that public key
is then available. No identity available - simple - reject the key.

Users of gpg that want to create weird and wonderful keys need to keep
them on their own laptop or desktop - keyservers should be able to purge
off these keys then keyservers would be back to what was intended.

David

-- 
People Should Not Be Afraid Of Their Government - Their Government
Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION
Becomes A DUTY! Join the Rebellion Today! The "Captain's B(L)og"
https://gbenet.com