(Note that this is mainly a client side mitigation, and may not require significant server-side effort if pm/gc supports the necessary wire formats)

Motivation

It is generally accepted that a key owner should be able to control the distribution of third-party sigs on their key, however it is not desirable that they should control the distribution of third-party sig revocations - otherwise the key owner could prevent a revocation from being seen by their correspondents and thereby continue to present their key as valid even if it were not.

It is therefore desirable for revocations of third-party sigs to be synchronised with the signer's key, not with the signed key. This is particularly important if HIP 2, HIP 3, and/or 1pa3pc are implemented, as they will all impede the propagation of third-party sigs.

Examples of interactions

When a client searches for a TPK, it should receive all third-party sig revocations alongside the third-party sigs made on that key. It should also receive a list of the third-party revocations made by that key, so that there is a second channel by which third-party sig revocations can be obtained. Support for this may require changes on the client side.

Design

Revocation of third-party sigs interacts in nontrivial ways with self-sovereignty, as sig revocations are just as effective a DoS vector as sigs, but self-sovereignty should not grant the ability to prevent revocation distribution. A keyserver should always serve any third-party revocations (if they exist) alongside the corresponding third-party sig, but this is not sufficient if third-party sigs can be removed from keys to prevent poisoning.

The solution is to distribute revocations with the signing key, so that even if the signed key has had the third-party sig removed, clients that previously downloaded and trusted that third-party sig have a channel whereby revocations can be obtained. It is sufficient to distribute revocations with the signing key as without the signing key the sigs cannot be validated anyway.

The same extension should also apply to hashqueries etc. when used by the key recovery process. If HIP 2 is implemented, revocations made by a key should therefore be treated as self-sigs on that key, so that recovery of the revocations can be initiated.

Out of scope

We assume that everyone regularly polls their keyring for updates using parcimonie or equivalent.

Please see HIP 2 and HIP 3 for further discussion of third-party sig distribution.

Security considerations

Verification of third-party sigs is not local, as it requires both TPKs. But without verification, it would be possible for a key to be flooded with fake revocation sigs purportedly made by that key, instead of on the key. This just moves the flooding problem around rather than solving it.

Further, in the base scenario, we can test the quick-hash bytes to detect obvious errors without reference to the signer. If we distribute revocations with the signer instead, such quick-tests are not possible, which is a regression from current (v2.2) behaviour.

We could specify attestations over the revocations in order to make them locally verifiable. IFF this took the form of an attestation sig over an embedded signature subpacket, this would have the added advantage of allowing revocations to be distributed in a grammatically-correct TPK instead of as a non-standard extension.

Compatibility

This may need changes to client software in order to work correctly; not all client software will expect to receive revocations made by the requested key. See also https://github.com/hockeypuck/hockeypuck/issues/96#issuecomment-1540337586 and https://dkg.gitlab.io/draft-openpgp-abuse-resistant-keystore/#name-revoking-third-party-certif

A wire format for distribution of third-party certification revocations is described in https://datatracker.ietf.org/doc/html/draft-gallagher-openpgp-user-attributes .

This removes a potential abuse vector introduced by HIP 3 and 1pa3pc.