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

[Andrew Gallagher]

On 2019/06/30 18:06, Daniel Kahn Gillmor wrote:
> 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?

We start from hagrid or something like it, and carefully add the ability
to sync only the absolute minimum of data required to allow revocations
to propagate. This probably means primary keys, their self-sigs and
revocation sigs.

(*Maybe* subkeys also, but it's probably unnecessary since distributing
new key material is less urgent than revoking existing material.)

We could repurpose the existing SKS recon protocol, but introduce
breaking changes: a) the protocol is versioned so that implementations
can gracefully degrade, and b) only whitelisted packet types are synced.

>> 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.

Sure, but WKD and Autocrypt still don't collectively cover all the edge
cases, so some residual need for a keyserver-like system remains.

>> 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.

iOS's native Mail app cannot be replaced, and all third-party mail apps
must use its API which is less than fully-featured. Constructing a
PGP/MIME message requires access to the MIME headers that the Mail app
does not expose. All PGP apps under iOS must either cut and paste inline
PGP or encapsulate messages as attachments that Mail treats as black
boxes. PGP on iOS is therefore klunky as hell, and it's not going to
improve unless Apple makes a conscious decision to support it.

> Anyone who claimed
> keyservers were authoritative in the past was either confused or
> misleading you.

I am under no illusion that the keyservers are authoritative, don't worry.

A comparison with DNS may be useful. DNS is a distributed cached
database, but there is a distinction between primary, secondary,
recursive etc. Recursive resolvers make the system resilient, but the
primary is consulted regularly and the cache constantly invalidated.

(In DNS of course, the master is also considered authoritative, but this
does not automatically follow in a cryptographically validating system)

The keyservers make no distinction between primary and secondary - all
keyservers are equal, the provenance of data is thrown away, and the
cache can therefore never be invalidated. But provenance matters, and if
synchronising keyservers can't be primaries, something else should be.
That can be WKD, DANE, or just a plain URL on a server that I control.
Keyservers would then be mainly limited to caching information that was
obtained from some master keystore (with the exception of material
strictly required for revocations).

OpenPGP already has the "keyserver" field which is rarely used. It is
supposedly a hint to clients to tell them to prefer a particular
keyserver, but it could also be used as a hint to the keyservers
themselves, to tell them where the master copy of any public key can be
sourced.

> 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.

I'd suggest adding a "caching keystore", either after or as a subsection
of "updates-only keystore", with the following properties:

```
A caching keystore extends the concept of an updates-only keystore, by
supplying user IDs and third-party certifications on the condition that
they were recently available at an original location specified by the
key's owner. This mitigates key-flooding attacks by preventing arbitrary
submissions, and allows for the coordinated deletion of old or
problematic material by removing it from the original location.

* A caching keystore MUST accept submissions of primary keys as well as
cryptographically-valid self-certification and revocation sigs
(including third-party revocations) over those primary keys.

* It MAY synchronise the above key packets from other keystores. It MUST
NOT synchronise, or accept external submission of, any other packets.

* It SHOULD attempt to fetch and temporarily cache user IDs and incoming
third-party certifications over each primary key from the URL contained
in that primary key's "keyserver" field, if defined.

* If more than one "keyserver" definition is found for a given primary
key, then the most recent cryptographically-valid packet MUST take
precedence.

* It MUST cryptographically verify all fetched material.

* It MUST discard any unexpected fetched packets, even if they are
cryptographically valid. In particular, it must discard any outgoing
third-party certifications *from* the fetched key, in case they flood
some other key.

* It MAY impose further restrictions on cached packets (e.g. it may
choose not to cache image IDs).

* It SHOULD delete cached packets after a reasonable period of time once
they can no longer be retrieved from the "keyserver" URL.
```

-- 

Andrew Gallagher

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190701/96fa819d/attachment-0001.sig>