Mailing List Archive

> On 20 May 2020, at 18:51, LisToFacTor via Gnupg-users <gnupg-users@gnupg.org> wrote:
>
> Demanding a piece of information from someone who would prefer not
> to give it is equally user-hostile, especially so if he who demands
> it does so only because it is required by some internal mechanics
> of the system he constructed

“Demand” is a strong word that I don’t believe is justified here, and only serves to inflame the debate.

Most implementations of email require that you enter a “real name” of some kind. OpenPGP/GPG strongly encourage you to use the same real name on your key as you use on your email profile - this is for the benefit of your correspondents, since using different IDs will likely cause confusion. You are free to ignore this recommendation but I don’t think the documentation should encourage novices to do so.

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

On 5/20/20 6:52 PM, Andrew Gallagher wrote:
>
>> On 20 May 2020, at 18:51, LisToFacTor via Gnupg-users <gnupg-users@gnupg.org> wrote:
>>
>> Demanding a piece of information from someone who would prefer not
>> to give it is equally user-hostile, especially so if he who demands
>> it does so only because it is required by some internal mechanics
>> of the system he constructed
>
> “Demand” is a strong word that I don’t believe is justified here, and only serves to inflame the debate.
>
> Most implementations of email require that you enter a “real name” of some kind. OpenPGP/GPG strongly encourage you to use the same real name on your key as you use on your email profile - this is for the benefit of your correspondents, since using different IDs will likely cause confusion. You are free to ignore this recommendation but I don’t think the documentation should encourage novices to do so.
English is not my native tongue, and the word I've chosen is based
on my interpretation of the dialog presented by the program when
generating the key:

> GnuPG needs to construct a user ID to identify your key.
> that the Old Guard (somebody
used the term in one of the previous posts) just can't even

> Real name:
upon entering an empty string, the response is:
...
> gpg: [internal]: no User-ID specified
(and the program quits with no further explanation)

To me, this appears to qualify as a demand for user's "Real name".

It is not up to a program designer to decide that it is mandatory for
a user to provide a piece of personally identifiable information
because "this is for the benefit of your correspondents, since using
different IDs will likely cause confusion." User is the one to decide
what personally identifiable information to provide, when and to whom.

And if the is demand for such information is refused, and the service
is summarily denied, (as outlined above) then it is not okay for the
program designer to wash his hands with "...so why didn't you just
invent something...".

Of course, it would be a one-minute job to change the prompt to
"enter a “real name” of some kind..." (or something to that effect,
better formulated). But with that, the whole "Web of Trust" structure
would collapse, and that is something to horrible to even
contemplate.

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

On Donnerstag, 21. Mai 2020 00:14:40 CEST LisToFacTor via Gnupg-users wrote:
> English is not my native tongue, and the word I've chosen is based
> on my interpretation of the dialog presented by the program when
> generating the key:
>
> > GnuPG needs to construct a user ID to identify your key.
> >
> > Real name:
> upon entering an empty string, the response is:
> ...
>
> > gpg: [internal]: no User-ID specified
>
> (and the program quits with no further explanation)
>
> To me, this appears to qualify as a demand for user's "Real name".

I suppose you also entered an empty string for "Email address":
```
$ gpg --gen-key
Note: Use "gpg2 --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:
You selected this USER-ID:
""

Change (N)ame, (E)mail, or (O)kay/(Q)uit? o
gpg: [internal]: no User-ID specified
```

Generating a key with empty "Real name" and non-empty "Email address" (and
vice versa) works:
```
$ gpg --gen-key
Note: Use "gpg2 --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.com
You selected this USER-ID:
"foo@example.com"

Change (N)ame, (E)mail, or (O)kay/(Q)uit? o
[...]
```
A key with above User-ID is generated.

I agree that there could be a more user-friendly error message than "gpg:
[internal]: no User-ID specified". In particular, it makes little sense to ask
the user if everything is okay if the empty values the user entered do not
result in a valid User-ID.

Regards,
Ingo




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

