New keyserver at keys.openpgp.org - what's your take?

[Daniel Kahn Gillmor]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190621/f64c60b2/attachment.sig>