Hacker News new | ask | show | jobs
by jnbiche 2493 days ago
I like the ability to remove keys. I understand the theoretical reason for append-only keyservers, but in practice it just turns people off from using them. No one wants to look at their entries from 2005 from when they screwed up while learning about subkeys, or their defunct 2008 entry which they never could revoke because they lost the revocation certificate (all examples purely fictional).

In any case, a keyservers job is not even to be some kind of source of trust, so all that really should matter is that it has a user's most up-to-date keys on it. Validating a key should come from web-of-trust or some secure second channel verification method (like listing your key ID on a TLS-enabled website).

2 comments

> No one wants to look at their entries from 2005 from when they screwed up while learning about subkeys

Yeah, it's interesting that even platforms such as Keybase that allow changing or removing data timestamp them in irremovable ways sometimes (e.g. following someone snapshots their profile in the follower's sigchain).

> In any case, a keyservers job is not even to be some kind of source of trust, so all that really should matter is that it has a user's most up-to-date keys on it. Validating a key should come from web-of-trust or some secure second channel verification method.

Actually having a key on a keyserver was never relevant as web-of-trust runs parallel to the key origin (that is if you're connected to WoT you'd know which key is the real one). But it's not practical in general.

> like listing your key ID on a TLS-enabled website

Web Key Directory is something like that and it's trivial to set up: https://spacekookie.de/blog/usable-gpg-with-wkd/

I assume a bigger justification for not running an append-only keyserver was this dumpster fire[1] in which the append-only nature of the SKS keyserver ecosystem was abused as a DOS vector.

---

[1] https://news.ycombinator.com/item?id=20312826