Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?

[Daniel Kahn Gillmor]

On Thu 2019-02-07 23:15:18 +0100, Kristian Fiskerstrand wrote:
> The current discussions we're having (e.g during OpenPGP email summit in
> brussels in october and lately on FOSDEM last weekend) is eventually not
> storing UIDs at all on the keyservers, but require the user to do key
> discovery through WKD, directly on a website or the like. This still
> allows using keyservers to distribute revocation certificates and
> updates to subkeys etc, but not as a discovery mechanism.

thanks for this summary, kristian.  it roughly matches my recollection
of these discussions as well.

It's conceivable that such a constrained updates-only-keyserver network
could also host self-signed user IDs, with reasonable constraints
(e.g. valid UTF-8 only, no more than 512 octets), but no third-party
certifications.  This would permit keyserver-based updates of
expirations, since primary key expiration timestamps are currently
stored in the self-signatures over the User IDs.

Alternately, we could encourage OpenPGP implementations to issue primary
key expiration timestamps as direct-key signatures, not involving a user
ID at all.

Critically, though, this updates-only keyserver network would *only*
permit retreival of keys by fingerprint, and would not provide a
web-based tool for browsing based on User ID, to avoid the usability
failures that we've seen attributed to SKS in the past.

Each node in this proposed updates-only network would also need to be
able to cryptographically verify the OpenPGP packets that it
synchronizes, and should reject packet that cannot be cryptographically
verified.

> Pool-wise it'd be setting up a separate keyserver network that  will
> gossip with the existing network for a time, with separate pool for the
> with-uid and without-uid servers, before the full switch is done...

Figuring out how to do the partial-sync for a limited time sounds
difficult to me, and i wonder whether it might be better/faster/cheaper
to just deploy such an update-only network, and don't bother with the
partial sync.

> The new network would be running on software replacing SKS, using more
> suited database backend that and multi-threaded implementation. The
> current disagreement are really with regards to whether this should be
> "validating keyservers" or not, and how such servers could interact with
> non-validating ones.

"validating keyservers" form an entirely distinct interaction model,
since they are focused on User IDs.  They should not be conflated with
this updates-only proposal.  There's no need to coordinate their
development.

        --dkg