PhD project ideas

Dashamir Hoxha dashohoxha at gmail.com
Sat Jun 9 14:51:23 CEST 2018


On Sat, Jun 9, 2018 at 1:34 PM, Andrew Gallagher <andrewg at andrewg.com>
wrote:

>
> > On 9 Jun 2018, at 10:07, Dashamir Hoxha <dashohoxha at gmail.com> wrote:
> >
> > The keyserver is just a servant and it should obey the orders
> > of the user, even if they damage the user himself.
>
> The keyservers don’t obey anyone’s orders. They a fairly dumb, but
> efficient, cache. If you want a system that obeys orders then it might be
> better to use something like WKD or keybase, where keys are attached to
> individual user accounts.
>

I don't know what is WKD, and Keybase as far as I know is centralized, it
is not distributed.
If it was distributed, it would have been a better alternative than
keyservers, in my opinion.

The keyservers perform three main services: finding keys, updating keys and
> revoking keys. There are other ways of finding and updating keys these
> days, even if none of them are as broadly used. For me though, the killer
> application for the keyservers is efficient distribution of revocations.
>

In a GDPR apocalypse scenario the simplest fallback position for the
> keyservers is probably to blacklist any packets containing user IDs. This
> would mean keyservers would no longer be usable for finding keys by ID, but
> their other functions would be maintained.
>

The problem is that I don't care about the keys, because I communicate with
people, not with keys. The keys are just a means of communication. If user
information is removed from the keys, then keyservers become almost
useless, as far as I am concerned.

I don't think there is going to be any "GDPR apocalypse". This has also
been clarified from previous discussions here.
But I do think that the keys should not be published for ever and ever, up
to the eternity. The owner should be able to remove them for whatever
reason he deems this is right.

This has all been discussed in excruciating detail over on the sks-devel
> list in the last few months, including several suggestions for keyserver
> improvements. This thread is probably best continued there.
>

Of course. But this thread was not only about the keyservers, they were
just an example.

Dashamir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180609/a3f68995/attachment.html>


More information about the Gnupg-devel mailing list