Design of a Modern Keyserver Network

[Jakob Bohm]

>
>> I wonder if removing the UID information from a key is enough to be forgotten
>> (vs the entire key).
> (Disclaimer: I am *not* a lawyer)
>
> I believe it should be enough to satisfy the right to be forgotten. According
> to Article 4(1) of the GDPR, "‘personal data’ means any information relating to
> an identified or identifiable natural person (‘data subject’)". By removing all
> UID data from the public key, the data subject (key owner) is not identified by
> the key itself. But is the data subject identifiable through the key + some
> additional research to find external references to the key that relate it to
> the data subject? Potentially, yes. Though an important detail to note is that
> for the keyserver to remove UID information from a pubic key, that key must be
> revoked. And it can be reasonably expected that most or all references to the
> now-revoked public key would be removed or changed. After all, why would anyone
> ever want to advertise a revoked key? It's completely useless! As such, it
> likely can be reasonably assumed that with all UID data removed, the public key
> neither identifies the data subject, nor does it make the data subject
> identifiable within reason.

I am not a lawyer either, but I did do some careful reading of the GDPR 
a few
years ago (It's written in EU-legalese, which seems to be a somewhat 
backwards
notation optimized for machine translation to/from French and German legal
documents).

As I understand it, UIDs are what the GDPR calls 'pseudonymous' personal 
data
and as such is still subject to some protections .  The 'right to be 
forgotten'
would require an ability of a user to remove any of the their own keys
(including the UID) from the keyserver network, also the organizer of the
keyserver network, rather than the individual server operators would be 
deemed
the "data controller" subject to most of the legal requirements, and 
would need
to have contracts (electronic would be easiest) with the keyserver 
operators
requiring the keyservers to faithfully perform all requests (including
deletions) on behalf of the affected end users, in accordance with the
published terms/policy of the "data controller" .

There would also be a need to write legal documents about the data sharing
between the keyservers and rules banning 3rd parties from making their own
copies of public keyserver information that might be handled contrary to 
the
rules in ways that harm users privacy.

Beware that some GDPR lawyers are so badly focused on the needs of big
data-hoarding companies that they end up giving out bad advice on what the
GDPR means (GDPR basically exists to outlaw that data-hoarding, but their
day job is to somehow argue that such abuses are legal).  A horror story is
how ICANN hired the wrong people to write up the GDPR documents for the
WHOIS service and ended up having to censor all the useful information to
match their bad legal theories with the law.

A much better approach would be to look at how country-wide online phone
directories comply with the GDPR, including the fact that most countries
will have multiple phone companies that can register and publish numbers
etc. assigned to people, while the directory will need to provide a
unified cross-provider search that will tell any member of the public
what the non-hidden phone number for someone is.

Because PGP key servers do not have an ongoing contract with a specific
subset of users (there is no ongoing connection service and no ongoing
contract payment, so no reason for users to remember which server they
uploaded their key to), aspects of the legal framework that presume
such provider contracts cannot be used.

> I can for certain agree that requiring the upload and storage of revocation
> certificates is the design's main limitation. Both for the reasons you've
> outlined, and also because it shifts more trust onto keyservers and their
> operators, which arguably goes against the web of trust's principle of
> entrusting solely users with the responsibility of managing their own key
> pairs. But since keyservers act as a middleman for the distribution of public
> keys, they too likely require at least some (ideally limited) ability to manage
> said keys in the event of legal intervention. So I mainly view it as a
> compromise between abstaining from interference of users' keys and adhering to
> legal obligations.
Indeed, revocation certificates should, as a long standing best practice,
and to comply with the data-minimization requirements of the GDPR, NOT be
stored until published by the user.

There will need to be a clear distinction between revocation and delisting,
as a user could want to delist a still valid key, or leave a revoked key
listed (to spread the revocation notice).

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded