Mailing List Archive

keys.openpgp.org not sending confirmation email
Dear all,

at first, thank you very much for providing privacy and safety for such
a long time free of charge to us!

Second, the following question could be slightly off-topic because it is
partly about the behavior of a key server which clearly is not part of
the GPG software. However, I think I have done something bad to my
Gpg4Win configuration, so I hope I don't get flamed.

I have used the Thunderbird / Enigmail / Gpg4Win troika for quite a
while without any issue. Yesterday, I had to reinstall, and while doing
so, upgraded to the newest versions of that packages, and while I was at
it, revoked my old (1024-bit) keys and generated new (4096-bit) ones
(using Enigmail's key management).

So I got four new key pairs, each of them associated with exactly one
email address. I uploaded the four public keys, again using Enigmail's
key management, to Enigmail's default key server, keys.openpgp.org.
Enigmail reported success each time.

I got confirmation emails for three of that four keys, but it seems that
the key server isn't in the mood to send a confirmation email for the
fourth. I have uploaded that one multiple times since then (again via
Enigmail's key management), each time getting a success message, but
still getting no confirmation email.

I am absolutely sure that this isn't some spam-filter-related issue or
similar. I had a look onto what the MX for the email address in question
was logging when uploading the key. I did this several times, and each
time I watched the logs at least for five minutes after having uploaded
the key. No email message from the key server arrived.

I have carefully checked multiple times that there is no typo in the
email address which is associated with the key in question.

And as expected, when searching for the first three keys on that key
server, they are found, while the fourth is not found.

Now I fear I have done something silly to the Gpg4Win settings (although
I haven't changed its configuration by intention), and I hope that
somebody could explain what could have gone wrong here.

I have quite a good idea of how PGP encryption works in general, but I
never (until now) have used GPG's command line interface (just hadn't to
do so because Enigmail did its job quite good), so it would be nice if
the issue could be explained in simple words :-)

Thank you very much in advance,

Binarus

P.S. If it would help, I wouldn't have a problem with publishing the
email address and the public key in question here.

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: keys.openpgp.org not sending confirmation email [ In reply to ]
Hi Binarus,

> I got confirmation emails for three of that four keys, but it seems that
> the key server isn't in the mood to send a confirmation email for the
> fourth. I have uploaded that one multiple times since then (again via
> Enigmail's key management), each time getting a success message, but
> still getting no confirmation email.

keys.openpgp.org admin here! Can you please contact support@keys.openpgp.org
from the address in question? I'll try to help you from there, if we tried to
deliver mails there will surely be something in the logs or bounces.

Cheers

- V

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: keys.openpgp.org not sending confirmation email [ In reply to ]
Dear Vincent,

On 14.09.2019 14:58, Vincent Breitmoser wrote:

>> I got confirmation emails for three of that four keys, but it seems that
>> the key server isn't in the mood to send a confirmation email for the
>> fourth. I have uploaded that one multiple times since then (again via
>> Enigmail's key management), each time getting a success message, but
>> still getting no confirmation email.
>
> keys.openpgp.org admin here! Can you please contact support@keys.openpgp.org
> from the address in question? I'll try to help you from there, if we tried to
> deliver mails there will surely be something in the logs or bounces.
>

Thank you very much for your fast reply!

I have sent an email from the address in question to
support@keys.openpgp.org as you have advised. I am looking forward to
what (silly thing) I have done wrong ...

Again, thank you very much for your support and time.

Regards,

Binarus

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: keys.openpgp.org not sending confirmation email [ In reply to ]
On 14.09.2019 13:15, Binarus wrote:
> I have used the Thunderbird / Enigmail / Gpg4Win troika for quite a
> while without any issue. Yesterday, I had to reinstall, and while doing
> so, upgraded to the newest versions of that packages, and while I was at
> it, revoked my old (1024-bit) keys and generated new (4096-bit) ones
> (using Enigmail's key management).
>
> So I got four new key pairs, each of them associated with exactly one
> email address. I uploaded the four public keys, again using Enigmail's
> key management, to Enigmail's default key server, keys.openpgp.org.
> Enigmail reported success each time.
>
> I got confirmation emails for three of that four keys, but it seems that
> the key server isn't in the mood to send a confirmation email for the
> fourth. I have uploaded that one multiple times since then (again via
> Enigmail's key management), each time getting a success message, but
> still getting no confirmation email.

The issue is solved now. I am documenting the solution for people who
are affected by the same problem and find this thread when searching.

Credits go to Vincent Breitmoser who has confirmed my own suspicion and
who was very helpful and fast with his support.

The point is that the key server failed to parse the key's ID as an
email address. The ID had the following structure (not the real ID, just
to make clear the structure):

Surname, Forename | Company <email@company.de>

Commas are not allowed as part of email addresses. While I knew that, I
made the wrong assumption that only the part between the brackets would
be considered the email address, and that I could use any characters for
the "name" part (expect brackets, of course ...).

Obviously, I was wrong, and the name part must obey the same rules as
the actual email address.

Vincent has told me that a certain number of other people had the same
problem, so they are thinking of making their parsers less strict, as
far as it concerns the name part. After my correspondence with him, I
think that they will be quite fast in implementing the changes.

However, I recommend everybody to make their whole key ID match the
rules for email addresses if they intend to upload it to a key server.

Personally, I have revoked all four of the new keys and generated new
ones with the ID being only the email address without a name part. While
this was not possible using Enigmail (because Enigmail insisted that I
had to add a name to the key), it was very easy by using gpg directly on
the command line (by the way, its documentation is quite good).

As a last tip, keys.openpgp.org offers to upload a public key directly.
When you do that, it will emit helpful messages in case of failure. In
my case, with the problematic key / ID, it clearly told the the ID could
not be parsed as an email address.

Unfortunately, I didn't know about the direct upload offer before asking
here ...

Regards, and thanks again,

Binarus


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: keys.openpgp.org not sending confirmation email [ In reply to ]
On Mon, Sep 16, 2019, Binarus wrote:

> Surname, Forename | Company <email@company.de>

> Commas are not allowed as part of email addresses. While I knew that, I

unless quoted, e.g.,
"Surname, Forename | Company" <email@company.de>


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: keys.openpgp.org not sending confirmation email [ In reply to ]
On 16.09.2019 12:58, Claus Assmann wrote:
> On Mon, Sep 16, 2019, Binarus wrote:
>
>> Surname, Forename | Company <email@company.de>
>
>> Commas are not allowed as part of email addresses. While I knew that, I
>
> unless quoted, e.g.,
> "Surname, Forename | Company" <email@company.de>

Thanks, Claus, for the clarification / correction, and for your continuous support and expertise.

Additionally, I just did a quick test. Using Thunderbird, I sent two messages to somebody else, one from an account where the name contained a comma and another one from an account where the name only contained [a-zA-Z] and spaces. Interestingly enough, Thunderbird did its thing right, at least in generating the "FROM:" line. It wrapped the name in quotes in the first case and left away the quotes in the second case. In other words, the receiver got two messages with "FROM:" lines which were formatted differently:

FROM: "Surname, Forename | Company" <email@company.de>
FROM: Forename Surname <email@company.de>

So Thunderbird seems to add the quotes automatically if necessary, and 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 quotes automatically.

From a quick glance at the web API (VKS interface) and at the HKP implementation of keys.openpgp.org, I got the impression that there isn't a status code or return value from which tools like Enigmail could see that there was a problem with parsing a key's ID. Perhaps the extended status codes in the HKP protocol could be used to return that sort of error, but even that is questionable, and I guess that this is not implemented anywhere.

In other words, the key server currently is not able to report such errors when a key is being uploaded via HKP or the web API. Am I correct here? If yes, should we consider this a design flaw in these key server APIs? After all, tools like Enigmail then wouldn't have the chance to report such errors to the user when trying to upload a key. Vincent, could you eventually elaborate a bit on that problem?

If we only would be able to read every RFC which affects any software we use for our daily work ...

Regards,

Binarus

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: keys.openpgp.org not sending confirmation email [ In reply to ]
On Tue, 17 Sep 2019 09:12, lists@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@example.org>"

results in

pub rsa3072 2019-09-17 [SC] [expires: 2021-09-16]
D5A13F45AD29FAD517FEB157F29010625F3EDDDA
uid foo, bar | baz <foo@example.org>

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. The code also allows for a user-id consisting only
of the mail-addr without the angle brackets. 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.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: keys.openpgp.org not sending confirmation email [ In reply to ]
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@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@example.org>"
>
> results in
>
> pub rsa3072 2019-09-17 [SC] [expires: 2021-09-16]
> D5A13F45AD29FAD517FEB157F29010625F3EDDDA
> uid foo, bar | baz <foo@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

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: keys.openpgp.org not sending confirmation email [ In reply to ]
> but as far as I have understood my communication with Vincent, it's such IDs
> which are a problem for keys.openpgp.org.

Right, that's because we currently use an actual rfc2822 parser on
keys.openpgp.org. This works fine for *most* users, but in the end causes more
trouble than it's worth, so we will probably switch to something more lenient
soon.

See also dkg's thoughts on the matter on the openpgp-wg mailing list, to align
the specification with reality:
https://mailarchive.ietf.org/arch/msg/openpgp/wNo27-0STfGR9JZSlC7s6OYOJkI

- V

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: keys.openpgp.org not sending confirmation email [ In reply to ]
On 17.09.2019 15:08, Vincent Breitmoser wrote:
>
>> but as far as I have understood my communication with Vincent, it's such IDs
>> which are a problem for keys.openpgp.org.
>
> Right, that's because we currently use an actual rfc2822 parser on
> keys.openpgp.org. This works fine for *most* users, but in the end causes more
> trouble than it's worth, so we will probably switch to something more lenient
> soon.
>
> See also dkg's thoughts on the matter on the openpgp-wg mailing list, to align
> the specification with reality:
> https://mailarchive.ietf.org/arch/msg/openpgp/wNo27-0STfGR9JZSlC7s6OYOJkI

Thank you very much for the link. That was an interesting reading. There
are much more differences between IDs in the wild and RFC2822 than I
ever would have suspected.

Did I get this right? That post has been published just yesterday? Glad
that I noticed this just in time - I already was typing "Does anybody
know how widespread those proposals are, and which one has won?" :-)

Regards,

Binarus


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: keys.openpgp.org not sending confirmation email [ In reply to ]
On Tue, 17 Sep 2019 14:57, lists@binarus.de said:

> to use only key IDs consisting solely of the actual mail address
> hereafter (with or without the angle brackets - I can live with both

That is actually what I suggest for quite some time. The extra stuff is
not required and may lead only to confusion if the user id does not
match the mail address as taken from an addressbook, or a received mail.

Further there are mail providers who do only allow keys which only the
mail address. The Web Key Directory takes this in account and gnupg
will create a new user id for such providers in the publishing process.

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

BTW, for a long time PGP 5 and later had no idea about the charset of
user-ids and happily copied verbatim whatever the OS supplied as a
string. The result is that all MUAs and gpg's command line implement a
heuristic to detect and convert on display the Latin-1 encoding of
German Umlauts.

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

FWIW, tehre are obvious cases which gpg does not catch either. I added
two test cases to show this:

+++ b/common/t-mbox-util.c
@@ -77,6 +77,12 @@ run_mbox_test (void)
{ "<fo()o@example.org> ()", "fo()o@example.org" },
{ "fo()o@example.org", NULL},
{ "Mr. Foo <foo@example.org><bar@example.net>", "foo@example.org"},
+ { "Surname, Forename | company <foo@example.org>", "foo@example.org"},
+ /* The next one is for sure not RFC-822 correct but nevertheless
+ * the way gpg does it. We won't change it because the user-id
+ * is only rfc-822 alike and not compliant (think only of our
+ * utf-8 requirement). */
+ { "\"<foo@example.org>\" <foo@example.net>", "foo@example.org"},
{ NULL, NULL }
};

> 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

Actually we parse the address out of the user-id and put it into the
Signer's User ID subpacket of a signature if possible. Mail addresses
have the advantage that they maps to a global directory of identities
which full user-ids won't.


Salam-Shalom,

Werner


--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: keys.openpgp.org not sending confirmation email [ In reply to ]
On Tue, 17 Sep 2019 15:08, gnupg-users@gnupg.org said:

> See also dkg's thoughts on the matter on the openpgp-wg mailing list, to align
> the specification with reality:

OpenPGP has never defined what goes into the User ID except for the
encoding which should be UTF-8. Anything else does not belong into the
specs unless the X.509 mess is a desired outcome. Thus the current
wording is sufficient and has served us well over the last 25 years [1]:

| ## User ID Packet (Tag 13)
|
| A User ID packet consists of UTF-8 text that is intended to represent
| the name and email address of the key holder. By convention, it
| includes an RFC 2822 [](#RFC2822) mail name-addr, but there are no
| restrictions on its content. The packet length in the header specifies
| the length of the User ID.



Salam-Shalom,

Werner




[1] RFC-1991 is oldest spec I have instantly available; it describes the
1991 data format of PGP2, it differes from OpenPGP only by using ASCII
for the encoding:

|6.7 User ID Packet
|
| Purpose. A user ID packet identifies a user and is associated with a
| public or private key.
|
| Definition. A user ID packet is the concatenation of the following
| fields:
|
| (a) packet structure field (2 bytes);
| (b) User ID string.
|
| The User ID string may be any string of printable ASCII characters.
| However, since the purpose of this packet is to uniquely identify an
| individual, the usual practice is for the User ID string to consist
| of the user's name followed by an e-mail address for that user, the
| latter enclosed in angle brackets.


--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: keys.openpgp.org not sending confirmation email [ In reply to ]
> Thus the current wording is sufficient and has served us well over the last 25
> years

If your statement here includes the "by convention contains an rfc2822
name-addr" part of the wording, please bring this opinion up on the openpgp-wg
thread.

The argument is being made (and I agree) that it's plain to see that
implementations neither emit user ids as rfc2822, nor parse them as such, by
convention or otherwise. The spec is factually wrong and misleading for
implementors in this aspect, and should be updated to reflect reality.

- V


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: keys.openpgp.org not sending confirmation email [ In reply to ]
On Tue, 17 Sep 2019 17:35, look@my.amazin.horse said:

> convention or otherwise. The spec is factually wrong and misleading for
> implementors in this aspect, and should be updated to reflect reality.

The specs are not wrong if you would read them:

| the name and email address of the key holder. *By convention*, it
| includes an RFC 2822 [](#RFC2822) mail name-addr, but there are no

Convention \Con*ven"tion\, n. [.L. conventio: cf. F. convention.

5. An agreement or contract less formal than, or preliminary
to, a treaty; an informal compact, as between commanders
of armies in respect to suspension of hostilities, or
between states; also, a formal agreement between
governments or sovereign powers; as, a postal convention
between two governments.
[1913 Webster]

In German "Sitte" oder "Brauch". In contrast:

specification \spec`i*fi*ca"tion\

4. A detailed listing or description of the required
properties of some object proposed to be built or bought;
-- usually used in the plural; as, the building
specifications require that it withstand an earthquake of
magnitude 8; the program specifications require an option
to change the menus.
[PJC]

Instead of finalizing RFC4880bis, which has all its goals already
implemented, some members of the WG kept on raising new items for what
the WG has never been chartered. The outcome of all that mess is that
implementers will simply ignore the fact that there won't be an RFC and
implement the current I-D.


Shalom-Salam,

Werner


--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: keys.openpgp.org not sending confirmation email [ In reply to ]
On 17.09.2019 17:21, Werner Koch wrote:
> On Tue, 17 Sep 2019 15:08, gnupg-users@gnupg.org said:
>
>> See also dkg's thoughts on the matter on the openpgp-wg mailing list, to align
>> the specification with reality:
>
> OpenPGP has never defined what goes into the User ID except for the
> encoding which should be UTF-8. Anything else does not belong into the
> specs unless the X.509 mess is a desired outcome. Thus the current
> wording is sufficient and has served us well over the last 25 years [1]:
>
> | ## User ID Packet (Tag 13)
> |
> | A User ID packet consists of UTF-8 text that is intended to represent
> | the name and email address of the key holder. By convention, it
> | includes an RFC 2822 [](#RFC2822) mail name-addr, but there are no
> | restrictions on its content. The packet length in the header specifies
> | the length of the User ID.

I totally agree that the ID in general should be encoded in UTF-8 and
that there should be no further restrictions. That would have solved me
from the hassle which has initiated this discussion (which, by the way,
gets more and more interesting).

However, just in case this discussion really leads to updates of
conventions or even RFCs, I'd like to throw in the following thought:

Some years ago (might be more than ten years, I really don't remember),
there was an article in the well-known German computer magazine c't,
written by one of Heise's long-time authors. In that article, the author
complained and was really upset because some "idiots" (I am citing him
here) constantly generated PGP keys with *his* email address in the ID,
and uploaded those keys to all key servers they knew.

Consequently, he constantly was receiving encrypted emails (probably
with important content - think of him being an investigative journalist)
which he could not decrypt. It was unclear if the "idiots" just wanted
to bother him, if they seriously wanted to prevent sensitive material
from being mailed to him, or if this was part of a greater attack on the
PGP system as a whole (assuming that other journalists were suffering in
a similar manner).

The current policy of some key servers (including keys.openpgp.org) is
to send a confirmation email to each email address which is contained in
an uploaded key's ID. Although this policy probably mainly has arisen
from data protection obligations, it makes the scam described above much
more difficult (if it doesn't prevent it at all).

Of course, a key server can only send a confirmation email if there is a
valid email address in the ID of a key. Hence, a future convention /
standard eventually should provide some sort of structure:

One part of the ID must contain the (valid) email addresses (addr) which
should be associated with the key, and another part has absolutely no
restrictions, or perhaps the only restriction that the @ character is
forbidden (to prevent people from smuggle in something which resembles
an email address).

Key servers then must send a confirmation email each time a key is
uploaded (if its ID contains an address entry), and must use only the
address entries (addr) to match search queries which contain the @
character.

I am aware that this is similar to what we have today, i.e. to the
convention described above. However, that convention, as experience
shows, is interpreted differently by different software packages, and it
is not mandatory.

I am also aware that this would not prevent other sorts of scams. For
example, an attacker could upload a key with his own correct email
address in the respective ID "field", but with my name in the "free
text" part. However, I believe that the overwhelming majority of people
who are searching for my public key are searching by my email address
(and not by my name). Perhaps Vincent has a statistic ...

If there were dedicated "fields" for the address part (addr) in the ID,
the complicated parsing of the name-addr wouldn't be necessary; just the
addr part (i.e. each field) would have to be parsed. The rest of the ID
wouldn't have to be checked, except for the absence of the @ character,
which is trivial.

A very simple ID structure providing that sort of "protection" which
immediately came to my mind is the following:

- The ID may consist of several lines, separated by LF.

- Lines are not restricted in length (as long as the ID as a whole does
not get too big).

- A line is said to be empty if and only if it contains the LF character
and no other character.

- If the first line is empty, the ID does not contain an email address
(addr), and the free text part of the ID starts at the second line.

- If the first line is not empty, it must contain exactly one valid
email address (addr), which is the first email address to be associated
with the key, and all following non-empty lines must contain valid email
addresses (addr) as well, one per line, which are the further email
addresses to be associated with the key. That array of lines with valid
email addresses (addr) is ended by an empty line. The free text part of
the ID starts after that empty line.

The free text part of the ID is encoded in UTF-8 and may contain any
character except the @ character.

Software must not generate IDs other than described above. Key servers
must refuse publishing keys with IDs other than described above. Key
servers must send a confirmation email to all email addresses (addr)
which are in a key's ID, and must not publish an email address as being
associated with a certain key until it has received an answer to the
respective confirmation email.

As far as I have understood, that structure could easily be put into tag
13; no new tag would have to be created (although a new tag for the
email addresses (addr) would be a huge improvement).

We even could allow the @ character in the free text part of the ID if
the key servers would provide two different kinds of search: Search by
mail address (addr) (here, the key server is only allowed to match the
search string against the dedicated address entries), and search by free
text (here, the key server is only allowed to match the search string
against the free text part).

As a final note, I am aware that many problems with scams can be
prevented by mutual key signing or by publishing keys on web sites. But
to be honest, I don't know many people who have their PGP / GPG keys
signed by a noteworthy number of other people. Meeting others just for
this purpose is painful, and validating the other party correctly is
only possible with some knowledge. And of course, not every private
person has a web site, and only a few companies publish more than one
email address with its public key on their web site, even if they have
dozens of employees with have PGP / GPG installed.

Actually, I currently don't know anybody who I could ask to sign my
keys, and furthermore, the problem is bigger the other way around. Can I
trust the key which I found on the key server for the intended
recipient's email address? Can I at least be sure that the key server
has sent a confirmation email to that email address and has received the
answer? Or has it failed to do so due to a malformed email address, but
finds that address nevertheless because it performs a full-text search
against the key IDs?

So, in summary, my point is that there should be as few restrictions on
the ID as possible, but it should be made sure that everything which
resembles an email address (addr) and which could be found by querying a
key server actually has been validated by having sent a confirmation
email and having received an answer. This especially means that email
addresses (addr) can't be part of surrounding free text, because parsing
(and possibly removing) them from such an environment is technically
complicated, implementation-wise error prone and subject to different
interpretation. There is some risk that the confirmation / validation
failed due to a malformed or wrongly interpreted addr, but that this
addr can be found nevertheless on the key server. Therefore, we need to
structure the ID so that there is one dedicated place where addrs can be
stored and easily parsed, which again means to disallow them in normal
free text.

Just my two cents - and being happy and grateful for what we have
already! Maybe it's too late - having had a long day ...

Regards,

Binarus

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: keys.openpgp.org not sending confirmation email [ In reply to ]
Binarus wrote:

> Actually, I currently don't know anybody who I could ask to sign my
> keys, and furthermore, the problem is bigger the other way around. Can I
> trust the key which I found on the key server for the intended
> recipient's email address? Can I at least be sure that the key server
> has sent a confirmation email to that email address and has received the
> answer? Or has it failed to do so due to a malformed email address, but
> finds that address nevertheless because it performs a full-text search
> against the key IDs?

If you would use your real name in your UID you could let Governikus
certify your key. Governikus is a German CA run on behalf by the BSI.

For that you will need a (certified) ID-card reader and AusweisApp2.

https://pgp.governikus.de/pgp/

Regarding the other questions, it would be IMHO really nice if we
would have internationally more CAs for GnuPG users, thus one must
not rely on the classical WoT signatures.

Regards
Stefan

--
box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56
certified OpenPGP key blocks available on keybase.io/stefan_claas


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: keys.openpgp.org not sending confirmation email [ In reply to ]
On 17.09.2019 21:58, Stefan Claas via Gnupg-users wrote:
> Binarus wrote:
>
>> Actually, I currently don't know anybody who I could ask to sign my
>> keys, and furthermore, the problem is bigger the other way around. Can I
>> trust the key which I found on the key server for the intended
>> recipient's email address? Can I at least be sure that the key server
>> has sent a confirmation email to that email address and has received the
>> answer? Or has it failed to do so due to a malformed email address, but
>> finds that address nevertheless because it performs a full-text search
>> against the key IDs?
>
> If you would use your real name in your UID you could let Governikus
> certify your key. Governikus is a German CA run on behalf by the BSI.
>
> For that you will need a (certified) ID-card reader and AusweisApp2.
>
> https://pgp.governikus.de/pgp/

Thank you very much for that hint. That might be a solution for German
citizens, and probably the citizens of a few other European countries.

However, I see several problems:

- People just refuse spending money or precious desk space on chip card
readers. The best proof is the nonsense the German banks are currently
doing to implement PSD2. I do not know anybody who has bought a chip
card reader. Instead, everybody installs a TAN generator app (one for
each bank) on the very same smart phone where the actual banking apps
are running, which undoubtedly decreases security.

- While I have no problem with one-time investments (chip card reader),
my red line are regular payments. From a first quick look at the website
you mentioned, I got the impression that the certification is currently
free of charge. However, at a first glance, I couldn't find out how long
a certification is valid, and experience tells me that they will begin
to charge a substantial amount of money every year or so to refresh the
certifications as soon as more than an infinitesimal number of people
use them.

- After the incidents at the web (SSL) CAs (Symantec, DigiNotar and so
on), I do not trust any centralized certification any more, even if
those incidents happened some years ago.

By the way, when clicking "Öffentlicher Schlüssel für die Beglaubigung"
in the menu at the page bottom of https://pgp.governikus.de/pgp/, you
currently just get an error page ("Es konnte leider nichts gefunden
werden"). This for sure is the best way to generate trust ... Probably
it's exactly what you should expect from a company which acts on behalf
of German government.

- The most important aspect is that I just can't force an addressee of a
private message to get that certification. The addressee might live in
another country where such certification is not available, or he might
refuse to buy a card reader or to get the certification for other
reasons. I don't have any figures (hopefully somebody else has), but I
suppose that no more than 5% of PGP users have a chip card reader.

In contrast, the email verification system for keys is by far less
secure than the Governikus certification, but it is already available,
works in every country and provides at least some level of security
which is by far better than nothing. It just needs to be supported by
making implementation easier, which primarily means eliminating the
ambiguities when deciding what is an email address in the key IDs, which
in turn means making dedicated addr entries mandatory and forbidding to
treat anything outside these entries as an email address; all of this
could be achieved with some small changes of the key ID convention /
specification, which additionally would make parsing the key ID by key
servers much more easy, less error-prone and reproducible.

> Regarding the other questions, it would be IMHO really nice if we
> would have internationally more CAs for GnuPG users, thus one must
> not rely on the classical WoT signatures.

As long as these CAs don't charge money, I totally agree with you
(although I am mistrustful towards CAs as I stated above).

Finally, I've got a question (no criticism, really just a question
because I have absolutely no experience with AusweisApp and the like):

You have stated that my real name must be in the key ID if I would like
to have the key certified by Governikus. Does the key ID need to have
other personal data in it? After all, as an example, there for sure are
at least 1000 people in Germany whose name is "Peter Meier" (which is
the reason why I personally will always use the email address (instead
of the name) as the criterion when searching for a public key). If there
is other personal data in the ID (like the address), what happens when
people relocate?

Regards, and thank you very much,

Binarus

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: keys.openpgp.org not sending confirmation email [ In reply to ]
Binarus wrote:

> You have stated that my real name must be in the key ID if I would like
> to have the key certified by Governikus. Does the key ID need to have
> other personal data in it? After all, as an example, there for sure are
> at least 1000 people in Germany whose name is "Peter Meier" (which is
> the reason why I personally will always use the email address (instead
> of the name) as the criterion when searching for a public key). If there
> is other personal data in the ID (like the address), what happens when
> people relocate?

AusweisApp reads your personal data from your ID-card and then Governikus
certifies your key, containing your real name. Your key does not need to
have other personal data besides your real name.

My UID for example looks like this: Stefan Claas *offline key* <sac@300baud.de>

I know that there is as second Stefan Claas living in Germany, but
he will not have the same email address like I have. So people looking
up key servers could then find of course (if he would upload a key too)
a second Stefan Claas.

I have no expierence when one relocates, but as I see it it does not matter
as long as you are a holder of a German ID-card.

When in doubt always give a hint to your key in your email signature,
so that people you are communicating with know the proper key to fetch.

Regards
Stefan

--
box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56
certified OpenPGP key blocks available on keybase.io/stefan_claas


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: keys.openpgp.org not sending confirmation email [ In reply to ]
On 18.09.2019 17:30, Stefan Claas via Gnupg-users wrote:
> Binarus wrote:
>
>> You have stated that my real name must be in the key ID if I would like
>> to have the key certified by Governikus. Does the key ID need to have
>> other personal data in it? After all, as an example, there for sure are
>> at least 1000 people in Germany whose name is "Peter Meier" (which is
>> the reason why I personally will always use the email address (instead
>> of the name) as the criterion when searching for a public key). If there
>> is other personal data in the ID (like the address), what happens when
>> people relocate?
>
> AusweisApp reads your personal data from your ID-card and then Governikus
> certifies your key, containing your real name. Your key does not need to
> have other personal data besides your real name.
>
> My UID for example looks like this: Stefan Claas *offline key* <sac@300baud.de>
>
> I know that there is as second Stefan Claas living in Germany, but
> he will not have the same email address like I have. So people looking
> up key servers could then find of course (if he would upload a key too)
> a second Stefan Claas.
>
> I have no expierence when one relocates, but as I see it it does not matter
> as long as you are a holder of a German ID-card.
>
> When in doubt always give a hint to your key in your email signature,
> so that people you are communicating with know the proper key to fetch.

OK, that makes sense. Thank you very much for the explanation.

My question regarding the relocation was only meant for the case that
Governikus would need other personal data besides the name (e.g. the
address) in the ID to certify a key.

So the real name is the only mandatory part in the ID of a key certified
by Governikus, while other parts, notably the email address, are
optional. Perhaps this policy is too relaxed. Personally, I always
include the respective email address(es) in my keys' IDs, but some
others probably don't (if they aren't forced to).

IMHO, this system lacks a mandatory unique token in the key ID. The
natural choice for such a token would be the email address, because in
the first place it is the only thing you know for sure when writing a
private message to somebody else who you haven't become acquainted with
yet. Perhaps Governikus should think of making it mandatory.

Regards, and thanks again,

Binarus

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: keys.openpgp.org not sending confirmation email [ In reply to ]
Binarus wrote:

> IMHO, this system lacks a mandatory unique token in the key ID. The
> natural choice for such a token would be the email address, because in
> the first place it is the only thing you know for sure when writing a
> private message to somebody else who you haven't become acquainted with
> yet. Perhaps Governikus should think of making it mandatory.

Well, I was not clear enough, sorry! In order that Governikus can send
you the signed key back it requires that you have an email address in
your UID.

Best regards
Stefan

--
box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56
certified OpenPGP key blocks available on keybase.io/stefan_claas


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: keys.openpgp.org not sending confirmation email [ In reply to ]
On 19.09.2019 12:31, Stefan Claas via Gnupg-users wrote:
> Binarus wrote:
>
>> IMHO, this system lacks a mandatory unique token in the key ID. The
>> natural choice for such a token would be the email address, because in
>> the first place it is the only thing you know for sure when writing a
>> private message to somebody else who you haven't become acquainted with
>> yet. Perhaps Governikus should think of making it mandatory.
>
> Well, I was not clear enough, sorry! In order that Governikus can send
> you the signed key back it requires that you have an email address in
> your UID.

I see. That makes much more sense. Thank you very much again!

Regards,

Binarus


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