I've had multiple people tell me that they searched for the OpenPGP fingerprint they found on my Twitter profile but it says "don't use" so they're not sure if they should trust it.

This is a user interface issue with sks.

I think that either the web app should only display uids that have valid signatures, or the web app should explicitly show that uids with invalid signatures are invalid (for example, by making them red and crossed out).

But the former is probably cleaner UI, and if people really wish to see the invalid uids they can always download them and use pgpdump, just like they must to see all sorts of other information stored in a public key block.

Comments (16)

keyservers, by design, does not validate signatures, it is not the role of the keyserver to do so as that would require it to be trusted. It is a pure data store. This is not a display issue, this is a misunderstanding of basic concepts and misusing the infrastructure for a role it is not intended for.

I just looked up the OpenPGP message format RFC, and it indeed doesn't seem to require that User ID packets have an associated "Positive certification of a User ID and Public-Key packet" Signature packet signed by the signature key to be a valid User ID. So technically, it appears that invalid UIDs don't violate the spec.

However there are no implementations of OpenPGP (that I'm aware of) that actually generate UID packets without Signature packets -- which is why you need access to the private key to "adduid" in gnupg. And there's no situation where anyone would ever want an unsigned UID packet on their key. And while it's true that anyone can add whatever they want to keyservers, it doesn't mean that sks should display obviously malicious UIDs.

PGP already has enough usability issues. It would be absurd not to fix such a simple bug that does nothing but cause more confusion.

Users shouldn't be thought to trust in third party services to begin with.
OpenPGP is secured by an object based security model and only a local client
has any chance of validating the keys and signatures in a trusted matter.
Users shouldn't visit the keyservers directly, but use the clients to access
it.

By the way, I still consider this a major issue. I've since learned that it's not just malicious UIDs that get displayed in the SKS web interface as if they were valid, it's also malicious revocation certificates.

It would be pretty trivial to fake-revoke every key in the strong set and upload them to key servers. When users view these keys in the a web browser, it would appear that they're all revoked.

You might not be the kind of person that strangers who are new to OpenPGP send encrypted emails to a regular basis, but I still hear from people all the time who think my key has been hacked because of the invalid UID that says "Dontuseee".

Kristian, would you mind if I fake-revoked your key, and added some fake UIDs to it as well, to demonstrate that severity of this bug?

@Kristian Fiskerstrand: Unfortunately, this faulty UX can lead to a compromise in security. One crucial observation here is that users won't always use your tool in the manner that it was intended, but paying attention to usage trends says a lot about the design of your tool.

If you provide a web interface to your tool, but that interface is integrity-weak and displays bogus, untrustworthy information, the fault is not with the user for using that interface; it's the fault of the designer to provide it without clear warning.

Of course, a GUI client, and importing via CLI, will only display verified, trustworthy information, but searching via either the web UI or the CLI will show bogus data -- not just user IDs, but revocation certificates as well. If an interface makes it possible for a user to think a key is revoked when it's not, or send encrypted e-mail to an unverified user ID, then that is bad UX; not only is that bad UX, it's bad UX that leads to a bad security decision.

These interfaces should either not exist, or exist with ample warnings. Leaving this unaddressed is precisely the kind of thinking surrounding a tool that's built for the choir -- not the congregation. I hope you'll reconsider your position on this.

Unfortunately users already incorrectly assume a level of trust in third party operators. This is why I opened this issue: because users were confused by the status quo, and thought that they could trust what they saw in the sks web app, when they can't.

But I suppose insisting that OpenPGP remains confusing and unusable for the foreseeable future is your choice.

I wonder if a solution for the sks project as a whole, instead of just for this one server, could be a warning message in the web interface? The top of each page could say something like, "You should not trust any information you see here. Use an OpenPGP program like GnuPG to view information about public keys."

/pks is just proxied to SKS, its not related to sks-keyservers.net, just removed any direct links to it.

The solution is education of users. If the user is dependent on a notice that the information isn't to be trusted, they are lost anyways - obviously a mallicious participant will just remove the disclaimer, its just silly.

There's a range of what people think they can trust. Some people think they if they search for an email address on a key server and find a key, that means they found that person's key. Some people know that fake keys are everywhere, but if they're looking at a key with the right fingerprint that they can trust the UIDs and signatures they see. Some people don't trust anything they see in the web UI.

If the information displayed on sks keyserver websites can't be trusted, but you still think it should be displayed because it's helpful for debugging reasons, this should be clear in the UI (doesn't necessarily have to be a warning message -- maybe it can just not be displayed at all, with a "debug info" link that shows what's in the PGP packets).

The best way to educate users is to build the education directly into their user interfaces. Otherwise they make mistakes and are told they just don't understand how it works, when in reality the UI is basically lying to them.

they shouldn't be on the keyserver UI at all, they should access HKP through third party tools. It just so happens that HKP is a layer over HTTP so they can visit it in browsers, although the number of questions I get on why port 80 doesn't provide the results they expect (port 11371) is curious on its own.

So, end users simply shouldn't use the sks software in a web browser to find keys at all. Instead they should use software like GnuPG to interact with sks?

Looking at the web interface of what is one of the most active instances of sks, this is not obvious at all. In fact, the opposite is obvious. It's very clear that you can use sks to search for keys, upload keys, etc.

Maybe all of those forms on the homepage should be replaced with a short paragraph telling people to use gpg, or some other software, to interact with sks instead? (Or the web interface could just avoid displaying provably malicious results...)

But honestly, the web interface is very useful. For example, I use split-gpg in Qubes. This means that my gpg keyring is in a VM that doesn't have a network interface, and my email client/other software that uses my keys communicates to this VM in a secure manner, without actually having access to its data. But sometimes I need to retrieve a key from a key server, which is more difficult since my gpg VM doesn't have internet access. My options are: 1) use a key server web interface to search for the key, and then copy and paste it into my gpg VM to import it, or 2) use a gpg in a different VM to retrieve the key, then copy that file into my gpg VM to import it. I frequently search for keys using the sks web interface to import them into my networkless gpg VM. Having a usable sks web interface is actually useful for me, and probably for other people too. It's just silly to insist that it not do the bare minimum to try to not display known-bad information.

But if you truly feel like the web interface shouldn't be used, then the fix really should be getting rid of all of those forms that make sks searchable. The solution to bad user interfaces isn't "user education", it's fixing the user interfaces.