At first, thank you very much for your explanations! On 17.09.2019 12:17, Werner Koch wrote: > On Tue, 17 Sep 2019 09:12, [email protected] said: > >> I am asking myself why Enigmail doesn't. I am not sure (and can't test >> at the moment) how GnuPG would behave if given a problematic name when >> generating a key; I hope it would give a warning or would add the > > gpg generates such a key just fine: > > gpg --quick-gen-key "foo, bar | baz <[email protected]>" > > results in > > pub rsa3072 2019-09-17 [SC] [expires: 2021-09-16] > D5A13F45AD29FAD517FEB157F29010625F3EDDDA > uid foo, bar | baz <[email protected]>
I really hope that I don't annoy anybody (being in no way an experienced user in this field and probably still missing many basics), but as far as I have understood my communication with Vincent, it's such IDs which are a problem for keys.openpgp.org. When I first used Enigmail to generate and upload a key with such an ID to keys.openpgp.org, I never got the confirmation email. When I uploaded that key using the web form (https://keys.openpgp.org/upload), it told me that it couldn't parse the key's ID as an email address. Consequently, it couldn't send a confirmation email, and the key, although having been stored on the server, could not be found when being searched for by mail address. > and gpg's internal mail-addr extraction function simply looks for the > left angle bracket to find the mail-address and then checks whether that > mail-addr is valid. Thank you very much for that insight. > The code also allows for a user-id consisting only > of the mail-addr without the angle brackets. This is the way I am going now. After the bad experience, I have decided to use only key IDs consisting solely of the actual mail address hereafter (with or without the angle brackets - I can live with both variants :-)). Enigmail refuses to generate such keys (it insists on entering a non-empty name and doesn't complete the key generation process otherwise). But I could easily generate such keys using the GnuPG command line interface. > The reason for this is > that this de-facto standard only resembles an rfc-822 address but is not > necessary valid. For example due to the utf-8 encoding. I see. Then the problem might be due to standards which are "only" de-facto, leading to parsers (on the key servers) which interpret those IDs subtly differently from what GnuPG / Enigmail and friends expect. By the way, I did not test yet how keys.openpgp.org would behave when given a key ID with a comma in the name, but with the name quoted. In every case, I am happy now, as long as IDs consisting only of the actual mail address remain allowed. Personally, I currently don't need to have my name or other fancy text in my keys' IDs. I suppose that somebody who wants to write me an encrypted message will search for my public key at first by email address (and not by other criteria). At least, I would do so ... Regards, and thanks again, Binarus _______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
