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

[Daniel Kahn Gillmor]

On Sun 2019-06-30 00:33:22 +0100, Andrew Gallagher wrote:
> Indeed, c) was exactly the killer use case I had in mind.

so, how do we get there?

> On the other hand, b) is also quite useful in the short to medium
> term, until all mail providers decide to support WKD etc.

WKD is mighty nice, but it is not necessary.  For example, if you don't
care about first-contact, Autocrypt is a totally reasonable key
discovery mechanism.  It also has a significantly reduced metadata
footprint compared to WKD or DANE OPENPGPKEY, since all messaging is
in-band.

It has other problems, of course, but it can be used directly today (not
just "short to medium term").

> And considering that some companies still don’t fully support PGP/MIME
> after nearly twenty years of being the preferred standard (I’m looking
> at you, Apple), “short to medium” effectively means “indefinitely”.

If you know something specific about Apple failing PGP/MIME in some
capacity i hope you'll be more explicit about it, because i don't know
what you're talking about.

> So maybe we shouldn’t think of keyservers as storage repositories, but
> rather as search engines. The keyservers should not be authoritative,
> but they should be a best effort directory of where the authoritative
> locations are, combined with a cache of the non-identity cryptographic
> material in case the authoritative locations get DOSed.

Of course they're both search engines and storage rpositories, and they
are not and have never been authoritative.  Anyone who claimed
keyservers were authoritative in the past was either confused or
misleading you.

> If the authoritative location is not on a keyserver, then we do not
> need to sync arbitrary data between keyservers, just a list of
> location hints. The keyservers would then fetch from the authoritative
> locations and decide for themselves how much of the content to cache.

i'd be curious to read any specific guidance about how you think a
sensible keyserver would make those decisions.  If you want to propose
changes to
https://tools.ietf.org/html/draft-dkg-openpgp-abuse-resistant-keystore
i'd be happy to incorporate them too.

    --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/20190630/f8e995e6/attachment.sig>