keys require a user-id

[Peter Pentchev]

On Fri, May 15, 2020 at 10:54:32PM +0200, Stefan Claas wrote:
> Peter Pentchev wrote:
>  
> > On Fri, May 15, 2020 at 07:07:40PM +0200, Stefan Claas wrote:
> 
> > > Mind you, I have only asked that GnuPG should support the import and
> > > processing of UID-less public key blocks and did not requested that
> > > this should be a default behaviour in the key generation process.
> > 
> > And the answer has been given: because those blocks violate the
> > OpenPGP standard and, as I understand Robert J. Hansen (and I
> > apologize to him if I'm putting the wrong words into his mouth), his
> > position is that there is no reason for this violation to exist at
> > all, there is no reason for UID-less key blocks to exist at all, so
> > GnuPG is quite right in following the OpenPGP standard and not
> > accepting them.
> 
> You know what, the most interesting thing of this ML for me is that
> when people, do a request or suggestion the old guard is always there
> to defend some standard and are not accepting that a new product on the
> OpenPGP market, with a new feature included, add an enrichment to a
> given standard, which people may like to use and appreciate.

OK, but *how* is it an enrichment? What does a UID-less key provide over
a randomly-generated UID? Why go to the bother of supporting a new
special case when you can get the same result in another way, with zero
additional code in any of the existing implementations and only a couple
more lines of code in the special client that will have to generate
a random UID?

G'luck,
Peter

-- 
Peter Pentchev  roam at ringlet.net roam at debian.org pp at storpool.com
PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20200516/8f8410d3/attachment-0001.sig>