Change Details

Contrary to T2960, a careful reading of RFC 4880 will show that public keys are allowed to have all of their user IDs revoked, so long as at least one of the revoked UIDs are transferred. The requirement merely states that at least one user ID packet, regardless of revocation status, is present. To stay in compliance, GnuPG could simply preserve the most recently-revoked UID in the same manner as it would the final UID. Note, by the way, that it is trivial to have GnuPG violate this requirement already by using export filters. Making a key with no unrevoked UIDs may seem pointless at first, and indeed it is best locked behind `--expert`, but I have encountered an important reason to do so. I use a "main" primary keypair for most things, as well as "secondary" primary keypairs for specific roles. For instance, I have a secondary keypair with my work email as its UID, which is used solely as part of my job (mainly for signing Git commits). If I stop being employed, that email and identity will no longer be accessible by me, the key holder. RFC 4880 **explicitly** uses this scenario as an example of [[ https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.3.23 | when to revoke a signature ]], so the correct way to indicate this is obviously revoking the self-signature on the UID. Under this scenario, anyone checking for an updated copy of that key will be able to see quite clearly that it is no longer being used in that capacity, as the UID has been revoked. However, if I return to that job in the future and regain access to that email, I will be able to use the still-valid keypair to add the UID back. In contrast, revoking the entire keypair would require me to generate a new key from scratch when returning. Key transitions are often difficult, but they are borderline impossible when the replacement key is not known at the time of revoking the old key. Encryption keys used for work email would be particularly thorny, as I'd have to convince others to encrypt for the new key without using the old key to vouch for it. The other option currently allowed by GnuPG, allowing the secondary key to expire without revoking it, introduces problems for anyone trying to refresh their copy: they would be unable to tell whether I have stopped using it or simply have a newer copy in a place they cannot see. In summary, it is useful to communicate that a key holder no longer uses any associated identities, while allowing for identities to be added back in the future, and communicating that the key is nevertheless still valid in the interim.

As noted by T2960, a careful reading of RFC 4880 will show that public keys are allowed to have all of their user IDs revoked, so long as at least one of the revoked UIDs are transferred. The requirement merely states that at least one user ID packet, regardless of revocation status, is present. To stay in compliance, GnuPG could simply preserve the most recently-revoked UID in the same manner as it would the final UID. Note, by the way, that it is trivial to have GnuPG violate this requirement already by using export filters. Making a key with no unrevoked UIDs may seem pointless at first, and indeed it is best locked behind `--expert`, but I have encountered an important reason to do so. I use a "main" primary keypair for most things, as well as "secondary" primary keypairs for specific roles. For instance, I have a secondary keypair with my work email as its UID, which is used solely as part of my job (mainly for signing Git commits). If I stop being employed, that email and identity will no longer be accessible by me, the key holder. RFC 4880 **explicitly** uses this scenario as an example of [[ https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.3.23 | when to revoke a signature ]], so the correct way to indicate this is obviously revoking the self-signature on the UID. Under this scenario, anyone checking for an updated copy of that key will be able to see quite clearly that it is no longer being used in that capacity, as the UID has been revoked. However, if I return to that job in the future and regain access to that email, I will be able to use the still-valid keypair to add the UID back. In contrast, revoking the entire keypair would require me to generate a new key from scratch when returning. Key transitions are often difficult, but they are borderline impossible when the replacement key is not known at the time of revoking the old key. Encryption keys used for work email would be particularly thorny, as I'd have to convince others to encrypt for the new key without using the old key to vouch for it. The other option currently allowed by GnuPG, allowing the secondary key to expire without revoking it, introduces problems for anyone trying to refresh their copy: they would be unable to tell whether I have stopped using it or simply have a newer copy in a place they cannot see. In summary, it is useful to communicate that a key holder no longer uses any associated identities, while allowing for identities to be added back in the future, and communicating that the key is nevertheless still valid in the interim.

Contrary toAs noted by T2960, a careful reading of RFC 4880 will show that public keys are allowed to have all of their user IDs revoked, so long as at least one of the revoked UIDs are transferred. The requirement merely states that at least one user ID packet, regardless of revocation status, is present. To stay in compliance, GnuPG could simply preserve the most recently-revoked UID in the same manner as it would the final UID. Note, by the way, that it is trivial to have GnuPG violate this requirement already by using export filters. Making a key with no unrevoked UIDs may seem pointless at first, and indeed it is best locked behind `--expert`, but I have encountered an important reason to do so. I use a "main" primary keypair for most things, as well as "secondary" primary keypairs for specific roles. For instance, I have a secondary keypair with my work email as its UID, which is used solely as part of my job (mainly for signing Git commits). If I stop being employed, that email and identity will no longer be accessible by me, the key holder. RFC 4880 **explicitly** uses this scenario as an example of [[ https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.3.23 | when to revoke a signature ]], so the correct way to indicate this is obviously revoking the self-signature on the UID. Under this scenario, anyone checking for an updated copy of that key will be able to see quite clearly that it is no longer being used in that capacity, as the UID has been revoked. However, if I return to that job in the future and regain access to that email, I will be able to use the still-valid keypair to add the UID back. In contrast, revoking the entire keypair would require me to generate a new key from scratch when returning. Key transitions are often difficult, but they are borderline impossible when the replacement key is not known at the time of revoking the old key. Encryption keys used for work email would be particularly thorny, as I'd have to convince others to encrypt for the new key without using the old key to vouch for it. The other option currently allowed by GnuPG, allowing the secondary key to expire without revoking it, introduces problems for anyone trying to refresh their copy: they would be unable to tell whether I have stopped using it or simply have a newer copy in a place they cannot see. In summary, it is useful to communicate that a key holder no longer uses any associated identities, while allowing for identities to be added back in the future, and communicating that the key is nevertheless still valid in the interim.