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

[Werner Koch]

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.

Anyway in the case of a compromised key it might make sense to delete
everything but the primary key and the revocation signature: Anyone who
has access to the compromised key can add user-ids and other stuff to
the key at will and thus harm the repudiation of the user (We all know
that people don't look at details of a key, like [REVOKED], when they see
some kind of interesting data in the key).  But that's up to discussion.

> except the primary makes sense in such cases. Merely superseded keys
> should be searchable by ID because we may wish to verify historical

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.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190710/f787d8d4/attachment.sig>