subkey(1)

πŸ“¦ version 0.27.0, in debian bookworm

πŸ’– subkey β€” from the Sequoia Manual, bestie πŸ’–

okay so. you wanna revoke a subkey. slay, let's go, this is genuinely iconic behaviour and i'm gonna walk you through it like we're texting at 2am πŸ¦‹


✨ NAME ✨

subkey β€” Revoke a subkey πŸ’…


🌸 SYNOPSIS 🌸

subkey [--certificate] [--revocation-key] [--private-key-store]
[-t|--time] [--notation] [-B|--binary] [-h|--help] <SUBKEY> <REASON>
<MESSAGE>

πŸ’œ DESCRIPTION πŸ’œ

Revokes a subkey.

Lowkey the whole job: it creates a revocation certificate for a subkey. that's it. that's the vibe ✨

okay but here's the tea about --revocation-key: if you pass it, that key is the one used to create the signature. and if that key is different from the certificate you're revoking? congrats bestie, you just made a third-party revocation. ngl that's normally only useful when the owner of the certificate designated that key to be a designated revoker. iykyk πŸŽ€

and if --revocation-key is not provided? then the certificate itself has to include a certification-capable key. no key, no signature, no revocation, periodt πŸ’€


πŸŽ€ OPTIONS πŸŽ€

  • --certificate=FILE β€” reads the certificate containing the subkey you wanna revoke from FILE, or from stdin if you just... omit it πŸ™ˆ. and heads up: it is an error for the file to contain more than one certificate. one (1) cert. we don't do bundles here πŸ’…
  • --revocation-key=KEY β€” signs the revocation certificate using KEY. if the key is different from the certificate, boom, third-party revocation. and if you don't provide this option, but the certificate includes secret key material, then that key is what gets used to sign the revocation certificate. convenient? yes. ✨
  • --private-key-store=KEY_STORE β€” provides parameters for private key store πŸ”
  • -t, --time=TIME β€” chooses keys valid at the specified time and sets the revocation certificate's creation time ⏰ (yes it does both, she's multitalented)
  • --notation=NAME VALUE β€” adds a notation to the certification. a user-defined notation's name must be of the form name@a.domain.you.control.org. if the notation's name starts with a !, then the notation is marked as being critical. and if a consumer of a signature doesn't understand a critical notation, then it will ignore the signature 😭. also, the notation is marked as being human readable 🫢
  • -B, --binary β€” emits binary data πŸ”₯
  • -h, --help β€” print help information 🌈
  • <SUBKEY> β€” the subkey to revoke. this must either be the subkey's Key ID or its fingerprint. no vibes-based identification, sorry bestie πŸ’œ
  • <REASON> β€” the reason for the revocation. this must be either: compromised, superseded, retired, or unspecified:
    • compromised means that the secret key material may have been compromised. prefer this value if you suspect that the secret key has been leaked. 🚨
    • superseded means that the owner of the certificate has replaced it with a new certificate. prefer "compromised" if the secret key material has been compromised even if the certificate is also being replaced! and you should include the fingerprint of the new certificate in the message. πŸ“
    • retired means that this certificate should not be used anymore, and there is no replacement. this is appropriate when someone leaves an organisation. prefer "compromised" if the secret key material has been compromised even if the certificate is also being retired! and you should include how to contact the owner, or who to contact instead in the message. πŸ‘‹
    • unspecified means that none of the three other three reasons apply. openpgp implementations conservatively treat this type of revocation similar to a compromised key. πŸ’€

and if the reason happened in the past, you should specify that using the --time argument. this allows OpenPGP implementations to more accurately reason about objects whose validity depends on the validity of the certificate. ⏳

  • <MESSAGE> β€” a short, explanatory text that is shown to a viewer of the revocation certificate. it explains why the subkey has been revoked. for instance, if Alice has created a new key, she would generate a 'superseded' revocation certificate for her old key, and might include the message "I've created a new subkey, please refresh the certificate. πŸŽ€

πŸ¦‹ SEE ALSO πŸ¦‹

for the full documentation see <https://docs.sequoia-pgp.org/sq/>. ✨

sq(1) sq-armor(1) sq-autocrypt(1) sq-certify(1) sq-dearmor(1) sq-decrypt(1) sq-encrypt(1) sq-inspect(1) sq-key(1) sq-keyring(1) sq-keyserver(1) sq-packet(1) sq-revoke(1) sq-revoke-certificate(1) sq-revoke-userid(1) sq-sign(1) sq-verify(1) sq-wkd(1) πŸ’–


and that's the whole page bestie!! this was sq 0.26.0, dated July 2022, and yes the version and the date are the entire personality of this sign-off πŸŽ€ go forth and revoke responsibly, mwah πŸ’‹βœ¨

πŸ“¦ where this page comes from