On Fri 2019-06-21 15:26:17 +0100, Andrew Gallagher wrote: > On 21/06/2019 14:32, Werner Koch via Gnupg-users wrote: >> That new thing now is the n-th repetition of the same game: Replacing >> PGP by a centralized approach, or well many centralized approaches, in >> an attempt to repeat the story of S/MIME. PGP has its strengths in the >> idea of not having the one-and-only-distributor-of-all-keys and thus a >> SPoFailure/Denial/Surveillance. If we want that it is easier to go with >> S/MIME. > > If hagrid supported an SKS-like reconciliation protocol, would that > mitigate your concerns?
There might be an impedance mismatch here, depending on what you think the goals are. SKS has no validation policy by default, and SKS-style reconciliation assumes that all peers have the exact same filtering policy. So: what exactly is the data that these servers would reconcile between each other? Since multiple validating keyservers haven't actually seen the same validation steps, it's not clear how they'd decide what to filter in terms of validated data. it may help to think about the different sorts of things that people use keyservers for. we don't have to solve all different use cases at once. I've written quite a bit more technical detail over here: https://tools.ietf.org/html/draft-dkg-openpgp-abuse-resistant-keystore-03 But there are basically three main use cases for OpenPGP keyserver clients (i'm setting aside the use case of people who want to publish their certificates): a) validating a signature that comes from a certificate that the user doesn't yet have access to. b) finding a certificate to associated with a peer the user wants to communicate with (e.g. lookup by e-mail address). c) learning about the status of a certificate that the user already has (expiration, revocation, new subkeys, etc) There's a good argument to be made that use case (a) is simply a broken workflow. If i'm shipping you a signature, and i have no way of ensuring that you already know my certificate, i can just ship my certificate along with the signature. If i don't do that, and you can't verify the signature, it's not clear that any keyserver network *should* be the thing to solve that problem. Use case (b) is intimately tied to the address validation process, which introduces the set reconciliation difficulty i allude to above. (b) is also well-suited to distributed discovery mechanisms, like DNS OPENPGPKEY or WKD, at least for users of domains that are willing to offer such a delegated publication mechanism. so it might not be a necessary component for a keyserver network long-term. But the data required for use case (c) on its own is eminently reconcilable, with relatively simple and clear filtering logic, and is likely the most worrisome part for the SPoFailure/Denial/Surveillance concerns that Werner rightly raises. So if we decide we only want to address use case (c), then it doesn't seem too crazy to imagine reconciliation among multiple installations of all the distributed, cryptographically-validated *non-identity* data that hagrid is designed to distribute. And this should be fully-compatible with hagrid's implementation; each instance which can simply augment the reconciled data with the identity information that it has independently verified. --dkg
signature.asc
Description: PGP signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users