Mailing List Archive

Werner Koch wrote:

> On Thu, 14 May 2020 23:01, Stefan Claas said:
>
> > you would consider including it in GnuPG too and reflecting it in
> > the respective RFC?
>
> The User-IDs are an integral part of OpenPGP and at the core of its
> design. All kind of important information is bound to the user ids
> and thus a key w/o a user ID is basically useless.

I understand that a UID is an integral part, for example if people
need a certification from a trusted CA, which usually requires a full
name and email address.

What I don't understand is why you are not liking the idea to allow
GnuPG to automatically import and process UID-less public key blocks,
if people who trust the GnuPG brand ask for this?

Nobody is asking for UID-less key creation as default behavior.

> There is one exception for this: Derek Atkins (one of the original PGP
> authors) requested certain features to allow the use of a stripped
> down OpenPGP key by space and CPU constrained devices. We integrated
> this into the standard because it is better to use even a stripped
> down format than to come up with just another format.
>
> Direct key signatures were never intended to replace User-IDs and
> their self-signatures.
>
> And no, it is not a privacy issue. If you don't want to put your name
> or mail address into the user ID, just don't do it but use a random
> string or even the keys fingerprint. For the majority of use cases a
> mail address is still the best way to identify and even lookup a key.

GnuPG always asks IIRC new users for their Name and email address
and does not tell them in advance that they can use a free form UID,
without an email address, thus being able to use a key for multiple
accounts or purposes, without adding additional UIDs.

Best regards
Stefan

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


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On Freitag, 15. Mai 2020 13:29:31 CEST Stefan Claas wrote:
> What I don't understand is why you are not liking the idea to allow
> GnuPG to automatically import and process UID-less public key blocks,
> if people who trust the GnuPG brand ask for this?

Because in GnuPG the validity of keys is bound to validity and owner trust of
UIDs. No UID -> invalid key. Why do you want to be able to import a key in
GnuPG that would be utterly unusable?

> GnuPG always asks IIRC new users for their Name and email address
> and does not tell them in advance that they can use a free form UID,
> without an email address, thus being able to use a key for multiple
> accounts or purposes, without adding additional UIDs.

To cite Robert J. Hansen:
"Unless you know what you're doing and why, use the defaults."

Consequently, it's a good thing that GnuPG, by default, doesn't bother new
users with difficult decisions.

Regards,
Ingo




_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Hi Ingo,

On 15.05.2020 14:35, Ingo Klöcker wrote:
> Because in GnuPG the validity of keys is bound to validity and owner trust of
> UIDs. No UID -> invalid key. Why do you want to be able to import a key in
> GnuPG that would be utterly unusable?

AFAIK key validity and owner trust are per key not per User ID.
Third-party signatures are made for key fingerprint and User ID but then
it takes one fully trusted UID (or 3 marginally by default) for the key
to be considered valid. And then if that valid key signs some other User
ID the process starts anew. For signing other keys only the primary key
is needed, not User IDs.

The distinction is important because it affects only the Web of Trust
and only in one way. That is if you owner-trusted that UID-less key it
could become trust introducer in your WoT. Also you could encrypt to
that key and verify signatures just fine (it just wouldn't display
anything meaningful).

Is this useful? I'm not sure, but wanted to point out this one detail.

Kind regards,
Wiktor

--
https://metacode.biz/@wiktor

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

I think we are conflating two related but distinct ideas here.

On 15/05/2020 13:35, Ingo Klöcker wrote:
> Why do you want to be able to import a key in
> GnuPG that would be utterly unusable?

There are use cases where you might want to transfer only the
modifications to a key, without necessarily distributing the entire key.
Publicly revoking a primary key without disclosing its user IDs, for
example. But this is distinct from being able to create a new key with
no user IDs at all, which I see no reasonable use for - if your user ID
is sensitive, then use an alias. Even in the use case described above
the keys have aliases.

--
Andrew Gallagher

On 15/05/2020 14:01, Wiktor Kwapisiewicz via Gnupg-users wrote:
> AFAIK key validity and owner trust are per key not per User ID.

Ownertrust is per-key, but validity is per-UID. On my local machine `gpg
--list-keys wiktor@metacode.biz` shows:

