To double- and triple-check the PGP signature of the Qubes master signing key, I searched for the fingerprint (427F 11FD 0FAA 4B08 0123 F01C DDFA 1A3E 3687 9494) on several public key servers.
On some (eg keyserver.ubuntu.com), I got a “Not found” result.
On the OpenPGP keyserver, a key was returned, but it did not match the public signing key that was already on my Qubes system.
Should I be concerned?
Remove the spaces like this:
https://keyserver.ubuntu.com/pks/lookup?search=427F11FD0FAA4B080123F01CDDFA1A3E36879494&fingerprint=on&op=index
Every PGP key has one of these fingerprints, which uniquely identifies it among all PGP keys. (On the command line, you can view a key’s fingerprint with the
gpg2 --fingerprint <KEY_ID>command.) Therefore, if you know the genuine QMSK fingerprint, then you always have an easy way to confirm whether any purported copy of it is authentic, simply by comparing the fingerprints.
Thanks for clarifying.
On the keys.openpgp.org keyserver, even when I remove spaces from the fingerpint, the key still doesn’t seem to check out. Has this server been compromised?
The OpenPGP keyserver does not sync well with other keyservers for reasons that I will explain below, in case you are curious, but the TLDR is that it is unsurprising for this keyserver to have a different set of keys than other popular keyservers.
Most keyservers work on a “web of trust” model where trust is established in keys by signatures from other keys. The idea is that you only truly trust a key if you have verified the fingerprint in-person after verifying the identity of the person through some other means (perhaps by looking at an ID card). I’ll call trusted keys “neighbors”. People can trust a key by checking if any of their neighbors trust the key. If not, then they check if any of their neighbors’ neighbors trust a key. And so on and so forth until they have a list of neighbors going from themself to the key that they want to trust. This is why downloading the key from the Ubuntu keyserver’s website will typically include a lot of signatures, and it is easy for keyservers that work on this model to sync with each other.
The OpenPGP keyserver works by validating the email attached to a keyserver. This is similar to a password reset on most websites: when you submit a key, the keyserver will send an email with a unique URL, and it will only publish identity information if the URL is followed (the key itself will be published either way, but the name & email address will not be). It is not very useful to publish to this keyserver unless you want to take advantage of the email validation service so a lot of people choose not to.
There are a lot of people who make a lot of noise about these methods being mutually exclusive, “competing” methods of establishing trust but there is no reason that we cannot use both. These are not the only methods to establish trust either, for example the QubesOS documentation recommends that you verify the master key by checking multiple independent sources so that a compromise in one source can be detected (Verifying signatures | Qubes OS). IMO this is good advice because in practice web of trust logic only works if you are in the right social circles to have the privilege of verifying a number of keys from trusted parties in person (if PGP were widespread then web of trust would work better, which is why it would be nice if our banking system worked with public ledgers and PGP-signed statements of transfer, similar to blockchain but without wasting a bunch of electricity, but I am digressing pretty far at this point so I’ll stop).
As @skyvine mentioned, the keys.openpgp.org keyserver relies on email addresses in order to validate keys that are uploaded. The QMSK has no email address in its user ID, so maybe that’s why the key has no user ID when downloaded from this keyserver.
(Not having an email address in the user ID is perfectly valid per the OpenPGP standard. It’s just that the operators of the keys.openpgp.org keyserver have chosen to institute a more restrictive policy.)