> Hi @ll.
Hi Dirk, thanks for your thoughts! > I don't think it's such a good idea to drop Signatures on keys. As mentioned in our FAQ, the reason we don't support those is that with the SKS model, anyone can attach arbitrary data to others' keys. It's hard to overstate how problematic that is. I can just add a megabyte or fifty of data to your key. There are solutions that still allow for some of the TPS-based use cases, but until there is at least some agreement on how to proceed, we decided against supporting them. Free distribution of arbitrary TPSes is quite simply not a viable model for any keyserver. The discussion shouldn't be about liking or disliking them, it should be about what alternatives could be. I see from your signing policy that you do a caff-style workflow. Have you considered the option to have keys cross-sign third party signatures for publication? It's a very slight switch in tooling if we assume a caff workflow, but that way each key remains in control of the public version of itself. > Also the centralized Approach is a no go in my opinion. The open federation model of SKS means all email addresses are enumeratable. That's a privacy no-go in my opinion, which people have gotten surprisingly used to in this community. I can imagine a closed federation model, where we have a handful of operators but still don't need to have personal information of our users in the open. Maybe we'll move in that direction once the dust has settled a bit. The keyserver ecosystem has been stagnant in more than a decade, so.. one step after another. > Even removing the ability to search for keys by UID is a thing I don't > like. Why not? Do you think "find all Dirks on the keyserver" is a valid use case that should be supported? Cheers - V _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users