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.

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

Please, just "Rob". :)

I share a name with Robert "rsnake" Hansen of SecTheory. He and I have
both spoken at Black Hat and DEF CON (which has sometimes led to
hilarious results when journalists have tried to track us down to talk
about our research).

In order to reduce confusion I always use my middle initial
professionally. But I go by Rob. :)

Robert J. Hansen wrote:

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

Thanks for your reply, much appreciated!

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 16-05-2020 15:57, Peter Pentchev wrote:

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

Have the bureaucrats who define standards have finally fixed the DOS
issues about keys spammed with signatures or is it still being
"discussed whether they are even needed."?

This strictly following standards removes all flexibility from
implementations. I am beginning to understand Moxie Marlinspike's ideas
about all these committees holding back progress better and better.

--
ir. J.C.A. Wevers
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html

On 16-05-2020 17:56, Robert J. Hansen wrote:

> I tell them, "I will not be able to use OpenPGP with you until such time
> as you UID conforms to the standard.

You confuse "not being able to" with "not willing to".

--
ir. J.C.A. Wevers
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html

> Have the bureaucrats who define standards have finally fixed the DOS
> issues about keys spammed with signatures or is it still being
> "discussed whether they are even needed."?

GnuPG had a bug in the key importation code which made it run in time
proportional to the square of the number of signatures. Importing a
certificate with 100,000 signatures was literally a hundred million
times slower than importing a certificate with 10.

That bug has since been fixed. With judicious use of the various -clean
options, the key spamming bug is effectively dead... on the GnuPG side:
on the SKS side, people are still filling up SKS keyservers with spam.

SKS is a completely separate project from GnuPG, and has no RFC guiding
it. So the "bureaucratic" project has it resolved, and the "free to
innovate" project has been unable to innovate.

(Note: I'm not blaming SKS. This is a hard problem. I personally don't
think SKS can be saved.)

On Sat, May 16, 2020 at 04:28:58PM -0400, Robert J. Hansen wrote:
>With judicious use of the various -clean options, the key spamming bug
>is effectively dead...

I’d like to point out that the options you are referring to are actually
enabled by default nowadays (since 2.2.17). So from an user’s point of
view, the judicious thing to do is simply to use the latest GnuPG
version available.

I am pointing that out because people could interpret your comment as
meaning that GnuPG requires some tinkering of its options in order to be
safely usable with regard to the SKS spamming issue. That’s not the
case; the default configuration is fine.

- Damien

> I’d like to point out that the options you are referring to are actually
> enabled by default nowadays (since 2.2.17).

Thank you, Damien. :)

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

Not everyone agrees.

https://mailarchive.ietf.org/arch/msg/openpgp/XxZt89Eh7XUenuVRajbgtcWzWdA/

- V

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

Hey folks,

this thread touches on userid-less keys, and keyservers.

I agree with Peter and Rob's points that userid-less keys are questionable for
use as-is. OpenPGP transfers information in the self-signatures of user ids. If
we use keys without any known UID, we might miss out on e.g. expiration dates,
or key flags.

There is one more angle to this topic: key updates. keys.openpgp.org uses
userid-less keys in some cases, to distribute revocations and subkey updates.
More specifically, this happens when no User ID on a key has been verified.

The logic is simple:

1. Without consent, we don't distribute email addresses.
2. We want to distribute revocations and subkey updates regardless.
3. Revocations and key updates are cryptographically independent from User IDs.

A key store that already has a UserID for some key can integrate revocation
certificates and subkey updates from such a userid-less key into its local
certificate. Implementation-wise, this is easy to do.

GnuPG upstream rejects such updates. Conretely, if you hand a primary key with
only a revocation signature to GnuPG, it will parse the revocation, verify that
it is cryptographically valid, and then throw it away.

For those interested, this issue has been discussed at length here:
https://dev.gnupg.org/T4393

Cheers

- V


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

I'm just curious as to what this "GNU" way is? I assume you would just a
non identifiable email address and then either leave your name blank,
incomplete, or just plain incorrect.

Is there another way I am missing?

Thanks

On 5/16/2020 8:56 AM, Robert J. Hansen wrote:
>> 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."
>
>
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

> I'm just curious as to what this "GNU" way is? I assume you would
> just a non identifiable email address and then either leave your
> name blank, incomplete, or just plain incorrect.