```
pub rsa4096/0x6C8857E0D8E8F074 2017-01-01 [C] [expires: 2021-01-01]
Key fingerprint = 6539 09A2 F0E3 7C10 6F5F AF54 6C88 57E0 D8E8 F074
uid [ unknown] Wiktor Kwapisiewicz <wiktor@metacode.biz>
uid [ unknown] [unknown attribute of size 83]
sub rsa4096/0xB97A1EE09DB417EC 2017-10-18 [S] [expires: 2021-01-01]
sub rsa2048/0x60D2F50529E2DE4F 2018-07-06 [E] [expires: 2021-01-01]
sub rsa2048/0x97FDEF34DAB8F82B 2018-07-06 [S] [expires: 2021-01-01]
sub rsa2048/0x3B6DFCC964CFEBC4 2018-07-06 [A] [expires: 2021-01-01]
```

Each of those `[ unknown]`s represents the validity of that particular
UID only. I could right now add a new UID <president@whitehouse.gov> to
my primary key. The invalidity of <president@whitehouse.gov> would not
invalidate <andrewg@andrewg.com>.

--
Andrew Gallagher

> GnuPG always asks IIRC new users for their Name and email address
> and does not tell them in advance that they can use a free form UID,
> without an email address, thus being able to use a key for multiple
> accounts or purposes, without adding additional UIDs.

It is not the job of the command-line interface to teach users the
subtleties and nuances of OpenPGP. If users want to know the many
different ways GnuPG can be used they need to read the documentation.

If you think this use-case is important enough it should go in the
manpage or FAQ, let's discuss that. But the command-line user interface
is the wrong place to be teaching people about unusual use cases.

On 15.05.2020 15:21, Andrew Gallagher wrote:
> Ownertrust is per-key, but validity is per-UID.

Andrew there are two validity values:

$ gpg --edit-key andrewg
pub rsa4096/FB73E21AF1163937
created: 2013-07-02 expires: 2021-01-07 usage: SCA
--> trust: unknown validity: marginal <--- here (A)
sub rsa4096/6B09069314549D4B
created: 2013-07-02 expires: 2021-01-07 usage: E
sub rsa4096/5C1EC404D5906629
created: 2015-04-26 expires: 2021-01-07 usage: S
sub rsa4096/85FDF561DA8C0C46
created: 2015-04-26 expires: 2021-01-07 usage: A
[marginal] (1). Andrew Gallagher <andrewg@andrewg.com> <-- and here (B)
[marginal] (2) Andrew Gallagher <andrewg@llagher.net>

Value from (A) is calculated from User IDs (B).

When you sign someone else User ID it's not your User ID that is doing
the signing it it's your key that's why you need a key validity that's
separated from User ID (key validity is calculated from User ID validity).

Kind regards,
Wiktor

--
https://metacode.biz/@wiktor

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On 15/05/2020 14:34, Wiktor Kwapisiewicz wrote:
>
> When you sign someone else User ID it's not your User ID that is doing
> the signing it it's your key that's why you need a key validity that's
> separated from User ID (key validity is calculated from User ID validity).

The inputs to the WoT are the signatures and the ownertrust values, and
the outputs are UID validities. "Key validity" is neither an input nor a
meaningful output of the system. It is useful only as an intermediate
step, together with the ownertrust, in the calculation of another UID's
validity. The practical outworking of any validity calculation is not
"Is this key valid?" but "Is this key valid for this UID?".

Also, the following is incorrect:

> Third-party signatures are made for key fingerprint and User ID but then
> it takes one fully trusted UID (or 3 marginally by default) for the key
> to be considered valid.

It takes one fully trusted certifier (*), or three marginally trusted
certifiers (*) on the *same UID*, for a UID to be considered valid.
Three different UIDs of the same key signed by marginal certifiers do
not increase the validity of the key, otherwise increasing the number of
UIDs on a key could boost its validity, which is perverse. ;-)

(* certification by a key that has at least one valid UID and
(full|marginal) ownertrust)

--
Andrew Gallagher

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On Fri, 15 May 2020 14:35, Ingo Klöcker said:

> UIDs. No UID -> invalid key. Why do you want to be able to import a key in
> GnuPG that would be utterly unusable?

FWIW, the expiration time of a key is also bound to the user-id as well
as key preferences and all kind of other possiblke gadgets. And no, a
direct-key signature is no replacement for this.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

Robert J. Hansen wrote:

> > GnuPG always asks IIRC new users for their Name and email address
> > and does not tell them in advance that they can use a free form UID,
> > without an email address, thus being able to use a key for multiple
> > accounts or purposes, without adding additional UIDs.
>
> It is not the job of the command-line interface to teach users the
> subtleties and nuances of OpenPGP. If users want to know the many
> different ways GnuPG can be used they need to read the documentation.
>
> If you think this use-case is important enough it should go in the
> manpage or FAQ, let's discuss that. But the command-line user
> interface is the wrong place to be teaching people about unusual use
> cases.

