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
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