GNU is a project by the Free Software Foundation. They're very focused
on what they call "free software", where freedom is about liberty and
not price. (Most people call it "open source software" instead, but FSF
and GNU are very particular about the language they use.)

FSF and GNU are both very concerned about the spread of proprietary
formats. For instance, for many years only Microsoft Word could read
.doc files. This was a problem for people who wished to only use free
software.

So the FSF/GNU way was, whenever someone tried to send them a document
in a proprietary format, was to tell the sender

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

GnuPG is part of the GNU project. I think we should use the standard
GNU response when people want us to use certificate formats that don't
comply with the OpenPGP standard.

You can learn more about the FSF at:

https://www.fsf.org/about/

You can learn more about GNU at:

http://www.gnu.org/gnu/about-gnu.html

Hope this helps.

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

On Sun, 17 May 2020 10:48, Vincent Breitmoser said:

> 1. Without consent, we don't distribute email addresses.

And by that changing the distributed system of keyservers into a
centralized key database like PGP tried this with their Universal
Server. Which unavoidable will change OpenPGP to a centralized systems.
If you want that use X.509 or to get complete centralization use Signal.

> 2. We want to distribute revocations and subkey updates regardless.

Go readup on the failures and impracticalities of CRLs and OCSP.

> GnuPG upstream rejects such updates. Conretely, if you hand a primary
> key with only a revocation signature to GnuPG, it will parse the
> revocation, verify that it is cryptographically valid, and then throw

There is a simple reason for that: You don't want to type in an entire
keyblock in the case you need to revoke your key and you only got the
printout of the revocation certificate.


Shalom-Salam,

Werner

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

Stefan Claas wrote:

> Robert J. Hansen wrote:

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

I would like to start the discussion, because I like to point out one
more thing, why I like the UID-less and label approach, compared to a
freeform UID.

Let's say I would regularly communicate with you, dkg and Werner etc.

In sequoia I would import the public keyblocks and could label them,
for example with rjh or rob, dkg and wk and would then use for the
recipient parameter -r rob -r dkg -r wk, which I can easily memorize.

With the freeform approach, when I would have to use (auto) generated
random chars or the fingerprint then I would have problems memorizing
if this was your, dkg's or Werner's public keyblock and it could be
also more error prone (typos), when using this method, in CLI mode.

You can argue now that you can give a freeform UID the name rob or rjh
too, but this would maybe not so good, because your are publicity known
as rob or rjh, thus defeating the purpose a bit.

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 18/05/2020 12:12, Stefan Claas wrote:
> You can argue now that you can give a freeform UID the name rob or rjh
> too, but this would maybe not so good, because your are publicity known
> as rob or rjh, thus defeating the purpose a bit.

If your threat model includes your endpoint device being compromised and
leaking your contact list, then you should be implementing an extra
layer of protection such as Tails and/or a hidden VeraCrypt volume. In
the vast majority of scenarios, endpoint compromise is Game Over, and
tinkering with obfuscation will not help you.

--
Andrew Gallagher

Andrew Gallagher wrote:

> On 18/05/2020 12:12, Stefan Claas wrote:
> > You can argue now that you can give a freeform UID the name rob or
> > rjh too, but this would maybe not so good, because your are
> > publicity known as rob or rjh, thus defeating the purpose a bit.
>
> If your threat model includes your endpoint device being compromised
> and leaking your contact list, then you should be implementing an
> extra layer of protection such as Tails and/or a hidden VeraCrypt
> volume. In the vast majority of scenarios, endpoint compromise is
> Game Over, and tinkering with obfuscation will not help you.

Agreed! It should be also mentioned, that if UID-less public keyblocks
end up more and more on keyservers it is harder for 3rd parties to
maintain a database, since as you know, everybody is still be able to
download complete keyserver dumps from SKS.

Thanks to Vincent this is no longer possible with Hagrid!

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

> And by that changing the distributed system of keyservers into a
> centralized key database like PGP tried this with their Universal
> Server. Which unavoidable will change OpenPGP to a centralized systems.

I think that's a little excessive, Werner. OpenPGP was always intended
to be flexible on the subject of certificate distribution, and there are
many use cases where a single authoritative keyserver is preferred over
a distributed federation.

In 2001 I was the chief system administrator for a law firm which used
OpenPGP to secure client communications. (It didn't require clients to
use OpenPGP but provided it as an option for clients who were concerned
about email privacy.) The procedure was simple: when you opted into
OpenPGP you showed up at your attorney's office in person with your
certificate burned on a CD. Your attorney then called in a member of
the sysadmin staff (usually me) who would check fingerprints with you,
before signing it with the firm's trusted-introducer key and uploading
it to the firm's own keyserver.

