Re: [Sks-devel] Implications of GDPR

[Arnold]

On 04-05-18 10:44, dirk astrath wrote:
> It may make sense to keep a revoked key in our database:
> How is your decision, if a key can't be found on a keyserver?
> Trust on first use? Don't trust?

This should, IMO, all be a local, individual decision.

I am currently looking into 'value sensitive design', making systems that are
adjustable to specific human values in different human societies.
[ https://vsdesign.org/ ]


> If my key gets compromised, I want ...
> Therefore:
> If ..., I'm unable to ...

In many messages in the current discussion, it is very easy to spot examples of 
a
need for value sensitive design, like in these few lines above.


> All in all:
> 
> It's not easy to find a perfect solution (if there is any) ... and it's
> not the first time we have this discussion ...

In 2015, the idea came up to let go of the idea of a single set that gets
synchronised. Instead of one single set, we can define parametrised filters to
create 'value sensitive sets' ;-)
[ http://lists.nongnu.org/archive/html/sks-devel/2015-05/msg00062.html ]

If keyserver A has configured Set A and keyserver B has configured Set B, the 
set
reconciliation algorithm between keyservers A and B should only consider Set C,
where Set C is the intersection of sets A and B. The set reconciliation 
algorithm
can be used the same.

In case the operator of keyserver A finds that his Set A is "larger" than the 
union
of all Sets of its peers, that operator can ask on this very mailing list for
peering with keyservers that have the missing subset (based on the configured
parameters of the filters).

At least this might be a solution to the keyserver compatibility problem.


For the pool, we might end up with sub-pools based on filter parameters. If
operators don't do fancy filtering of their own, but follow local law, we might 
end
up with regional pools, possibly based on groups of countries, with a maximum of
the number of countries in the world ;-)

Kind regards,
Arnold