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

Reply via email to