Doing it this way meant we could skip long conversations about, "but
can't anybody get my certificate if it's on the internet?" Instead of
spending 30 minutes talking about why it's okay if public certificates
are shared, we could instead just say "we're not going to share your
public key with anyone without your written consent" and spend those 30
minutes talking abut more productive things.

Centralized key management schemes are sometimes very useful.

On 18-05-2020 18:16, Robert J. Hansen wrote:

> Instead of
> spending 30 minutes talking about why it's okay if public certificates
> are shared, we could instead just say "we're not going to share your
> public key with anyone without your written consent" and spend those 30
> minutes talking abut more productive things.

Which might be a good thing for those customers, the fact alone that
someone is a customer of a certain law firm might be sensitive
information in some cases.

--
ir. J.C.A. Wevers
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html

On Mon, 18 May 2020 12:16, Robert J. Hansen said:

> Centralized key management schemes are sometimes very useful.

I fully agree and I personally known that this is a common use case.

However, people requiring such a use case do not talk in the public
about their specific infrastructure and are also not affected by the
alleged privacy enhancements needs people are talking about.

The nice thing with OpenPGP is that you can implement any kind of PKI
with it and you are not as restricted as with X.509/PKIX. And it is
just one RFC and not several dozens RFCs and other documents you all
need to read, analyze, and guess like we see the PKIX world.


Shalom-Salam,

Werner

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

> With the freeform approach, when I would have to use (auto) generated
> random chars or the fingerprint then I would have problems memorizing
> if this was your, dkg's or Werner's public keyblock and it could be
> also more error prone (typos), when using this method, in CLI mode.
--group {name=value}
Sets up a named group, which is similar to aliases in email pro?
grams. Any time the group name is a recipient (-r or --recipi?
ent), it will be expanded to the values specified. Multiple
groups with the same name are automatically merged into a single
group.

The values are key IDs or fingerprints, but any key description
is accepted. Note that a value with spaces in it will be treated
as two different values. Note also there is only one level of
expansion --- you cannot make an group that points to another
group. When used from the command line, it may be necessary to
quote the argument to this option to prevent the shell from
treating it as multiple arguments.

The feature you want, GnuPG already has. If my certificate had no email
address listed, you could put

group rjh@sixdemonbag.org=0x1DCBDC01B44427C7

... and then whenever you asked GnuPG to encrypt something for
rjh@sixdemonbag.org, GnuPG would silently substitute my certificate.

So let's recap:

* PII-free UIDs are possible today
* Nobody is forced to put PII in a UID
* Certificates can be relabeled with the 'group' option

It really seems like after all this discussion the only thing left is
you think GnuPG ought do a better job documenting how to create a
PII-free UID. And if you can get the community to back you on that I'll
draft it myself.

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

Robert J. Hansen wrote:

> > With the freeform approach, when I would have to use (auto)
> > generated random chars or the fingerprint then I would have
> > problems memorizing if this was your, dkg's or Werner's public
> > keyblock and it could be also more error prone (typos), when using
> > this method, in CLI mode.
> --group {name=value}
> Sets up a named group, which is similar to aliases in email
> pro? grams. Any time the group name is a recipient (-r or --recipi?
> ent), it will be expanded to the values specified.
> Multiple groups with the same name are automatically merged into a
> single group.
>
> The values are key IDs or fingerprints, but any key
> description is accepted. Note that a value with spaces in it will be
> treated as two different values. Note also there is only one level
> of expansion --- you cannot make an group that points to another
> group. When used from the command line, it may be necessary
> to quote the argument to this option to prevent the shell from
> treating it as multiple arguments.
>
> The feature you want, GnuPG already has. If my certificate had no
> email address listed, you could put
>
> group rjh@sixdemonbag.org=0x1DCBDC01B44427C7
>
> ... and then whenever you asked GnuPG to encrypt something for
> rjh@sixdemonbag.org, GnuPG would silently substitute my certificate.

Thanks for the info, I was not aware of it.

> So let's recap:
>
> * PII-free UIDs are possible today
> * Nobody is forced to put PII in a UID
> * Certificates can be relabeled with the 'group' option
>
> It really seems like after all this discussion the only thing left is
> you think GnuPG ought do a better job documenting how to create a
> PII-free UID. And if you can get the community to back you on that
> I'll draft it myself.

