keys.openpgp.org not sending confirmation email
Binarus
lists at binarus.de
Tue Sep 17 14:57:27 CEST 2019
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, lists at binarus.de 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 <foo at example.org>"
>
> results in
>
> pub rsa3072 2019-09-17 [SC] [expires: 2021-09-16]
> D5A13F45AD29FAD517FEB157F29010625F3EDDDA
> uid foo, bar | baz <foo at example.org>
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
More information about the Gnupg-users
mailing list