How to verify an email signature from Facebook?
Facebook allows users
to add OpenPGP public keys to their profile; these keys can be used to "end-to-end" encrypt notification emails sent from Facebook to your preferred email accounts. – Securing Email Communications from Facebook
Facebook provides a public key (0x2F3898CEDEE958CF) at https://www.facebook.com/facebook/publickey/download/
“encrypted notifications” regarding my account have been sent to me repeatedly via email from Facebook ([email protected]). These emails are encrypted with my public key, that I have uploaded to Facebook. These emails are signed with a key (0x3028CF59770E7A01) which is not the one provided by Facebook (0x2F3898CEDEE958CF). When I try to import the key 0x3028CF59770E7A01 with Enigmail the following notification is displayed:
The key with ID 0x3028CF59770E7A01 is not available on the keyserver. Most likely, the owner of the key did not upload their key to the keyserver.
Please ask the sender of the message to send you their key by email.
- I have found no way to contact the sender of the message.
- I have found no source for the key 0x3028CF59770E7A01.
My main question: How can I verify the email signature from Facebook?
And by the way: Why would Facebook use a key that produces a signature that can not be verified?
Update
Looking up the key 0x2F3898CEDEE958CF on a keyserver (see e.g. keyserver.ubuntu.com) will show a recent inclusion of a subkey 0x3028CF59770E7A01:
sub rsa4096/3028cf59770e7a01 2019-07-08T16:09:07Z
sig sbind 2f3898cedee958cf 2019-07-08T16:09:07Z ____________________ 2020-01-04T20:00:00Z []
This is in accordance with the information provided by Facebook in their post Securing Email Communications from Facebook
Facebook's OpenPGP key comprises a long term primary key with short term subkeys; this allows us to frequently rotate our operational keys whilst maintaining the web of trust and a consistent identity over time.
However this subkey apparently is not public and attempts to receive this missing key from a keyserver fail.
gpg: Signature made Di 06 Aug 2019 17:56:19 CEST
gpg: using RSA key 3B6C6808FC9D75EDAE0184E73028CF59770E7A01
gpg: Can't check signature: No public key
The facebook.asc provided by Facebook actually holds two subkeys, which can be seen by executing gpg --show-key --with-colons facebook.asc
pub:-:4096:1:2F3898CEDEE958CF:1431903600:1581038771::-:
uid:::::::::Facebook, Inc.:
sig:::1:2F3898CEDEE958CF:1517966771:::::[selfsig]::13x:
sub:-:4096:1:D2CC929B77D6D6F9:1547468530:1564686000:::
sig:::1:2F3898CEDEE958CF:1547468530:::::[keybind]::18x:
sub:-:4096:1:3028CF59770E7A01:1562602147:1578168000:::
sig:::1:2F3898CEDEE958CF:1562602147:::::[keybind]::18x:
Notice that the second subkey is the ominous 0x3028CF59770E7A01.
Importing this file to my keyring (gpg --import facebook.asc ) works and suddenly
gpg: Signature made Di 06 Aug 2019 18:00:09 CEST
gpg: using RSA key 3B6C6808FC9D75EDAE0184E73028CF59770E7A01
gpg: Good signature from "Facebook, Inc." [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 31A7 0953 D8D5 90BA 1FAB 3776 2F38 98CE DEE9 58CF
Subkey fingerprint: 3B6C 6808 FC9D 75ED AE01 84E7 3028 CF59 770E 7A01
While Enigmail's Key Management repeatedly fails to download the subkey 0x3028CF59770E7A01 (e.g. from hkps://keys.openpgp.org or hkps://hkps.pool.sks-keyservers.net) it is possible to receive the subkey via gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys 0x3028CF59770E7A01:
gpg: key 2F3898CEDEE958CF: 586 duplicate signatures removed
gpg: key 2F3898CEDEE958CF: 1417 signatures not checked due to missing keys
gpg: key 2F3898CEDEE958CF: 1 signature reordered
gpg: key 2F3898CEDEE958CF: public key "Facebook, Inc." imported
gpg: marginals needed: 3 completes needed: 1 trust model: pgp
gpg: depth: 0 valid: 2 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 2u
gpg: next trustdb check due at 2021-02-07
gpg: Total number processed: 1
gpg: imported: 1
Update My default keyserver was stripping the user IDs from the keys, resulting in new key but contains no user ID - skipped. Using keyserver.ubuntu.com solves that. This answer explains why.