I doubt that I can get the community to back this ... But thanks for
the offer.

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi


On Friday 15 May 2020 at 11:12:31 PM, in
<mid:20200515221231.GP9891@straylight.m.ringlet.net>, Peter Pentchev
wrote:-


> to generate a random UID?

Would a random UID be the way to go? How about a placeholder UID that
was replaced at the end of key generation by a UID that matches the
key-ID or fingerprint?

- --
Best regards

MFPA <mailto:2017-r3sgs86x8e-lists-groups@riseup.net>

Do what you can, with what you have, where you are.
-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCXsRutl8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw
Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju
+jZJAQDVaEo+PB3C0QTUfb7gctrOWZKtXCKPDkqCiv8V++1K5wD8CHrq0AOsORzX
Kv5zqkj8FJDcQvRdK4UkUv3LNKtUQwCJApMEAQEKAH0WIQRSX6konxd5jbM7JygT
DfUWES/A/wUCXsRutl8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw
REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/+7PEACgIrT0WJ11w3B/IXOxr8CtFVCW
4cCUlu2mWyGC2ZJolwtWvvEf5MPkd5qlBJ78y8sjG7VovZQeyd058dhFO6ScO7xs
zhdcPDGG88XE0KuHyPDaabty5s3/ZeTRIELcOf7WmKWO28MlDIe62b6uS9/10Hj6
HkGFbJovrX3x/NLdGo9Icg2UD4OduXQga+AA+qDWrqZQUeqAQSKA5+4YKqrviaZF
QBaYzUuUoAkjoVQ8DqB0a04qgvQ+ctcW+5OL6d2hMLEAFE5WWHS2MSDNAlUsESKP
Uo1zWal7DwlRCXta6QQVji4oX5w8/GPvXMNqVJkqcu6+KFDimBKSg1Rasl+BTBln
OZHY0YWGW1wTXC7xqHa/AHjW+MbL/n2IOMIxIWxmVWqbAV6WpSt+CMj5x0pnRc7V
lwN8mXA1Fh9PgLnPzPJnr/BSvNbH+yGKv3KZXLm3s97QI7KZjX0S2uXDdKNhoZe2
I9lmneUP44OHXBxODdPdPF0pBPZ1H5eLn4QB1LLYWk0Q/zby0UIa+XOKAoQ+F3ub
41OjN3ocImQj7FsqWjWZ9hOB8QyvN1e+3hVYzwwp3+nksx+q+357oyXj+m1adwGG
DZj2y5AgWdvgp82VneBNI2i8AJfGiOvJ6bRusjAUe3CbgulQvjict6MOULTZ6uDI
9AeVasGsXEmmIn6KPA==
=Xl+u
-----END PGP SIGNATURE-----


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

Just to test this out I tried creating a new key in Kleopatra with no
name and then with just a single name and it would not let me do it. It
had to have a first and at least a last initial. 

On 5/19/2020 7:29 AM, Robert J. Hansen wrote:
>> With the freeform approach, when I would have to use (auto) generated
>> random chars or the fingerprint then I would have problems memorizing
>> if this was your, dkg's or Werner's public keyblock and it could be
>> also more error prone (typos), when using this method, in CLI mode.
> --group {name=value}
> Sets up a named group, which is similar to aliases in email pro?
> grams. Any time the group name is a recipient (-r or --recipi?
> ent), it will be expanded to the values specified. Multiple
> groups with the same name are automatically merged into a single
> group.
>
> The values are key IDs or fingerprints, but any key description
> is accepted. Note that a value with spaces in it will be treated
> as two different values. Note also there is only one level of
> expansion --- you cannot make an group that points to another
> group. When used from the command line, it may be necessary to
> quote the argument to this option to prevent the shell from
> treating it as multiple arguments.
>
> The feature you want, GnuPG already has. If my certificate had no email
> address listed, you could put
>
> group rjh@sixdemonbag.org=0x1DCBDC01B44427C7
>
> ... and then whenever you asked GnuPG to encrypt something for
> rjh@sixdemonbag.org, GnuPG would silently substitute my certificate.
>
> So let's recap:
>
> * PII-free UIDs are possible today
> * Nobody is forced to put PII in a UID
> * Certificates can be relabeled with the 'group' option
>
> It really seems like after all this discussion the only thing left is
> you think GnuPG ought do a better job documenting how to create a
> PII-free UID. And if you can get the community to back you on that I'll
> draft it myself.
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

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

