Public certificate generated by plugin cannot be imported into several different GPG apps due to userID check failure

[3ndarchy]

First, I apologize if I lack the technical detailed knowledge on the programming or PKI side to fully describe what is happening.

The public certificate generated by the plugin can be imported into into some GPG Keychains (e.g. Mailvelope, Protonmail), and appears to be failing on the userID check. The error is similar to what is outlined here: mailvelope/mailvelope#713

But appears to be related to the certificate versus the keychain, as the issue also happens with Protonmail. My theory is the checksums are being printed incorrectly when the plugin generates the public key. GPG Keyrings that skip/ignore this conflict and focus on other checks import it fine, but any that include checking of the two-bit checksum run into an issue.

It gets out of my league at this point so I'm not sure if it is even possible to find out what is causing an invalid checksum to appear in the public key and correct that so the key can be imported into a wider variety of keychains (or if it's even 100% the problem).

[fabacab]

I am not sure what you are referring to when you say "public certificate" (which is a term used in the S/MIME technology) but then say you are trying to import this thing into a GPG Keychain. Moreover, the plugin does not actually generate public certificates. It only generates an OpenPGP keypair. Maybe that's what you mean?

Either way, if so, and from your description, it sounds like this would be more appropriate to report to the upstream OpenPGP.php project. This plugin uses that library to actually generate the OpenPGP signing key used to authenticate outgoing emails. As such, you should report any issues with invalidly generated keypairs to that project, not here.

[VincentBentley]

Thunderbird 78.14.0 and 91.4.1 OpenPGP Key Manager cannot import public keys generated by this plug-in. Received emails cannot be processed correctly because it is impossible to import the public key of the sender (generated by this plug-in) into the recipient's client application either automatically or manually from an armor .asc file. Messages sent by WordPress arrive with an uncertain signing and no way of validating it on the client.

As a possible workaround, I generated keys manually in GnuPG 2.2.19 with libgcrypt 1.8.5 on an Ubuntu workstation and copy/pasted the PGP key blocks into the appropriate text areas. However, this breaks WordPress! I read in the documentation that you could manually create a bigger and longer lasting keypair, but this appears to be no longer true. I tried various combinations and each got a 'white-screen-of-death' from WordPress when using the 'Send me a test email' button.

Keypairs generated by GnuPG could successfully be imported into Thunderbird, but that's not much use when WordPress can no longer send any emails.

As the WordPress site has no idea which PGP client the message recipient has, it's now hit or miss if the message is correctly processed at the receiving end if only some PGP clients work. I understand that the developer has used an upstream library for OpenPGP which may indeed be at fault, but the problem is most certainly not resolved. This is a serious issue that shouldn't be brushed off.

I haven't tested the plug-in using S/MIME public certificate.

I would like to use the plug-in, but it is pretty much useless at the moment with this fault present.

[fabacab]

I generated keys manually in GnuPG 2.2.19 with libgcrypt 1.8.5 on an Ubuntu workstation and copy/pasted the PGP key blocks into the appropriate text areas. However, this breaks WordPress! I read in the documentation that you could manually create a bigger and longer lasting keypair, but this appears to be no longer true. I tried various combinations and each got a 'white-screen-of-death' from WordPress when using the 'Send me a test email' button.

At a minimum, this should be reported as a separate issue. I'm not actively maintaining this plugin because there is literally no support for doing so beyond my own personal use of it (which is minimal), so without active funding/support/participation in a useful manner you can pretty much guarantee that this is going to remain unresolved. That said, "participation in a useful manner" is, at a bare minimum, reporting one issue per, y'know, issue? :\ In any event, thanks and I hope it gets worked out for you.

[VincentBentley]

I understand. Thanks for making the code public. I moved away from PHP years ago but I still find WordPress useful for some projects. If I don't redeploy in Django I will take a look at the code. I was hoping for a quick and easy WordPress solution but I guess not now.

[VincentBentley]

Further testing has shown that with the Admin's public key pasted into the plug-in interface, encrypted mail can be sent. However, it arrives without being signed.

[VincentBentley]

With the Admin's public key deleted and the option to sign everything switched on, emails arrived signed but they cannot be verified.

I have uploaded the public key to a keyserver, it contains a valid UID but Thunderbird's OpenPGP Key Manager fails to discover it. It is impossible to import the public key by any other means.

[VincentBentley]

I tried a few workarounds today but sadly each of them failed. I am documenting them here in case they are of any use.

Workaround 1

Use GnuPG offline to 'clean' the plug-in's keys and create a public key that can be imported into Thunderbird's OpenPGP Key Manager.

1. Copy/pasted both Private and Public keys to separate text files (*.asc)
2. Copied .asc files to another machine with GnuPG installed
3. Imported keys into GnuPG
4. When listing them, there are NO signing or encryption subkeys present
5. Exported them to new .asc files
6. Copy pasted them back into the plug-in
7. Sent a test message
8. Email Received, but still has uncertain signature
9. Failed to import public key into Thunderbird

Conclusion: Workaround 1 doesn't work

Workaround 2

Generate new keys offline in GnuPG and import them into plug-in by copy/pasting

1. Deleted previously stored Private and Public keys for WordPress on GnuPG machine
2. Used gpg --full-generate-key to create a 2048 RSA-RSA key that never expires
3. Exported keys to files
4. Copy pasted them into the plug-in
5. Clicked button to send a test message but got WSOD from WordPress
6. Successfully imported public key into Thunderbird

Conclusion: Workaround 2 fails as WordPress site is broken. No point having the public key in the client if the service cannot send email.

Workaround 3

Add an Encryption subkey to the original plug-in generated keys

1. Deleted previously stored Private and Public keys for WordPress on GnuPG machine
2. Imported original plug-in keys back into GnuPG
3. gpg --edit-key wordpress@example.com
4. addkey, RSA Encryption
5. save
6. Exported Private and Public keys to text files
7. Copy pasted them back into the plug-in
8. Sent a test message
9. Email Received, but still has uncertain signature
10. Imported public key into Thunderbird... it recognises the key ID but spots a problem
    
    

Conclusion: Workaround 3 fails to import the public key into Thunderbird

[VincentBentley]

There is likely to be a problem in the OpenPGP_SignaturePacket::sign_data() function using the wrong data for quick checksum.
See singpolyma/openpgp-php#120