keys require a user-id

[Peter Pentchev]

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.

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/81c9347d/attachment.sig>