[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sks-devel] Implications of GDPR
From: |
Andrew Gallagher |
Subject: |
Re: [Sks-devel] Implications of GDPR |
Date: |
Sat, 5 May 2018 01:08:22 +0100 |
> On 4 May 2018, at 22:56, Arnold <address@hidden> wrote:
>
> 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
The main difference between this proposal and the one that Phil, myself and
others are discussing in the other thread is that here the servers need to
agree on the definition of these sets in advance, and servers that do not
understand the sets (perhaps because they are too old) will be unable to recon
with those that serve a restricted set.
The advantage of fake recon is that a) it can be deployed incrementally while
maintaining recon between old and new software versions and b) there is no need
for a commonly agreed definition of sets.
A
- Re: [Sks-devel] Implications of GDPR, (continued)
- Re: [Sks-devel] Implications of GDPR, Gabor Kiss, 2018/05/03
- Re: [Sks-devel] Implications of GDPR, Ari Trachtenberg, 2018/05/03
- Re: [Sks-devel] Implications of GDPR, brent s., 2018/05/03
- Re: [Sks-devel] Implications of GDPR, Daniel Roesler, 2018/05/03
- Re: [Sks-devel] Implications of GDPR, dirk astrath, 2018/05/04
- Re: [Sks-devel] Implications of GDPR, Arnold, 2018/05/04
- Re: [Sks-devel] Implications of GDPR,
Andrew Gallagher <=