> On 20 May 2020, at 06:32, Mark <azbigdogs@gmx.com> wrote:
>
> Just to test this out I tried creating a new key in Kleopatra with no
> name and then with just a single name and it would not let me do it. It
> had to have a first and at least a last initial.

This must be a Kleopatra limitation. I have successfully created IDs consisting of a single word using the gpg command line.

Such a limitation would be user-hostile, as there are people in some cultures who have only one name, the Indonesian dictator Suharto being one famous example.

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

On 18/05/2020 07:14, Werner Koch via Gnupg-users wrote:
> Go readup on the failures and impracticalities of CRLs and OCSP.

While I agree that revocation is a Very Hard Problem, I'm not convinced
that its abandonment is warranted. Letsencrypt have sidestepped the
issue by issuing short-expiration certs and requiring users to
continually refresh. This is practical for servers under X509 (where
automation is easy and the trust model is centralised) but not for
hyper-distributed PGP. So while revocation cannot be entirely relied
upon, it's still better than nothing and I think we should continue to
support it as best we can.

--
Andrew Gallagher

On Tue, 19 May 2020 10:29, Robert J. Hansen said:

> * PII-free UIDs are possible today

Well, according to European law this is not that easy because a public
key is in most cases an attribute which identifies a natural person.
This is the same as with phone numbers and mail addresses. In Germany
even dynamically assigned IP addresses are attributes which can be used
to identify a person and thus are subject to GDPR.

OTOH, the GDPR does not forbid the use of this data, there are just
rules on how they can be used. WP describes the basic rules as:

Unless a data subject has provided informed consent to data processing
for one or more purposes, personal data may not be processed unless
there is at least one legal basis to do so. Article 6 states the
lawful purposes are:

(a) If the data subject has given consent to the processing of his or
her personal data;

(b) To fulfill contractual obligations with a data subject, or for
tasks at the request of a data subject who is in the process of
entering into a contract;

(c) To comply with a data controller's legal obligations;

(d) To protect the vital interests of a data subject or another
individual;

(e) To perform a task in the public interest or in official authority;

(f) For the legitimate interests of a data controller or a third
party, unless these interests are overridden by interests of the
data subject or her or his rights according to the Charter of
Fundamental Rights (especially in the case of children).

IMHO, point d covers the case of distributing and using a public key for
the purpose of securing the communication with the data subject. The
key may of course not be used for any other purpose (i.e. tracking
behaviour etc). Hacker be aware, the lay is not a machine, it works
different than we tend to assume.


Shalom-Salam,

Werner

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

Werner Koch via Gnupg-users wrote:

> On Tue, 19 May 2020 10:29, Robert J. Hansen said:
>
> > * PII-free UIDs are possible today
>
> Well, according to European law this is not that easy because a public
> key is in most cases an attribute which identifies a natural person.

Curious as I am, did Mr Sch?nbohm never asked you why your public
keyblock is not signed by Governikus?

I ask, because don't you think that this could not have an impact on
the spread and usage of GnuPG in the EU for business purposes etc. and
for example if you would accept UID-less public keyblocks, privacy
concerned parents could for example allow their minors to use GnuPG,
while mom, dad or their teacher could sign their public keyblock?

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

Stefan Claas wrote:

> I ask, because don't you think that this could not have an impact on
> the spread and usage of GnuPG in the EU for business purposes etc.

With that I mean the acceptance of GnuPG Signatures, compared to costly
eIDAS solutions.

Best regards
Stefan

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



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


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

It must be... With all the talk of "anonymous" keys I wanted to see if I
could create one with Kleopatra, especially since it says optional for
name.

On 5/20/2020 12:27 AM, Andrew Gallagher wrote:
>> On 20 May 2020, at 06:32, Mark <azbigdogs@gmx.com> wrote:
>>
>> Just to test this out I tried creating a new key in Kleopatra with no
>> name and then with just a single name and it would not let me do it. It
>> had to have a first and at least a last initial.
> This must be a Kleopatra limitation. I have successfully created IDs consisting of a single word using the gpg command line.
>
> Such a limitation would be user-hostile, as there are people in some cultures who have only one name, the Indonesian dictator Suharto being one famous example.
>
> A

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

