A key server will be used within Eclipse applications to better support PGP signing, e.g., for displaying the web of trust, and even supporting things like key revocation. Without a key server, a more complete web of trust as shown here would not be possible, e.g., we'd only be able to show the first two nodes in the lower tree:
We can only know a key is revoked if we get an up-to-date version of the key from a key server...
The key server site will also be used by users to understand the web of trust with respect to the keys they are being asked to trust and to manually verify with great care.
Designs
Child items
...
Linked items
0
Link issues together to show that they're related or that one is blocking others.
Learn more.
Note that the goal set by the Platform team and the Planning Council anticipates the potential for delivering PGP signed content for Q2. I think the user experience will be somewhat poor without a key server and I think it will be kind of embarrassing to use Ubuntu's key server.
Perhaps worse than poor usability and strange use of foreign servers, without a key server, we can't generally implement key revocation which is perhaps a security hole...
Just to better understand the requirements, is this expected to be publicly searchable & publicly updatable or just publicly searchable with some kind of private/secured update mechanism?
So definitely searchable via query strings as spelled out in the specification. If it's not updateable, it would definitely have to mirror from a server/source that is updateable. I think mirroring from elsewhere is pretty important if this is going to be generally useful for any PGP keys (e.g., all the ones that are in Maven)...
I think PGP is generally for every yahoo, but then I think a yahoo could flood a site with keys. I read about that being a problem. It's also a problem that really old crappy keys can accumulate. It would be good to find out how https://keyserver.ubuntu.com/ is managed because it's fast and good. I don't have all the answers. But keep in mind that people will install things from market place and those eventually will use PGP keys that users will want to find out more about, so ideally we'd do as good a job as keyserver.ubuntu.com at providing information about public keys.
First of all an own keyserver would have the advantage that we are not bound to others infra, e.g. if ubuntu is down/slow we still can use our own. Beside that, one could add some feature to add their public key to the eclipse account and it automatically appears (e.g. with enhanced metadata from the account) there without need ask people using another service. One even might require to sign their commits with the account PGP key, its all open.
Beside that web-of-trust is nothing really stored on a key-server it is something in the users private key-ring but could simplify such usages as it is a place to exchange such data. And as data-exchange of the public key and their verification by others is a key-point in PGP trust it is actually desirable that "every yahoo" should be encouraged to publish there data because otherwise you can't use PGP.
So lets assume we have a keyserver and every committer has uploaded his public key, we do not have gained much more than I can send an encrypted message to a person and be sure he is the only one that could decipher it (if we trust what the crypto guys state).
So lets say I send a (signed) message to Ed and tell him to try out a patch, lets say that patch is not trivial and probably Ed do not know much about me (I might have faked all or some of my account details how knows?) so how can Ed trust me? He might ask me to meet each other and exchange keys and verify each others identity but that might be possible of the distance. Luckily Ed can see that Lars is living next to me and Ed has already meet Lars at the last Eclipsecon and has exchanged the details and also find he can trust Lars, then he might ask him to verify with me or probably Lars and I have already meet in the past and there is already a record on the key-server about that.
Now Ed > verified Lars > verified me so Ed could be to a certain degree be confident that at least I exits and my account details are somewhat valid (Lars might has checked my passport).
So the Keyserver can store that Ed verify Lars (hopefully vice versa) and Lars verified me (again vice versa), but Ed now has to decide how much he trust Lars. If that is over a given threshold then he could also trust me -> Web of trust.
And here now revocations become important, lets say Lars is confident that his key was compromised (e.g. copied to an not encrypted USB stick and Lars has lost it or it was stolen), now Ed probably would trust another stranger because he does not know but the key of that stranger was signed with Lars key? For sure Lars can try to contact everyone and explain that, or better he creates a revocation certificate for his key and upload it to as many keyservers as he knows and hopes that others (unknown ones) sync with them. Now Ed could get a message that the key was revoked and he no longer can trust anyone verified by that key. And that's where it becomes important (even if not required) that key servers sync each others, to spread the information as good as possible and make it as easy as possible to gather other persons key.
There's no disagreement about the value of a the web of trust. But as Mikael points out, there are many keyservers out there, so I/we question the value of an EF-hosted keyserver. Allow me to express some .. hesitation about taking on new infra, when it comes with many an expectation regarding performance, security, availability and overall longevity (ie, if we enable this, it's virtually a contract for life).
As described above, we would be just more flexible and independent using an own keyserver, e.g. because we want to publish additional meta-data.
If that's not required, an own keyserver is not strictly required but we might want to simply publish more meta-data to existing servers to fulfill Eds requirements.
So as far as I can tell there is exactly one key server that works reliably and provides useful web-of-trust details.
I understand the concerns about new infrastructure. Note though that it's not strictly necessary that the server be 100% available; the implementation caches richer key information locally and will reuse that when the server is not available. The user will just see poorer data when the server was never available.
More of a concern though is key revocation. Without access to any server, one can never know that a key has been revoked. That's a security concern.
If the Eclipse Foundation is comfortable that our PGP signing infrastructure, as used by p2 for installing and updating, should rely solely on the functionality of keyserver.ubuntu.com that's okay. I think it would be very good to have our own keyserver, though it should have rich information and a wealth of keys just like keyserver.ubuntu.com. Conversely, it would be kind of odd not to have our own keyserver when we have infrastructure that relies on one. But that is your decision to make, not mine; it is a significant long term commitment...
the Eclipse IDE would be the only user of such a service (there has been no similar request from other projects up to this day)
the decision from the Eclipse IDE to move to PGP has been made without consulting the Eclipse IT team about the new service's requirement
the expectations regarding performance, security, availability, and overall longevity are, for good reason, very high, but would be additive to the already overwhelming workload of the infra team
the industry is moving away from GPG signing at an accelerating pace, most notably towards the sigstore technology, which may be a more interesting service, with a broader scope and usage, to investigate in: