How to handle a former employee's public GPG key?



  • In my keyring I have the public key of a former colleague. I have signed it, because I trusted that it was his key. I still do so, but the fact that he has left the company of course changes the nature of trust.

    So basically what I want is:

    • no new encryption operations should be possible with that key (especially important when they are executed by scripts)
    • signatures before his leave date should be considered valid, signatures after that date should be considered invalid

    The first thing I tried was editing the key (--edit-key) and setting the trust to none (2 = I do NOT trust). That does not even achieve the first requirement above. The opposite works if you have an unsigned key and set it to full trust. But obviously my signature is always stronger?

    I know I could delete my signature (delsig) but obviously that won't help with the second requirement.



    • no new encryption operations should be possible with that key (especially important when they are executed by scripts)

    The easiest way to do that is disabling his key in your keyring (and any keyrings accessible through the scripts). Do this in edit-key mode with the command disable. This will make the key no longer usable for encryption. I'd also suggest changing the scripts if they specify his key directly.

    • signatures before his leave date should be considered valid, signatures after that date should be considered invalid

    The first thing I tried was editing the key and setting the trust to none.

    I'm not clear on what trust setting "none" is, but you should set the key to Untrusted (edit-key, trust, 2 = I do NOT trust). As pointed out by Esa Jokinen, the date distinction is meaningless as timestamps are trivial to forge if he still has the private key. I would suggest generating a new key with a User ID something like "John Doe's [leave date] replacement signing Key" and using it to sign all items that were signed by John's original key prior to leave date.


Log in to reply
 

Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2