On 5/21/20 10:52 AM, Ingo Klöcker - kloecker@kde.org wrote:
> On Donnerstag, 21. Mai 2020 00:14:40 CEST LisToFacTor via Gnupg-users wrote:
> I suppose you also entered an empty string for "Email address":
> `` > Real name:
> Email address: foo@example.com
> You selected this USER-ID:
> "foo@example.com"
>
> Change (N)ame, (E)mail, or (O)kay/(Q)uit? o
> [...]
> ```
> A key with above User-ID is generated.
You are correct, the e-mail address was likewise an empty string.

First, let me mention that Web of Trust is to me not a useful public
key verification mechanism, as it is compromises my privacy. I use
other methods to make it possible for my correspondents to verify
the key.

I do not have a/one e-mail address either. At any point in time,
I might be using any number of addresses, depending on who I'm
communicating with, and none of those addresses is likely to
remain in use as long as the key I am generating. None of such
e-mail correspondents would have any idea whatsoever what to do
with a gpg-encrypted message received from me anyways. On the
other hand, for the exchange of personal and confidential messages,
I do not use the "conventional" e-mail at all - the encrypted
text is exchanged by other means, of which there are myriad.

I do know I could have given my name as "Peter P. Pumpkineater"
and the e-mail address as "peter.p.pumpkineater@example.com"
and the program would generate the key-pair for me. But the
question begs: is inventing false information the proper way
of preventing the leakage of personally identifiable information,
completely unnecessarily, via programs constructed by system
architects whose thinking about the privacy is stuck in the time
long behind us?

The proper thing for gpg program to do would be to allow the
personally identifiable information in the key to be optional,
and to warn the user generating such key that he will not be able
to participate in the Web of Trust. Wouldn't that be a better
system design than demanding the user to provide the false
information and treating such information as valid? Especially
as one would not be able to participate in the Web of Trust as
"Peter P. Pumpkineater", but there is no way for a program to
issue any warning for that?

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

On 21/05/2020 14:34, LisToFacTor via Gnupg-users wrote:
>> The proper thing for gpg program to do would be to allow the
> personally identifiable information in the key to be optional,
> and to warn the user generating such key that he will not be able
> to participate in the Web of Trust.

I think you're getting overly hung up on the web of trust. The contents
of the User ID are independent of the WoT - they exist to tell your
email program which keys belong to which correspondents. You can use a
WoT with keys that have no email addresses in them, so long as the
verification chain is cryptographically valid and you have the
appropriate settings in your trustdb. Your WoT could be made up of
Donald Duck, Mickey Mouse and Goofy - the only time the UID's contents
become important (as opposed to its certifications) is when you want to
send an email to president@whitehouse.gov you should have a valid key
that has "president@whitehouse.gov" in either its User ID or local alias
(as RJH pointed out above).

--
Andrew Gallagher

> First, let me mention that Web of Trust is to me not a useful public
> key verification mechanism, as it is compromises my privacy.

Only if your sigs are exportable. Local sigs are a perfectly legitimate
way to use the WoT. If Alice locally signs Bob's certificate and sets
Bob up as a trusted introducer, Alice can benefit from Bob vouching for
Charlotte's certificate without revealing her identity to Charlotte --
or even the fact that she (Alice) even exists.

> But the question begs: is inventing false information the proper way
> of preventing the leakage of personally identifiable information,
> completely unnecessarily, via programs constructed by system
> architects whose thinking about the privacy is stuck in the time long
> behind us?

The question is irrelevant. OpenPGP allows you to use true identity
information, false information, or true information about a persona, or
false information about a persona, or a recipe for a nice habanero
salsa. Do what's right for you, and understand that what's right for
you may well be different from what's right for others.

(Saute two thinly-sliced cloves of garlic in a little oil for a few
minutes until they start releasing the garlicky goodness. Add a pinch
of ground cumin; saute another minute. Add 500g finely-diced tomatoes
and their juices, one habanero finely-diced, cook over low heat for ten
minutes stirring constantly. Once the tomatoes and peppers are
well-cooked, pour into a blender or food processor. Add cilantro and
the juice of one lime, puree the mixture, pour into a bowl. Decorate
with lime slices. And here you thought this mailing list was only good
for nerd stuff...)

> The proper thing for gpg program to do would be to allow the
> personally identifiable information in the key to be optional,

It already is.

> and to warn the user generating such key that he will not be able to
> participate in the Web of Trust.

But they can.

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

Robert J. Hansen wrote:

> > First, let me mention that Web of Trust is to me not a useful
> > public key verification mechanism, as it is compromises my privacy.
>
> Only if your sigs are exportable. Local sigs are a perfectly
> legitimate way to use the WoT. If Alice locally signs Bob's
> certificate and sets Bob up as a trusted introducer, Alice can
> benefit from Bob vouching for Charlotte's certificate without
> revealing her identity to Charlotte -- or even the fact that she
> (Alice) even exists.
>
> > But the question begs: is inventing false information the proper
> > way of preventing the leakage of personally identifiable
> > information, completely unnecessarily, via programs constructed by
> > system architects whose thinking about the privacy is stuck in the
> > time long behind us?
>
> The question is irrelevant. OpenPGP allows you to use true identity
> information, false information, or true information about a persona,
> or false information about a persona, or a recipe for a nice habanero
> salsa. Do what's right for you, and understand that what's right for
> you may well be different from what's right for others.
>
> (Saute two thinly-sliced cloves of garlic in a little oil for a few
> minutes until they start releasing the garlicky goodness. Add a pinch
> of ground cumin; saute another minute. Add 500g finely-diced tomatoes
> and their juices, one habanero finely-diced, cook over low heat for
> ten minutes stirring constantly. Once the tomatoes and peppers are
> well-cooked, pour into a blender or food processor. Add cilantro and
> the juice of one lime, puree the mixture, pour into a bowl. Decorate
> with lime slices. And here you thought this mailing list was only
> good for nerd stuff...)
>
> > The proper thing for gpg program to do would be to allow the
> > personally identifiable information in the key to be optional,
>
> It already is.
>
> > and to warn the user generating such key that he will not be able to
> > participate in the Web of Trust.
>
> But they can.

I miss dkg here on the ML ...

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

Given the number of people that still manage to create (and distribute)
their keys with glaring mistakes, such as misspelling their own domain
name/tld, or providing a key which doesn't match their email address.

Too many people is sending and receiving openpgp emails by actually
encrypting the content on a separate application, then pasting it on
their MUA (often resulting in the openpgp armor contained in a html/text
block! ?). Which then leads to the occasional mistake of the wrong key
being manually chosen.

People should *really* use a MUA supporting OpenPGP if they are going to
send or receive OpenPGP emails. It's a big mistake that end users think
it's normal to process that separately.


I don't think relaxing the current uid validation would help with that.
Quite the opposite.

The stated issue could be solved, while keeping rfc4880 conformance, by
adding a skip path on the key creation:

> You have chosen not to provide a uid to the new key. It is recommended
> to add an identifier. A key specifying no email address will be
> severely limited if it is going to be used to send or receive mail, as
> it won't be linked with that account.
>
> If not providing a uid, usage of this key will have to be done using
> the user-unfriendly key fingerprint. By continuing with no explicit
> uid, GnuPG will automatically fill the uid field with the key
> fingerprint A1786ADB27E946D5DC1B5A989EED09D63FCD9AB7
>
>
> Do you want to create such a key anyway? [y/N]


I still wonder if it's worth adding that code for this limited use case,
though.



On 2020-05-21 at 15:32 +0100, Andrew Gallagher wrote:
> you should have a valid key
> that has "president@whitehouse.gov" in either its User ID or local
> alias (as RJH pointed out above).

Note you may need to set your alias for "<president@whitehouse.gov>",
not "president@whitehouse.gov". It will depend on how is gnupg called by
the MUA.


Best regards


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

Robert,

Hi and thanks for the reply. Salsa is cooking. And since you
are so kind:

It would help a whole lot if GPG included some authoritative
documentation on how to use the program in the following scenario:

- The trust in the correspondent's public key is established only
by comparing the key fingerprint derived programmatically from the
locally stored key-file and a copy independently obtained from
the owner. The only identification of a public key is its fingerprint.
Since the public key is either known to an adversary, or it is very
hard to guard against such eventuality, the public key itself should
not provide the adversary with any useful information.

- All gpg operations (key generation, encryption, decryption) are
carried out on a device not connected to the Internet.

- There is no e-mail. (It's not just "resting", it is DEAD).

It would really, really help.

p.s.
Out-of-channel fingerprint dissemination and exchange of ciphertext
without the benefit of the e-mail system has been dealt with, so
there is no need at all to address that.



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

> - The trust in the correspondent's public key is established only
> by comparing the key fingerprint derived programmatically from the
> locally stored key-file and a copy independently obtained from
> the owner. The only identification of a public key is its fingerprint.
> Since the public key is either known to an adversary, or it is very
> hard to guard against such eventuality, the public key itself should
> not provide the adversary with any useful information.

Okay, but this seems largely redundant with section 8.12 of the FAQ,
which, uh ... does exactly this. What exactly are you objecting to?

=====

8.12 How do I use another person’s certificate?

In order to send an encrypted message or verify a signature, you must
obtain the certificate for the recipient’s/signer’s public key.

Occasionally you might obtain the certificate physically, by meeting the
certificate holder face-to-face and exchanging the certificate on some
storage medium such as a USB stick, memory card, or portable disk. Or
you might download a copy of the certificate from the holder’s web site.

Once obtained in one of these ways, you can add the certificate to your
collection of public keys by doing:

gpg --import certificate.txt

More commonly, you’ll download a correspondent’s certificate from a
keyserver.

[snip keyserver instructions]

*Why do I need to validate certificates?*

If you were to receive a letter in the mail that claimed to be from the
President of the United States, would you believe it? Probably not,
because anyone can put together official-looking letterhead: you’d
insist on doing some kind of checking to make sure that no one was
fooling with you.

The same applies to email. A certificate can claim to be from anyone.
You have to make sure that the certificate really belongs to whom it
claims it belongs to. That process of making sure is called ‘validation’.

*How do I validate certificates?*

This advice is controversial.

It’s controversial for a simple reason: every Tom, Dick and Harry has
their own idea about the “right way” to validate certificates. Some of
these people are well-informed and some of them are just plain unhinged.
In the end, you are responsible for making your own decisions. That
said, the following is generally agreed upon as being a reasonable
procedure:

1. Meet the certificate holder face-to-face.
2. Ask to see two forms of government-issued identification.
3. Upon verifying the person really is who they claim to be, ask
this person to provide their certificate’s fingerprint, their email
address, and where you can obtain a copy of their certificate. (Example:
“My fingerprint is 4541 BB01 8EA4 8F99 19CA 3701 2380 6BE5 D6B9 8E10,
and you can find it on pool.sks-keyservers.net.”)
4. On your own computer, retrieve the person’s certificate from the
specified location. Check to make sure the email address they gave you
is one that’s also listed on the certificate. Check to make sure the
fingerprint of the certificate you’ve downloaded matches the fingerprint
the person gave you.
5. gpg --edit-key [their certificate ID] sign
6. Once signed, gpg --armor --output signed_cert.asc --export [their
certificate ID]
7. Send the file signed_cert.asc to the address they gave you

By following this process you first ensure that you’re speaking to the
right person. By comparing the fingerprints of the certificate you have
against the fingerprint they specified, you’re ensuring that you have
the right certificate. Checking to make sure the email address they gave
you is also listed on the certificate is one more check to make sure.
Once that’s done, presto, Bob’s your uncle: there’s nothing left to do
except sign it and return the newly-signed certificate to the other person.

=====

I mean, this seems like 95% of what you want. You just want the
reference to an email address in step 4 removed?

If you can get the community to agree, I'm all in favor.

> - All gpg operations (key generation, encryption, decryption) are
> carried out on a device not connected to the Internet.

The FAQ covers both online and offline use.

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

Robert J. Hansen wrote:

> > - The trust in the correspondent's public key is established only
> > by comparing the key fingerprint derived programmatically from the
> > locally stored key-file and a copy independently obtained from
> > the owner. The only identification of a public key is its
> > fingerprint. Since the public key is either known to an adversary,
> > or it is very hard to guard against such eventuality, the public
> > key itself should not provide the adversary with any useful
> > information.
>
> Okay, but this seems largely redundant with section 8.12 of the FAQ,
> which, uh ... does exactly this. What exactly are you objecting to?

[...]

I think that many people have multiple email accounts and would like
to see a way to have a procedure in place with GnuPG that would allow
them to use such a public key, with only one UID (or none), covered in
the FAQ.

The problem is that we IMHO still stick to procedures Mr Zimmermann,
while not being a cryptographer back then, has invented in the early
90s, which may no longer fit in 2020.

It should be also pointed out, to the interested reader, that 99% of
public key crypto software, I am aware of, does not require an email
address, a UID, to manage public keys (in a key ring).

Regards
Stefan

--
https://keybase.io/stefan_claas


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

On 2020-05-23 at 12:30 -0400, Robert J. Hansen wrote:
> > - The trust in the correspondent's public key is established only
> > by comparing the key fingerprint derived programmatically from the
> > locally stored key-file and a copy independently obtained from
> > the owner. The only identification of a public key is its fingerprint.
> > Since the public key is either known to an adversary, or it is very
> > hard to guard against such eventuality, the public key itself should
> > not provide the adversary with any useful information.
>
> Okay, but this seems largely redundant with section 8.12 of the FAQ,

Handy link to the FAQ:
https://gnupg.org/faq/gnupg-faq.html#using_certificates



I see a big hole in the validation part. The steps providex are
validating the offline identity but not matching it to the certificate
uid.

> *How do I validate certificates?*
>
> This advice is controversial.
>
> It’s controversial for a simple reason: every Tom, Dick and Harry has
> their own idea about the “right way” to validate certificates. Some of
> these people are well-informed and some of them are just plain unhinged.
> In the end, you are responsible for making your own decisions. That
> said, the following is generally agreed upon as being a reasonable
> procedure:
>
> 1. Meet the certificate holder face-to-face.
I meet Rob, face-to-face

> 2. Ask to see two forms of government-issued identification.
He shows me two ids that I consider acceptable

> 3. Upon verifying the person really is who they claim to be, ask
> this person to provide their certificate’s fingerprint, their email
> address, and where you can obtain a copy of their certificate.

He gives me his email address <donaldtrump@sixdemonbag.org>, its
certificate fingerprint and place to download (WKD).



> 4. On your own computer, retrieve the person’s certificate from the
> specified location. Check to make sure the email address they gave you
> is one that’s also listed on the certificate. Check to make sure the
> fingerprint of the certificate you’ve downloaded matches the fingerprint
> the person gave you.

I download the certificate, I verify that it has the provided
fingerprint and that the provided email address does appear on the
certificate: “Donald Trump <donaldtrump@sixdemonbag.org>”


> 5. gpg --edit-key [their certificate ID] sign
> 6. Once signed, gpg --armor --output signed_cert.asc --export [their
> certificate ID]
> 7. Send the file signed_cert.asc to the address they gave you

I sign the certificate, and send it to donaldtrump@sixdemonbag.org, so
he can share my signature attesting his identity.


> By following this process you first ensure that you’re speaking to the
> right person. By comparing the fingerprints of the certificate you have
> against the fingerprint they specified, you’re ensuring that you have
> the right certificate. Checking to make sure the email address they gave
> you is also listed on the certificate is one more check to make sure.
> Once that’s done, presto, Bob’s your uncle: there’s nothing left to do
> except sign it and return the newly-signed certificate to the other person.


And yet, I find something unsettling about that key with a Donald Trump
name just by meeting Rob Hansen face-to-face ;)


I would _probably_ keep some records somewhere that I had signed that
key based on meeting a certain Robert Hansen, but that actually means
keeping your own out-of-keyring identity map.
There might be an unwritten assumption that the name must match, too.
But in that case it should be explicit


It's also not clear what should be there. Consensus seem to be that
there must be _some_ kind of loose matching. Maybe, but for Robert
Hansen vouching for that certificate, the identity might be
* Robert J. Hansen
* Robert Hansen
* Rob Hansen
* Rob J. Hansen
* rjh


And he's far from being the only Robert Hansen, anyway:
https://en.wikipedia.org/wiki/Robert_Hansen_(disambiguation)


Nonetheless, a name of ‘Donald Trump’ should probably not be accepted,
unless he is the name he goes by in certain circles.

(In fact, on [some] common law jurisdictions, it is possible to change
your name just by asking to be called that way)


Another scenario would be an identity where only an email was provided,
although in that case, it's not clear why you would want a
government-issued identification. You only need an attestation that the
key is owned by the mailbox owner.

It is already quite long, but I think this part should be expanded to
explain about how to treat the names in the certificates.


I'd also clarify that 7 is optional, and you don't *need* to send your
signature to the other party. This is actually much easily fixed.

Best regards



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

> I see a big hole in the validation part. The steps providex are
> validating the offline identity but not matching it to the certificate
> uid.

Correct, and that's by design.

There is no -- *NO* -- generally understood meaning for user IDs beyond
"the name here is a meaningful term of address for an individual or
individuals who control this email address".

Many years ago I was in Germany and tried to persuade a friend of mine
to do the hard right thing as opposed to the easy wrong thing. She
rolled her eyes at me and declared "du bist Rob, der Ritter". ("You're
Rob, the knight.") She was attempting to be sarcastic. Bystanders
misheard her as "du bist ein Raubritter" and a new nickname for me was
born.[1]

So let's say I give you my ID and you're one of these people who knows
me as Raubritter. Would you sign raubritter@sixdemonbag.org? Probably.
Should you? Sure, why not? You know there's a specific person, me,
who answers that email address and you know exactly who I am in the eyes
of the law, thanks to seeing my ID.

So why shouldn't you sign a pseudonym, if you know the pseudonym maps to
an individual person? And if you're going to sign a pseudonym, why not
sign donald_trump@sixdemonbag.org if you happen to know there's a person
or persons at that domain which answer to that name?



[1] This was thirty years ago. Words tend to change their cultural and
slang meanings over the years. I don't know what the current
implications of "Raubritter" are, and for that reason I don't use it or
advertise it to others... but yeah, there are people who have known me
for thirty years who still call me that.

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

On 5/23/20 4:30 PM, Robert J. Hansen wrote:
>
> I mean, this seems like 95% of what you want. You just want the
> reference to an email address in step 4 removed?
>
> If you can get the community to agree, I'm all in favor.
>
>> - All gpg operations (key generation, encryption, decryption) are
>> carried out on a device not connected to the Internet.
>
> The FAQ covers both online and offline use.

I maintain two short internal documents on "WOT-less" and
"e-mail-less" off-line gpg use: one can be thought as "tutorial"
the other as "reference". When I get some free time I'll merge
them, remove group-specific stuff and post in a new thread.

Would that be okay?

Would that be worthwhile?


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

On 2020-05-24 at 00:14 -0400, Robert J. Hansen wrote:
> > I see a big hole in the validation part. The steps providex are
> > validating the offline identity but not matching it to the certificate
> > uid.
>
> Correct, and that's by design.
>
> There is no -- *NO* -- generally understood meaning for user IDs beyond
> "the name here is a meaningful term of address for an individual or
> individuals who control this email address".
>
> Many years ago I was in Germany and tried to persuade a friend of mine
> to do the hard right thing as opposed to the easy wrong thing. She
> rolled her eyes at me and declared "du bist Rob, der Ritter". ("You're
> Rob, the knight.") She was attempting to be sarcastic. Bystanders
> misheard her as "du bist ein Raubritter" and a new nickname for me was
> born.[1]
>
> So let's say I give you my ID and you're one of these people who knows
> me as Raubritter. Would you sign raubritter@sixdemonbag.org? Probably.
> Should you? Sure, why not? You know there's a specific person, me,
> who answers that email address and you know exactly who I am in the eyes
> of the law, thanks to seeing my ID.
>
> So why shouldn't you sign a pseudonym, if you know the pseudonym maps to
> an individual person? And if you're going to sign a pseudonym, why not
> sign donald_trump@sixdemonbag.org if you happen to know there's a person
> or persons at that domain which answer to that name?
>
>
>
> [1] This was thirty years ago. Words tend to change their cultural and
> slang meanings over the years. I don't know what the current
> implications of "Raubritter" are, and for that reason I don't use it or
> advertise it to others... but yeah, there are people who have known me
> for thirty years who still call me that.

I tried to cover that with
> unless it is the name he goes by in certain circles

The point is, if I met you as Raubritter, a government-issued id showing
a different name is unlikely to help.

Similarly, I remember a blog post written by Skud during the Nym wars,
where it was mentioned that being presented in conferences under the
legal name ‘Kirrily Robert’ tended to cause confusion. [1]


Of course, this leads to question if it would ever help to see such id.
I do think it can be helpful. There are cases where the other party is
known to use their legal name. Seeing an official id, and assuming it is
a legit one (would you correctly detect a fake id? even from a foreign
country?), doesn't stop that an impostor could appear with a valid id on
that name (just like dealing with stripe doesn't mean it's the company
you really mean to [2], or you could live on many Bostons), but it
should restrict the odds somehow, by filtering the possibilities.
Remember, if we know the legal name beforehand (e.g. when verifying a
university email address, a tenured professor is unlikely _not_ to be
using their legal name, although publishing means that naming in
academia isn't straightforward either [3])

For online identities, a TOFU approach would probably work better. You
would want to link the identity with its good or bad interactions to the
cryptographic identity, regardless if who makes them is named Rob or
Dogbert.


For people you personally know -whatever the name-, you are probably
comfortable signing whatever name they used on their key, that's likely
how you know them and you may remember them.

However, that doesn't help much if you wanted t benefit from the WoT, as
the naming gets messy adding intermediate nodes between people.


Also, there are too many meanings given to a key signature. I would like
to have a standard set of notations with common meanings, so (in some
subset) we could all agree on what was meant.


Now, this is all quite complex to properly explain in a small FAQ entry,
focused to new users, and still be understood, I'm afraid.



Best regards




PS: I am no German speaker, so I have no idea what Raubritters are. Or
what would that term be used for 30 years ago, fwiw.



1- That site has fallen out of the internet and took a while to dig it
out, but I finally found it at
https://web.archive.org/web/20111115190646/http://infotrope.net/bio/my-name/
for the background on the why for that page see
https://web.archive.org/web/20121213001724/http://infotrope.net/2011/07/22/ive-been-suspended-from-google-plus/
2- https://scotthelme.co.uk/the-power-to-revoke-lies-with-the-ca/
3- https://academia.stackexchange.com/questions/tagged/personal-name


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

> The point is, if I met you as Raubritter, a government-issued id showing
> a different name is unlikely to help.

I refer you back to the part of the FAQ which says the certificate
signing process is controversial because every Tom, Dick, and Harry has
their own idea on how to do it.

If you can convince the list that the FAQ needs updating, I'll update
it. But otherwise, I'm going to consider this yet another opinion on
what the right thing to do is, and although I certainly think it's on
topic for the list, I'm not going to consider changing the FAQ until and
unless there's buy-in from others. :)

> PS: I am no German speaker, so I have no idea what Raubritters are. Or
> what would that term be used for 30 years ago, fwiw.

Nabokov once said that translations were like women: the beautiful ones
weren't faithful, and the faithful ones weren't beautiful.

Literally, "raubritter" means "robber-knight" and historically refers to
minor nobility in the medieval period who extorted money out of anyone
they could. In English literature, these figures are normally called
"black knights".

Use whichever meaning you want. :)

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

> Would that be okay?
>
> Would that be worthwhile?

By all means, go for it! And if you can get the community to say "yeah,
that's a good idea" I'll happily merge 'em in.

I know I keep on saying "if the community wants it...". That's the hard
and fast rule for the FAQ: it represents the consensus of the community.
I'm the FAQ custodian more than I am the FAQ author.

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

On 2020-05-25 at 03:13 -0400, Robert J. Hansen wrote:
> If you can convince the list that the FAQ needs updating, I'll update
> it. But otherwise, I'm going to consider this yet another opinion on
> what the right thing to do is, and although I certainly think it's on
> topic for the list, I'm not going to consider changing the FAQ until and
> unless there's buy-in from others. :)


I do think the FAQ could benefit from an update. However, I do not claim
to know which would the right words to put there.
There are some ideas on my previous mails. I hoped that could spark some
discussion, but they are not near a proposal. That's a tougher task :)

Maybe by giving it enough time I might come up with something to work
with, far from perfect, but some draft to built upon.





> Nabokov once said that translations were like women: the beautiful ones
> weren't faithful, and the faithful ones weren't beautiful.
>
> Literally, "raubritter" means "robber-knight" and historically refers to
> minor nobility in the medieval period who extorted money out of anyone
> they could. In English literature, these figures are normally called
> "black knights".

Thanks for the insight!


Best

?ngel


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