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
%ask-passphrase
%commit

2. Create a new key with gpg --batch --gen-key <SETTINGS-FILE>
3. If you inspect the public key, you will see that the user Id is encoded in Windows-1252

Related

• OpenPGP JS will reject such keys: github.com/openpgpjs/openpgpjs/issues/845
• This leads to such keys being unusable in Mailvelope: github.com/mailvelope/mailvelope/issues/623
• Sample offending key with an invalid user Id: 0x0F96D906EF3359CB