keys require a user-id

[Stefan Claas]

Peter Pentchev wrote:
 
> 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."

Thanks for the write up, this mostly anwsers my question I had for
Robert.

Regards
Stefan

-- 
Signal (Desktop) +4915172173279
https://keybase.io/stefan_claas