ietf-openpgp
[Top] [All Lists]

Re: [openpgp] Privacy-preserving Transferable Public Keys

2019-06-14 03:40:25
On Fri, 31 May 2019 09:42, look@my.amazin.horse said:

A) Distribute updates to subkeys and the primary key (expiry, revocation, 
etc),
without revealing the key's UserIDs.

Easy for new and revoked subkeys.

For full revocations gpg has always allowed to import a standalone
revocation self-signature.

For changing expiration or preferences the user id is required or the
client needs to trial verify all new self-signatures.  The server won't
be able to check the self-signatures if it has no access to the user-id.
This will spam the users and server with bogus self-signatures.

Right, direct key signatures can be used but I we have not much
experience with them.

B) Distribute updates to UserIDs (expiry, revocation, etc) without revealing 
the
UserID itself.

This is the same as A modulo direct key signatures.

C) Create, distribute, and use keys without attaching UserIDs or other
designation metadata at all

Why should one want to do that?  The user id (i.e. mail address or DNS
name) is important meta data.  However, it is better to use a direct
mapping from the user id to the key than any arbitrary mapping as done
by keyservers.  Then any updates to the user id can be retrieved via
that userid->keyblock service.

done in dkg's "abuse resistant keyserver" document, recently on this list.

The simplest way to avoid DoS on keyservers is to disallowing searching
by user id.  That is for about 20 years standard at MTAs and although
not a perfect solution it has helped a lot against mail address
harvesting by asking MTAs.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

Attachment: signature.asc
Description: PGP signature

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp
<Prev in Thread] Current Thread [Next in Thread>