On 2019-07-02 at 10:01 +0200, Wiktor Kwapisiewicz wrote: > > It is a real shame that a decentralized Hagrid isn't really > >possible, though, at least to my understanding. It's quite the > >limitation for GnuPG. > > Decentralized non-identity information hagrid could still be > possible. > It's just a question over which protocol to synchronize this kind of > data.
A point I don't like about the design of hagrid is that verification is performed by the server itself. Thus, it seems that if there were a reconciliation protocol between them, either entering into one of them would lead to all of them blindly trusting it, or the owner would need to validate a challenge for each keyserver to which it gets replicated. My expectation would be that the verification added a (non-dropped) signature by the entity which performed the verification. The keyservers themselves would be configured with a set of introducing keys whose signatures they accepted for non-stripping. This way, multiple servers, managed by different individuals, could rely on a common verification entity (which may not run a keyserver itself). The current reconciliation protocol (ie. the one used by SKS) would probably work if all keyservers in a network trusted the same verification keys, as they would share the same view. (I admit my utter ignorance of the gossip protocol, though) It would be desirable that it worked even with separate ones, so eg. gentoo could use a single server that allowed its own CA and keys.openpgp.org, even if the later only trusted its own verifier. Unpublishing of uids would simply be triggered by the publication of the revocation signature. This is akin to other systems, like the old "PGP Global Directory Verification Key" signatures. I see on https://sequoia-pgp.org/blog/2019/06/14/20190614-hagrid/ that a machine-readable vouch was not added since "we don’t think that the verification is strong enough to even warrant a positive certification". However, I do think that will be needed in order to have a successful keyserver network, and it would be helpful to separate both roles. They could be made at the persona cert level (1), to make gpg ignore them (by default), though, as a way to disincentive treating them as a CA. Kind regards _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
