Preserving non-central and privacy with a "permission recording keyserver"

[Andrew Gallagher]

On 2019/07/10 18:54, Werner Koch wrote:
> On Wed, 10 Jul 2019 10:27, andrewg at andrewg.com said:
> 
>> I don't think we should ever delete the full dataset (i.e. including the
>> primary). We still need to be able to distribute revocations, and that's
>> only going to work if they're attached to something.
> 
> Some folks are talking about privacy reasons not to distribute the
> user-id.  I don't buy this argument because the user has already given
> his consent (with most MUAs and with gpg's command line) to use a mail
> address along with a key and the specific format is a requirement.

The problem with the consent argument is that consent must be active and
explicit; you cannot presume consent just because someone has used a
service. But I don't think the consent argument is relevant, because
(IMO) keyservers fall under "subject has placed the information in the
public domain" - so long as there has been a reasonable verification
step to ensure that it was the data subject that did it.

The real trick is vindicating the right to deletion...

> Anyway in the case of a compromised key it might make sense to delete
> everything but the primary key and the revocation signature:

Agreed.

> A key on a keyserver should never be searchable by user-id.  It is not
> required and only an attractor to use the keyserver as free and
> searchable data storage.  We only need lookups by fingerprint.  Keys
> should in general be discovered by other reliable mail to key mapping
> services.  If that is not possible there is always the fallback to first
> send a signed mail and the recipients tool can then lookup the key via
> the fingerprint (which is embedded in the signature) at a keyserver.

That works for email userids. But email is only one use case for PGP, so
there is still a need for some form of lookup by ID, at least in the
short term.

-- 
Andrew Gallagher

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190710/5bf2e07e/attachment.sig>