keys require a user-id

[Peter Pentchev]

On Sat, May 16, 2020 at 04:55:11PM +0300, Peter Pentchev wrote:
> On Sat, May 16, 2020 at 01:36:10AM +0200, Stefan Claas wrote:
> > Peter Pentchev wrote:
> >  
> > > On Fri, May 15, 2020 at 10:54:32PM +0200, Stefan Claas wrote:
> > 
> > > > 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?
> > 
> > Fact is this function is available for users of OpenPGP software.
> 
> Is it though? It is not part of the OpenPGP standard, is it? It is
> available for users of software that implements the OpenPGP standard
> *with some local extensions*, which is a bit different.
> 
> > We should better think of how this will pan out in the future, if users
> > start to use OpenPGP software with UID-less public keyblocks and how
> > GnuPG users can interact with them, or not?
> 
> GnuPG users can interact perfectly well with people who use OpenPGP
> software :) As Robert J. Hansen said, if you (or somebody else) want to
> extend the standard, there is an IETF working group and mailing list for
> that.
> 
> The way I see it, there are two types of standards:
> 
> - ones that are discussed and written before being implemented, so that
>   all the implementors have the same idea and nobody comes up with, say,
>   using the same magic numbers for completely different purposes or
>   having a function accept one more argument than anyone else and break
>   if it is called with fewer arguments
> 
> - ones that standardize existing behavior, like the POSIX standard for
>   operating systems, system calls, libraries, command shell, etc.
> 
> Now, I've been on the POSIX mailing list for well nigh 20 years now, and
> let me tell you, trying to standardize something when different
> implementors have come up with *all kinds* of slightly different ways of
> doing *almost* the same thing can be... crazy. Insane. Amazingly,
> astonishingly, horrifyingly weird, and very time- and nerve-consuming.
> 
> It seems to me that the people involved in developing the OpenPGP
> standard did, at one point, decide to go the other way: yes, sure, start
> with the existing PGP and GnuPG and other implementations, but then,
> when thinking about future work, decide to discuss things before
> implementing them (recent threads on the OpenPGP mailing list
> notwithstanding), so that it is sorta kinda expected that once various
> implementations gain the new features, they *will* be able to
> interoperate. That sounds... kind of reasonable to me.

Just one more point that I forgot to write: *of course* it's fine for
people to implement experimental things to see if they'll work... within
reasonable bounds, of course, like not implementing new algorithm
identifiers outside the space reserved for experimental ones. But it is
also fine for other people to say "okay, sure, you have your
experimental features, but I'll wait until they're standardized until
I do the work on implementing them myself; also, let's discuss whether
they are even needed."

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/55e3e100/attachment-0001.sig>