Keyservers and GDPR

[Ben McGinnes]

On Thu, May 24, 2018 at 12:42:12AM +0200, Christoph Anton Mitterer wrote:
> On Wed, 2018-05-23 at 23:45 +0200, Kristian Fiskerstrand wrote:
> > yes and no.. it basically changes keyservers to becoming certificate
> > authorities.
> ?? Why this?
> 
> A CA is trusted by others and assures the identity of subjects.
> The challenge/response I'm talking about, would just assure that only
> the owner can publish the key to the network.

I take it you just mean something like signing a token with the key
you're trying to upload?  Sure, assuming it doesn't also prevent
signature updates, for all the obvious reasons.

> Of course the owner could still set up a fake User ID, effectively
> publishing another user's personal data.. but I guess then we'd be
> save in terms of privacy laws.
> 
> 
> > but it is basically the PGP
> > Global Directory.
> I don't think PGP GD requires prof that an uploader is the key owner.
> The only difference with that is that it doesn't syncronise with other
> keyservers (which is a major deficiency from a security PoV)... and
> didn't it remove keys after a while (if the users didn't reupload)..
> but then removal is complete (IIRC)... which is again a major
> deficiency, as revocations are also removed.
> 
> 
> 
> > From a security perspective I'm not impressed about it, and there are
> > several caveats, in particular related to expecting a domain name
> > being
> > in the original owner's control forever

> You mean the PGP GD model? Well I haven't said we should do it as
> they do it (i.e. sending a mail to people asking them for
> reupload)...

Good, it does get a bit ridiculous and the load would be a bit silly.

> instead... if a user wants to keep his UIDs published,
> his client would need to do the reupload every now and then.. say
> once a year.  If he doesn't,... the UIDs would get removed from the
> keyserver network (but NOT the revocation sigs).

Hang on, you're proposing the keyservers edit keys that aren't updated
to remove the UIDs?

Two questions:

 1. How could end users continue to trust the servers knowing that
    their key data may be edited at all?  For instance if law
    enforcement want to isolate a person from contact and issue some
    kind of compliance order to remove the UIDs since there's
    precendent, what then?

 2. How would you actually update this when resynchronising with other
    servers will simply (or should simply) restore that data?

> I'm not sure whether other sigs on the key should be removed

They should not, only the person/entity making the signature should be
modifying it.

> (especially thinking about the certifcation sigs the person of the
> removed key made on other people)... these could basically allow to
> "trace" his contacts... and may therefore interfere with privacy
> laws.  OTOH... when the UIDs are gone... it's already
> pseudo-anonymous... so might be fine.

You're already veering into dangerous enough territory with any kind
of key modification as it is.

> I'd rather think about: when some person wants to upload its key... its
> client must attach a signed standardised message like:
[SNIP]
> And only if the current date/time is in a +/- 30 min time frame... and
> if the sig validates... the keyserver would accept the UIDs.

This bit I kind of don't mind.

> The whole thing would *not* apply to just upgrades... like new
> certification sigs.

Presumably it would apply to adding and revoking subkeys, the UIDs,
modifying any expiration times of the primary key or subkeys, changes
to cipher, digest and algorithm preferences (including cert-digest)
and so on, but *not* to the addition of signatures or revocation of
the same.

Deletion of data should not be permitted because it opens the entire
nework up to a whole slew of attacks and legal vulnerabilities which
would be rather bad.


Regards,
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180528/3738ebf0/attachment.sig>