Mailing List Archive

Re: [Sks-devel] Fwd [from schleuder dev team]: Signature-flooded keys: current situation and mitigation
> On 18 Jul 2019, at 17:46, Todd Fleisher <todd@fleetstreetops.com> wrote:
>
> "Unfortunately, there is currently no
> good way to distribute revocations that doesn't also reveal the revoked
> identity itself. We don't want to distribute revoked identities, so we can't
> distribute the identity at all."

We can kill two birds with one stone here, using two simple extensions-by-convention of the protocol.

A key owner can (preferably automatically) create a “self-identity” on her primary key consisting of a well-known string that contains no personal information. To avoid breaking legacy search-by-id systems this string should be unique to the primary key. I suggest using “fpr:00000000000000000000000000000000000”, where the zeros are replaced by the fingerprint of the key. The self-identity (and any revocations on it) can then be safely distributed by keystores that would otherwise refuse to distribute personal info.

A recipient can then infer from revocation of the self-identity that the primary key itself has been revoked (and by extension all associated identities, whether published or not).

A

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [Sks-devel] Fwd [from schleuder dev team]: Signature-flooded keys: current situation and mitigation [ In reply to ]
Hi Andrew,

On 18.07.2019 19:35, Andrew Gallagher wrote:
> A key owner can (preferably automatically) create a “self-identity” on her primary key consisting of a well-known string that contains no personal information. To avoid breaking legacy search-by-id systems this string should be unique to the primary key. I suggest using “fpr:00000000000000000000000000000000000”, where the zeros are replaced by the fingerprint of the key. The self-identity (and any revocations on it) can then be safely distributed by keystores that would otherwise refuse to distribute personal info.

Minor thing: I suggest using
"openpgp4fpr:00000000000000000000000000000000000" instead of "fpr".
That'd make the User ID a valid URI as "openpgp4fpr" is an assigned URI
Scheme, see:

https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml

Probably the cleanest solution (suggested by others) would be using
direct key signature (0x1F) [0] and avoid User IDs entirely. Your
suggestion Andrew has the benefit that it's immediately backwards
compatible with software "in the wild".

[0]: https://tools.ietf.org/html/rfc4880#section-5.2.1

Kind regards,
Wiktor