We now have the situation that either parents or teachers, etc. can
choose between a software which allows UID-less public key generation,
for their minors / students, themselves, or a software which does not
accept this and has no guidelines for free-form UIDs in their FAQ / man
page, nor an equal treatment in the standard key generation process.

Regards
Stefan


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


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

> We now have the situation that either parents or teachers, etc. can
> choose between a software which allows UID-less public key
> generation, for their minors / students, themselves...

They are free to use whatever identifier they like for a UID, even just
the key ID. A UID-free certificate is in no way required for user privacy.

You're being dishonest. I hate to say that, but I believe it's true.
You insist on pretending that you're the only one concerned about
privacy and that UID-free certificates are necessary for privacy of
personally identifying information. The reality is the UID system in no
way requires personally identifying information and everyone you're
accusing of not caring about privacy cares a great deal about it.

You're being dishonest. Please stop.

> or a software which does not accept this and has no guidelines for
> free-form UIDs in their FAQ / man page, nor an equal treatment in the
> standard key generation process.

If you want the documentation to reflect PII-free UIDs, please say that.
This could be a useful discussion. If the community believes PII-free
UIDs should be in the FAQ I will happily write up an entry for it.

Robert J. Hansen wrote:

> > We now have the situation that either parents or teachers, etc. can
> > choose between a software which allows UID-less public key
> > generation, for their minors / students, themselves...
>
> They are free to use whatever identifier they like for a UID, even
> just the key ID. A UID-free certificate is in no way required for
> user privacy.
>
> You're being dishonest. I hate to say that, but I believe it's true.
> You insist on pretending that you're the only one concerned about
> privacy and that UID-free certificates are necessary for privacy of
> personally identifying information. The reality is the UID system in
> no way requires personally identifying information and everyone you're
> accusing of not caring about privacy cares a great deal about it.
>
> You're being dishonest. Please stop.

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.

It is also interesting when you folks seem to run out of arguments
that you try to get personal, but I don't mind and stop, as per
request! :-)

> > or a software which does not accept this and has no guidelines for
> > free-form UIDs in their FAQ / man page, nor an equal treatment in
> > the standard key generation process.
>
> If you want the documentation to reflect PII-free UIDs, please say
> that. This could be a useful discussion. If the community believes
> PII-free UIDs should be in the FAQ I will happily write up an entry
> for it.

Please discuss it with the community and try to add it later to the
documentation as equally treated, in the key generation process.

Regards
Stefan

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


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On 15.05.2020 16:43, Andrew Gallagher wrote:
> The inputs to the WoT are the signatures and the ownertrust values, and
> the outputs are UID validities. "Key validity" is neither an input nor a
> meaningful output of the system.

Key validity directly influences the "WARNING: This key is not certified
with sufficiently trusted signatures" message that I think is pretty
significant for end-users. If it wasn't meaningful it wouldn't be
printed in the --edit-key dialog.

> It is useful only as an intermediate

> step, together with the ownertrust, in the calculation of another UID's

> validity. The practical outworking of any validity calculation is not

> "Is this key valid?" but "Is this key valid for this UID?".

The argument could be reversed stating that "User ID validity is useful
only as an intermediate step to calculate key validity" and we wouldn't
draw any new knowledge from this. My original point was that key
validity exists.

Also: thanks for bringing my mental shortcut to technical correctness:

> It takes one fully trusted certifier (*), or three marginally trusted

> certifiers (*) on the *same UID*, for a UID to be considered valid.

This could of course be further refining by mentioning ownertrust or
that 0x11: Persona certifications do not contribute to this or that
trust signatures affect the algorithm or...

Kind regards,
Wiktor

--
https://metacode.biz/@wiktor

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On Fri, May 15, 2020 at 07:07:40PM +0200, Stefan Claas wrote:
> Robert J. Hansen wrote:
>
> > > We now have the situation that either parents or teachers, etc. can
> > > choose between a software which allows UID-less public key
> > > generation, for their minors / students, themselves...
> >
> > They are free to use whatever identifier they like for a UID, even
> > just the key ID. A UID-free certificate is in no way required for
> > user privacy.
> >
> > You're being dishonest. I hate to say that, but I believe it's true.
> > You insist on pretending that you're the only one concerned about
> > privacy and that UID-free certificates are necessary for privacy of
> > personally identifying information. The reality is the UID system in
> > no way requires personally identifying information and everyone you're
> > accusing of not caring about privacy cares a great deal about it.
> >
> > You're being dishonest. Please stop.
>
> 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.

G'luck,
Peter

