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 r...@ringlet.net r...@debian.org p...@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
