DRM?

[Andrew Gallagher]

On 16/01/18 17:19, Leo Gaspard wrote:
> Well, if such requests were honored, this would fix the OP's answer (ie.
> “how do I hide the fact I mistakenly associated two unrelated UIDs on my
> key”, if I understood correctly), as well as requests pertaining to the
> EU's “right to be forgotten”

The right to be forgotten is not absolute. For example, it does not
require that published news be unpublished, although it does sometimes
ask that published news not show up in search results. It also does not
require that search engine operators scrub their internal databases.

It is technically difficult to prevent keys from being propagated
because altering or deleting data packets breaks the assumptions upon
which the reconciliation algorithm is founded. But there is nothing to
stop individual servers from scrubbing search results of keys that have
a valid "nopublish cert" (however this may be technically implemented).
This would not affect SKS reconciliation and would reduce the
computational overhead.

IF something like this were to be implemented, then only searches for
IDs should be stripped. Searches on fingerprints should always return
data, in order to ensure that revocation certificates are still
distributed. "Nopublish" certs could also be used by well-behaved
clients as a guard against accidental disclosure, even if preventing
malicious disclosure is technically impossible.

If we were worried about the *legal* implications of right to be
forgotten, then this could be a defensible fallback position. But it is
not a solution to many of the *practical* problems in privacy protection.

Ultimately, the PGP ecosystem prioritises security over privacy. They
are not the same thing, and in some cases they are in conflict.

-- 
Andrew Gallagher

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180116/f3cc0430/attachment-0001.sig>