No. The federation model of the SKS pool has various problems in terms of reliability, abuse-resistance, privacy, and usability. We might do something similar to it, but keys.openpgp.org will never be part of the SKS pool itself.
For the moment, no. We do plan to decentralize keys.openpgp.org at some point. With multiple servers run by independent operators, we can hopefully improve the reliability of this service even further.
Several folks offered to help out by "running a Hagrid server instance". We very much appreciate the offer, but we will probably never have an "open" federation model like SKS, where everyone can run an instance and become part of a "pool". This is for two reasons:
We require explicit consent to distribute identity information. Identities that aren't e-mail addresses, such as pictures or website URLs, offer no simple way for us to acquire this consent.
Note: Some OpenPGP software creates keys with incorrectly formatted e-mail addresses. These addresses might not be recognized correctly on keys.openpgp.org.
An e-mail address can only be associated with a single key. When an address is verified for a new key, it will no longer appear in any key for which it was previously verified. Non-identity information will still be distributed for all keys.
This means a search by e-mail address will only return a single key, not multiple candidates. This eliminates an impossible choice for the user ("Which key is the right one?"), and makes key discovery by e-mail much more convenient.
We use a modern standard called MTA-STS, combined with STARTTLS Everywhere by the EFF, to make sure verification e-mails are sent out securely. This protects against eavesdropping and interception during delivery.
The MTA-STS mechanism depends on correctly configured e-mail servers. You can run this test to see if your e-mail provider supports it. If the "MTA-STS" entry on the left isn't a green checkmark, please ask your provider to update their configuration.
Short answer: No.
A "third party signature" is a signature on a key that was made by some other key. Most commonly, those are the signatures produced when "signing someone's key", which are the basis for the "Web of Trust". For a number of reasons, those signatures are not currently distributed via keys.openpgp.org.
The killer reason is spam. Third party signatures allow attaching arbitrary data to anyone's key, and nothing stops a malicious user from attaching so many megabytes of bloat to a key that it becomes practically unusable. Even worse, they could attach offensive or illegal content.
There are ideas to resolve this issue. For example, signatures could be distributed with the signer, rather than the signee. Alternatively, we could require cross-signing by the signee before distribution to support a caff-style workflow. If there is enough interest, we are open to working with other OpenPGP projects on a solution.
The keys.openpgp.org service is meant for key distribution and discovery, not as a de-facto CA. Client implementations that want to offer verified communication should rely on their own trust model.
When an OpenPGP key marks one of its identities as revoked, this identity should no longer be considered valid for the key. And this information should ideally be distributed to all OpenPGP clients that already know about the newly revoked identity.
Unfortunately, there is currently no good way to distribute revocations, that doesn't also reveal the revoked identity itself. We don't want to distribute revoked identities, so we can't distribute the identity at all.
There are proposed solutions to this issue, that allow the distribution of revocations without also revealing the identity itself. But so far there is no final specification, or support in any OpenPGP software. We hope that a solution will be established in the near future, and will add support on keys.openpgp.org as soon as we can.
If you have Tor installed,
you can reach keys.openpgp.org anonymously
This is a problem with current versions of GnuPG. If you attempt to update a key from keys.openpgp.org that contains no identity information, GnuPG will refuse to process the key:
$ gpg --receive-keys A2604867523C7ED8
gpg: key A2604867523C7ED8: no user ID
We are working with the GnuPG team to resolve this problem.