--
Peter Pentchev roam@ringlet.net roam@debian.org pp@storpool.com
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13

On Fri, May 15, 2020 at 10:33:12PM +0300, Peter Pentchev wrote:
> On Fri, May 15, 2020 at 07:07:40PM +0200, Stefan Claas wrote:
> > Robert J. Hansen wrote:
> >
> > > > We now have the situation that either parents or teachers, etc. can
> > > > choose between a software which allows UID-less public key
> > > > generation, for their minors / students, themselves...
> > >
> > > They are free to use whatever identifier they like for a UID, even
> > > just the key ID. A UID-free certificate is in no way required for
> > > user privacy.
> > >
> > > You're being dishonest. I hate to say that, but I believe it's true.
> > > You insist on pretending that you're the only one concerned about
> > > privacy and that UID-free certificates are necessary for privacy of
> > > personally identifying information. The reality is the UID system in
> > > no way requires personally identifying information and everyone you're
> > > accusing of not caring about privacy cares a great deal about it.
> > >
> > > You're being dishonest. Please stop.
> >
> > 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.

...and he actually said pretty much that in
06a65d70-6d01-6de0-ec03-c841d64c829b@sixdemonbag.org :)

G'luck,
Peter

--
Peter Pentchev roam@ringlet.net roam@debian.org pp@storpool.com
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13

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.

Regards
Stefan

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


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

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@ringlet.net roam@debian.org pp@storpool.com
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13

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. 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?

Regards
Stefan

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


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

(Sent from my phone)
If and when people insisting on UID-less keys want to communicate with me, I'll tell them the same thing I told users of Imad Faiad's PGP 6.5.8ckt builds, Disastry's PGP builds, and many more:
"I'm sorry, but you're not confirming to the specification. If you wish for me to make sense of your messages, please resend in a conformant message."
The community has literally been dealing with devs breaking the standard for 25 years. We have learned from bitter experience how important standards conformance is.
UIDless certs will get the same response as people using TIGER192 as a hash.

On May 15, 2020 7:36 PM, Stefan Claas <sac@300baud.de> 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. 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?

Regards
Stefan

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


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

rjh@sixdemonbag.org wrote:

> (Sent from my phone)
>
> If and when people insisting on UID-less keys want to communicate
> with me, I'll tell them the same thing I told users of Imad Faiad's
> PGP 6.5.8ckt builds, Disastry's PGP builds, and many more:
>
> "I'm sorry, but you're not confirming to the specification. If you
> wish for me to make sense of your messages, please resend in a
> conformant message."
>
> The community has literally been dealing with devs breaking the
> standard for 25 years. We have learned from bitter experience how
> important standards conformance is.
>
> UIDless certs will get the same response as people using TIGER192 as
> a hash.

So, when you like to communicate with a person who uses such a new
key how do you proceed then?

And you bring up also one interesting point, I like to ask, for the
interested ML reader here.

How does this work in general, let's say I am a dev and would add this
too, to my OpenPGP app. Is there an OpenPGP board where devs can vote
for or against a feature, so that Werner has then to follow suite, or
is he in the position to say no and every dev has to follow his GnuPG
specs?

P.S. Really to bad that Mr. Zimmermann, Bruce Schneier, Prof. Bernstein,
Prof. Green and other crypto experts are not on this ML. I would really
like to hear what they would say to such an OpenPGP feature in 2020.

Regards
Stefan

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


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

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@ringlet.net roam@debian.org pp@storpool.com
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13

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@ringlet.net roam@debian.org pp@storpool.com
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13

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


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

> So, when you like to communicate with a person who uses such a new
> key how do you proceed then?

I tell them, "I will not be able to use OpenPGP with you until such time
as you UID conforms to the standard. Would you like help in making your
user ID standards-conformant in a way that reveals nothing about your
real-world identity?"

This is, in fact, the preferred GNU way. "I'd love to be able to work
with you on this document, but you're using a proprietary format I can't
read. There's an open format we can both use, though, and I'd be happy
to help you get started with it."

> How does this work in general, let's say I am a dev and would add this
> too, to my OpenPGP app. Is there an OpenPGP board where devs can vote
> for or against a feature, so that Werner has then to follow suite, or
> is he in the position to say no and every dev has to follow his GnuPG
> specs?

The RFC is maintained under auspices of the Internet Engineering Task
Force (IETF), just like every other RFC. The IETF's motto is "rough
consensus and running code".

Werner sits as secretary of the (largely dormant) group that guides
OpenPGP development, but there are a lot of non-GnuPG people who are
deeply involved in giving feedback on proposed changes. He's the
secretary, not the dictator.