Did a bit more experimenting with it.  You can have something only in
the first name field but it has to be a minimum of 5 characters and the
first one must be a letter. .. 

On 5/20/2020 3:16 PM, Mark wrote:
> It must be... With all the talk of "anonymous" keys I wanted to see if I
> could create one with Kleopatra, especially since it says optional for
> name.
>
> On 5/20/2020 12:27 AM, Andrew Gallagher wrote:
>>> On 20 May 2020, at 06:32, Mark <azbigdogs@gmx.com> wrote:
>>>
>>> Just to test this out I tried creating a new key in Kleopatra with no
>>> name and then with just a single name and it would not let me do it. It
>>> had to have a first and at least a last initial.
>> This must be a Kleopatra limitation. I have successfully created IDs consisting of a single word using the gpg command line.
>>
>> Such a limitation would be user-hostile, as there are people in some cultures who have only one name, the Indonesian dictator Suharto being one famous example.
>>
>> A
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

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

On Wed, May 20, 2020 at 03:27:28PM -0700, Mark wrote:
> Did a bit more experimenting with it.? You can have something only in
> the first name field but it has to be a minimum of 5 characters and the
> first one must be a letter. ..?

*sigh*
https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/

> On 5/20/2020 3:16 PM, Mark wrote:
> > It must be... With all the talk of "anonymous" keys I wanted to see if I
> > could create one with Kleopatra, especially since it says optional for
> > name.
> >
> > On 5/20/2020 12:27 AM, Andrew Gallagher wrote:
> >>> On 20 May 2020, at 06:32, Mark <azbigdogs@gmx.com> wrote:
> >>>
> >>> Just to test this out I tried creating a new key in Kleopatra with no
> >>> name and then with just a single name and it would not let me do it. It
> >>> had to have a first and at least a last initial.
> >> This must be a Kleopatra limitation. I have successfully created IDs consisting of a single word using the gpg command line.
> >>
> >> Such a limitation would be user-hostile, as there are people in some cultures who have only one name, the Indonesian dictator Suharto being one famous example.
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

--
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu

Mark wrote:
Hi,

> Did a bit more experimenting with it.? You can have something only in
> the first name field but it has to be a minimum of 5 characters and
> the first one must be a letter. ..

If you are familiar with GnuPG in command line mode you may try out
sequoia pgp, which I compiled a Windows binary for, so that you
can see how easy it is to have UID-less public keyblocks and how
to assign labels for such keys.

dkg once said IIRC 'less is more', not in this context but this
is what I love about sequoia pgp.

https://keybase.pub/stefan_claas/software/sequoia-pgp_Win64.zip

https://docs.sequoia-pgp.org/sq/index.html

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

Thanks I may take a look at it and just see what it does. I'm still VERY
much a novice in regards to all this so just trying to learn more. My
"experiment" with Kleopatra was just to see if I could since it said
"optional" for the name part. 

Sorry, not sure who dkg is but have seen those initials mentioned a few
times.


On 5/21/2020 7:30 AM, Stefan Claas wrote:
> Mark wrote:
> Hi,
>
>> Did a bit more experimenting with it.  You can have something only in
>> the first name field but it has to be a minimum of 5 characters and
>> the first one must be a letter. ..
> If you are familiar with GnuPG in command line mode you may try out
> sequoia pgp, which I compiled a Windows binary for, so that you
> can see how easy it is to have UID-less public keyblocks and how
> to assign labels for such keys.
>
> dkg once said IIRC 'less is more', not in this context but this
> is what I love about sequoia pgp.
>
> https://keybase.pub/stefan_claas/software/sequoia-pgp_Win64.zip
>
> https://docs.sequoia-pgp.org/sq/index.html
>
> Regards
> Stefan 
>

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

That is very true.? I have a friend whose first name is M'Lou and she's
had all kinds of issues when systems freak out over her first name.

