On 13/06/18 14:43, Daniel Kahn Gillmor wrote: > the proposed revocation distribution network wouldn't allow any user IDs > or third-party certifications, so most of the "trollwot" would not be > relevant.
As I see it, the keyservers perform two related but distinct functions - finding unknown keys by UID, and finding updates to known keys by fingerprint. All the current issues are related to the first function, but the first function has several alternative solutions available (DNS, WKD, Keybase, attaching pubkeys to every email...). If this first function were to fail overnight, it would be an inconvenience but not a disaster. But there is no known alternative to the second function, which is the distribution of key updates, including revocations. Therefore I believe the immediate priority should be to protect update distribution. How to prevent abuse of a distributed, unauthenticated store of arbitrary data remains an unsolved problem (see: usenet). If the keyservers are to remain unauthenticated and distributed, then the only option is to prohibit arbitrary data. That means no arbitrary data fields (i.e. no UIDs) and no arbitrary data in structured data fields (i.e. validity checks on self-sigs). This will shrink the size of the database significantly, but impose some processing cost. There are two ways forward: a new network of key-material-only servers, or restricting the existing network to key material only. In the first case, we would still need a means to propagate keys between the old and new networks during the transition. And in the second case, we would need to handle an intermediate state where only some servers have been upgraded to the new version. So no matter what we do, we will still need to have some method of doing fake recon with legacy sks instances. The question is how to arrive at this state most efficiently. I would suggest that since recon is at the root of the problems, we should concentrate on the recon process itself. If uploading a bad key takes down one server then fine, we can lose one server. But the badness must not infect other servers automatically. -- Andrew Gallagher
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users