1

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.

Improve this question
2
  • 2
    "signatures before his leave date should be considered valid, signatures after that date should be considered invalid" doesn't make sense: anyone with the private key can easily forge the timestamp.
    – Esa Jokinen
    Commented Jun 20, 2021 at 16:01
  • "anyone with the private key can easily forge the timestamp" is a valid point
    – Uwe Geuder
    Commented Jun 20, 2021 at 16:03

2 Answers 2

Reset to default
1
  • 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.

Improve this answer
1
  • Thanks, updated my question with explicit syntax. I had missed the disable subcommand; it does the job. The re-signing seems to be the only secure approach. This needs to be taken into account when setting up a signing scheme in a company so that on day X it is easy to find all signed items. Re-signing git commits does not seem to be a good option, SHA-1s of released software would change. Instead a commit "terminating" validity of the signature in question could be added to the tip of every branch. But then you need extra tooling to verify signatures. Not easy...
    – Uwe Geuder
    Commented Jun 22, 2021 at 9:22
0

This may be a hassle, but you could re-sign all his previous "commits" (up to a certain date), and omit his own signature. This is something that could be automated. Effectively, you are "demoting" the previous trust there was.

And of course the old private key of his should be retired and out of reach so it cannot be used anymore. I suggest archiving it to offline storage. In fact, you should have backups of your private keys right ?

This is the condition to satisfy this requirement:

no new encryption operations should be possible with that key

But he might have retained a copy of the private key, so who knows for sure ? Then he could still use that key to sign stuff.

It all depends on what you are trying to achieve.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .