Motivation

It is still not possible to reliably delete key material from the keyservers without manual intervention by each keyserver operator (See #136). This is particularly problematic for User ID and User Attribute packets, which usually contain personal information that is regulated by e.g. GDPR, CCPA.

It is generally accepted that a key owner should be able to control the form of their key that is returned from keyservers. This proposal attempts to address the issue entirely through internal changes to keyserver operation.

Examples of interactions

A key owner can revoke their entire key by making a direct key revocation signature. If the reason for revocation is given as either "Key material has been compromised" or "User ID no longer valid", then uploading that revocation to a keyserver will cause it to delete all userid and uat packets (and all signatures over them) from its copy of the key. This revocation will automatically propagate across all synchronising keyservers, and any keyserver that implements HIP 5 will know that it should delete the same personal information. This provides a robust, distributable implementation of RTBF (right to be forgotten).

Design

If a direct revocation signature gives "Key material has been compromised" (0x02) or "User ID no longer valid" (0x20) as its reason for revocation, or gives no reason (either by not including a reason for revocation subpacket (nil) or explicitly stating "No reason" (0x00)), then all User IDs, User Attributes, and signatures over them (both first and third party) MUST be deleted from disk (subkeys and sbinds SHOULD be retained so that searches for subkey fingerprints will return the direct revocation). We call such direct revocation signatures "redacting revocations".

If a key owner issues a hard revocation (0x00, 0x02, or nil) then all signatures generated by that key in the past are now suspect, so there is no need for that key to remain usable even in a historical context. Deleting UIDs and UATs in this scenario ensures that RTBF is the default behaviour, and can be triggered even if the user no longer has access to their private key material (assuming that they backed up their revocation signature like they were encouraged to do!).

A user may however wish to RTBF their key without making it unusable by correspondents who already hold a copy, so we need to also designate one of the soft revocation types as an RTBF indicator. "User ID no longer valid" (0x20) has a standard interpretation when used in a UID/UAT revocation sig. Its use in a direct revocation signature is not common, but its extension to mean "All User IDs on this key are no longer valid" in that context is natural. Since a key with no valid User IDs is not usable, and revocation is permanent, it is not obviously wrong for a keyserver to infer that all User IDs should be deleted in this case.

If by contrast a user wanted to declare all her User IDs to be no longer valid, but NOT imply that they should be deleted, she can revoke them individually. If she were to change her mind in the future, she could still publish a redacting revocation as above.

Out of scope

This design cannot be used to delete a specific ID from a key, because the full (plaintext) contents of an ID packet are required to validate any sig over it. Once the ID packet was deleted, the sig would no longer validate and must be discarded as it would be indistinguishable from spam. This would then fail to prevent that ID from being resubmitted in the future.

A robust selective deletion would require an opaque reference to the User ID (e.g. a salted hash) to be added to a direct signature, however this would require changes to the OpenPGP standard.

Security considerations

If the user were to lose her private key material, she would no longer be able to generate a revocation signature (either redacting or non-redacting). To guard against this, users SHOULD generate a revocation signature at key generation time (this is the default behaviour of most clients) and ensure that it is safely backed up.

To better guard against unintended deletion, we could use a novel "Reason for revocation" value instead of "User ID no longer valid", however this may be overkill.

Compatibility

This will result in failure to recon completely with keyservers that do not support HIP 5. It will therefore break compatibility with sks-keyserver and older versions of Hockeypuck. However, it should be noted that there is in principle no solution to RTBF that does not involve a breaking change of similar impact.

References

Hard revocations: #250.
Soft revocations: #294.