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

[Dirk Gottschalk]

Hello. 

Am Dienstag, den 09.07.2019, 21:37 +0200 schrieb Werner Koch:
> On Tue,  9 Jul 2019 14:13, gnupg-devel at gnupg.org said:

> > > === Record deletions
> > > If someone requests a deletion (which means this person can prove
> > > that it is there personal data), this is also recorded, only by
> > > key
> > > number, so this can also be synced with other keyservers.

> > Sure, technically not a big thing. 

> Right, we have most tthings already in place.  To delete a key the
> owner of the key just needs to publish a revocation certificate.  The
> keyserver validates the revocation and removes everything from the
> key but the primary public key and the revocation signature.

This is a really good starting point.

> We can also make use of the reason-for-revocation flag.  For example

>   No reason specified               --> Delete as described.
>   Key is superseded                 --> Keep keyblock.
>   Key material has been compromised --> Delete as described
>   Key is retired and no longer used --> Keep keyblock

Yes, this makes sense. For a revoked key there is no need for a UID-
Packet. A refresh would get the 'cut' packet and add the revocation.

The UID packet on the client side shoule be left untouched so that the
user is still able to see whoms key has been revoked.


> In the keep cases the server should be prepared to see another
> revocation to delete the key.  This is a bit questionable in the "key
> compromised" case.

Yes, I see. In this case there shoule be some kind of additional
confirmation mechanism to avoid abuse.

Regards,
Dirk

-- 
Dirk Gottschalk

GPG: 4278 1FCA 035A 9A63 4166  CE11 7544 0AD9 4996 F380
Keybase: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190710/3a655e4d/attachment-0001.sig>