key distribution/verification/update mechanisms other than keyservers

[Daniel Kahn Gillmor]

On Wed 2018-01-17 15:51:07 +0000, Andrew Gallagher wrote:
> On 17/01/18 15:32, Daniel Kahn Gillmor wrote:
>> i don't think you need an extension to OpenPGP at all to do this -- you
>> just need policy.  The policy could be (for example):
>
> The main technical question is where should this policy be applied?

read in the context of the discussion in the thread (i know -- it's 90
messages long, hard to keep up!), we're talking about a parallel
keyserver network here, so the policy would be applied at upload time
(which also means it happens at "replication" time).

> 3. At search/display stage - almost as easy as 1, although more
> computationally intensive as it would need to be calculated per download
> (caching may help). Can be retrofitted to existing keyservers.

I think a better way to consider retrofitting to existing keyservers
would be if existing keyservers could maintain the idea of two
filtersets concurrently.  then, if they're gossiping with a peer who
insists on filterset A (the existing dominant filterset), they work only
with the certificate material that belongs to that particular filterset.

if they're gossiping with a peer who can do the new constrained
filterset (we'll call it B), then they work only with the certificate
material that belongs to that filterset.  but internally they know about
the union of all of that certificate material.

If we had a few keyservers capable of that kind of operation with both A
and B, then we could keep the B-only keyservers in sync during a
migration.

sadly, i don't have such an implementation and i don't know how to do
that work in the time i have available.

     --dkg