GPG creates invalid keys if the settings file is not encoded in UTF-8
Open, LowPublic


Expected Behaviour

When using a settings file that is encoded in something other than UTF-8 (for instance Windows-1252) containing non-ASCII characters, GPG outputs a meaningful error message or detects the encoding and uses it correctly. It should never create an invalid key.

Actual Behaviour

When using gpg --gen-key with a settings file encoded in Windows-1252 containing non-ASCII characters (for instance German Umlauts) in the Name-Real field, GPG will create a key with a Windows-1252-encoded user Id. This is in violation of RFC 4880, section 5.11 which states that the user Id must be encoded in UTF-8.

Tested with GPG4win 3.1.5, GnuPG 2.2.11 and GnuPG 2.0.26 on Windows 10. I suspect this issue also occurs with other distributions and OS.

Steps to reproduce

  1. Create a Windows-1252 encoded settings file with the following content:
Key-Type: RSA
Key-Length: 4096
Subkey-Type: RSA
Subkey-Length: 4096
Name-Real: Ümläut
Name-Email: uemlaut@localhost
Expire-Date: 5y
  1. Create a new key with gpg --batch --gen-key <SETTINGS-FILE>
  2. If you inspect the public key, you will see that the user Id is encoded in Windows-1252



GPG4win 3.1.5, GnuPG 2.2.11
werner added a subscriber: werner.Feb 9 2019, 11:43 AM

I don't think that we are going to change this. All data is utf-8 including the *conf files.

aheinecke triaged this task as Low priority.Feb 11 2019, 9:39 AM
aheinecke added a subscriber: aheinecke.

I think we might accept this with low priority. As this is an unusual way to create a key.

But if we can detect invalid utf-8 strings in the config file or in a user id we should error out.