On 5/21/2020 6:48 AM, Mark H. Wood via Gnupg-users wrote:
> On Wed, May 20, 2020 at 03:27:28PM -0700, Mark wrote:
>> Did a bit more experimenting with it.? You can have something only in
>> the first name field but it has to be a minimum of 5 characters and the
>> first one must be a letter. ..?
> *sigh*
> https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/
>
>> On 5/20/2020 3:16 PM, Mark wrote:
>>> It must be... With all the talk of "anonymous" keys I wanted to see if I
>>> could create one with Kleopatra, especially since it says optional for
>>> name.
>>>
>>> On 5/20/2020 12:27 AM, Andrew Gallagher wrote:
>>>>> On 20 May 2020, at 06:32, Mark <azbigdogs@gmx.com> wrote:
>>>>>
>>>>> Just to test this out I tried creating a new key in Kleopatra with no
>>>>> name and then with just a single name and it would not let me do it. It
>>>>> had to have a first and at least a last initial.
>>>> This must be a Kleopatra limitation. I have successfully created IDs consisting of a single word using the gpg command line.
>>>>
>>>> Such a limitation would be user-hostile, as there are people in some cultures who have only one name, the Indonesian dictator Suharto being one famous example.
>> _______________________________________________
>> Gnupg-users mailing list
>> Gnupg-users@gnupg.org
>> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

Mark wrote:

> Thanks I may take a look at it and just see what it does. I'm still
> VERY much a novice in regards to all this so just trying to learn
> more. My "experiment" with Kleopatra was just to see if I could since
> it said "optional" for the name part.?
>
> Sorry, not sure who dkg is but have seen those initials mentioned a
> few times.

Hi,

dkg stands for Daniel Kahn Gillmor. He is a highly respected member
in the GnuPG/OpenPGP scene and maintains GnuPG for the Linux Debian
OS.

He is also author of the Abuse-Resistant OpenPGP Keystores Internet
Draft and also author of the Stateless OpenPGP command line interface
framework.

If you do a Google look-up for him you can learn more about him.

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 Wed, 20 May 2020 19:11, Stefan Claas said:

> Curious as I am, did Mr Schönbohm never asked you why your public
> keyblock is not signed by Governikus?

I don't know a Mr. Schönbohm. I know Governikus and recently noticed
that their software does not even support the recommended set of
algorithm for ECC in S/MIME.

> https://keybase.io/stefan_claas

Mandating no user id and using a service which by design is the quite
the opposite of it ;-)


Salam-Shalom,

Werner

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

On Wed, 20 May 2020 15:16, Mark said:
> It must be... With all the talk of "anonymous" keys I wanted to see if I
> could create one with Kleopatra, especially since it says optional for
> name.

The name should indeed be optiona; If that has not been fixed in the
latest version, please file a bug.

GPG has always allowed to create a key with just a mail address:

--8<---------------cut here---------------start------------->8---
$ gpg --gen-key
Note: Use "gpg --full-generate-key" for a full featured key generation dialog.

GnuPG needs to construct a user ID to identify your key.

Real name:
Email address: foo@example.org
You selected this USER-ID:
"foo@example.org"

Change (N)ame, (E)mail, or (O)kay/(Q)uit? o
--8<---------------cut here---------------end--------------->8---

Or with the not anymore new quick command:

--8<---------------cut here---------------start------------->8---
$ gpg --quick-gen-key foo@example.org
About to create a key for:
"foo@example.org"

Continue? (Y/n)
--8<---------------cut here---------------end--------------->8---


Now, if you want to have the fingerprint as a User-ID, that needs a bit
of extra work: First create a key with some arbitrary user-id, then use
--edit-key to add a new User-ID containg the fingerprint, delete the
original User-ID, save, and publish the key. I do not suggest such user
IDs because they would only confuse users.


Shalom-Salam,

Werner

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

Werner Koch wrote:

> On Wed, 20 May 2020 19:11, Stefan Claas said:
>
> > Curious as I am, did Mr Sch?nbohm never asked you why your public
> > keyblock is not signed by Governikus?
>
> I don't know a Mr. Sch?nbohm. I know Governikus and recently noticed
> that their software does not even support the recommended set of
> algorithm for ECC in S/MIME.

Ok, I thought at least he knows you.

> > https://keybase.io/stefan_claas
>
> Mandating no user id and using a service which by design is the quite
> the opposite of it ;-)

Well, that is easy to explain. I use keybase for file storage (250 GB
per user) and for chatting there with friends or in teams with other
people. Nice free service IMHO.

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

> dkg stands for Daniel Kahn Gillmor. He is a highly respected member
> in the GnuPG/OpenPGP scene and maintains GnuPG for the Linux Debian
> OS.

He would prefer you refer to Debian as the GNU/Linux Debian OS. :)

dkg is also a genuinely pleasant person. I've met him a couple of times
at conferences. He's very nice. We need more kind people in the
community. :)

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