Skip to content

Commit

Permalink
keys/employees-keys/README.md: improve revocation procedure
Browse files Browse the repository at this point in the history 
This commit implements experimentally proved suggestion from review,
which consist of using last known safe date as expiration date for
revoked key. This lead that portals like Github show that key is both
revoked and expired despite keeping green label of verified signature
for git commits.

Signed-off-by: Piotr Król <[email protected]>
  • Loading branch information
@pietrushnic
pietrushnic committed Oct 17, 2023
1 parent 321fcad commit fbb2fa6
Show file tree
Hide file tree
Showing 3 changed files with 138 additions and 3 deletions.
Binary file added img/certify_key_revoked.png
View file
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added img/certify_key_revoked_commit.png
View file
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
141 changes: 138 additions & 3 deletions keys/employees-keys/README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -372,7 +372,7 @@ use.
### What to do when primary/master private key was lost, compromised or will no longer be used?

Following guide was made for:
- recovery in case of loosing access to you primary/master private key,
- recovery in case of loosing access to you main/primary/master private key,
- evidence of primary/master key compromise,
- event when employee of 3mdeb finished his/her cooperation and should no longer
sign 3mdeb related development work.
Expand Down Expand Up @@ -411,7 +411,134 @@ Where `KEYID` is the id of the key which you would like to revoke.
gpg --import [email protected]
```

#### Upload revoked key to the servers
#### Change expiration date

In situations where there's a potential compromise of a GPG key, it might be
necessary to change the expiration date of the key to the last known safe date.
This ensures that the key is no longer valid after the potential compromise,
adding an extra layer of securit.

Because last known safe date is in the past and we can set expiration date only
for future we have to change system time before we can proceed. Let's assume
our last safe date is 2023-10-06 07:08:03 PM.

```shell
sudo date 1005190823.03

This comment has been minimized.

Sign in to view

Copy link
@krystian-hebel

krystian-hebel Oct 17, 2023

Member

Not sure if you are aware of this, but date is very good at parsing human-readable dates. E.g. you can use sudo date -s "2023-10-05 07:08:03 PM", sudo date -s "5 days ago" or even sudo date -s "last Friday". This is much more readable than MMDDhhmmYY.ss you used.

Additionally:

  • please write that one day before safe date was used deliberately, it can be easily missed or considered to be a typo by reader,
  • mention that this is temporary, most distributions synchronize time with network time servers, e.g. on Fedora I get about 10 minutes before it resets to current time, but on Ubuntu it works only for a fraction of second (maybe there are other mechanisms that set it back to current time),
  • just in case please add service systemd-timesyncd restart at the end of instructions, or even better, use service systemd-timesyncd stop at the beginning and service systemd-timesyncd start at the end, which should fix the problem from the previous point.

This comment has been minimized.

Sign in to view

Copy link
@pietrushnic

pietrushnic Oct 17, 2023

Author Member

Not sure if you are aware of this, but date is very good at parsing human-readable dates.

@krystian-hebel Yes, I've been using Linux for more than 20 years. And maybe because of that, providing input in a more complex format is not an issue for me.

  • Fix for date input format: 354deb5
  • Fix for a precise explanation of why I used one day before: ff69cb7

mention that this is temporary, most distributions synchronize time with network time servers, e.g. on Fedora I get about 10 minutes before it resets to current time, but on Ubuntu it works only for a fraction of second (maybe there are other mechanisms that set it back to current time),

Fix for that is here: c9b2346

just in case please add service systemd-timesyncd restart at the end of instructions, or even better, use service systemd-timesyncd stop at the beginning and service systemd-timesyncd start at the end, which should fix the problem from the previous point.

Added despite I cannot test that because Qubes OS AppVMs use different mechanisms for time synchronization: c9e43c9

This comment has been minimized.

Sign in to view

Copy link
@pietrushnic

pietrushnic Oct 18, 2023

Author Member

@krystian-hebel ping?

This comment has been minimized.

Sign in to view

Copy link
@pietrushnic

pietrushnic Oct 24, 2023

Author Member

@krystian-hebel ping v2?

This comment has been minimized.

Sign in to view

Copy link
@krystian-hebel

krystian-hebel Oct 25, 2023

Member

minimum expiration period to set in gpg is 1d (one day)

Technically not true: https://stackoverflow.com/questions/55051062/is-it-possible-to-set-gpg-key-expiration-time-shorter-than-one-day-say-an-hour - I think we should use 1d because it is easier, but please change the description.

Sorry about the delay, I was sure I replied to this already...

This comment has been minimized.

Sign in to view

Copy link
@pietrushnic

pietrushnic Oct 25, 2023

Author Member

Damn! This is like chasing ghosts. Undocumented param format, jeez gpg makes things difficult, and maybe really switching to sequoia will be a better option.

gpg> key 1

sec  rsa4096/035FFF499CFA7026
     created: 2023-10-25  expires: never       usage: C   
     trust: ultimate      validity: ultimate
ssb* rsa4096/EA383577AD04B33C
     created: 2023-10-25  expires: 2024-10-24  usage: S   
ssb  rsa4096/5FA5130A782665DD
     created: 2023-10-25  expires: 2024-10-24  usage: E   
[ultimate] (1). Your Name (Employee Cert Key) <[email protected]>

gpg> expire
Changing expiration time for a subkey.
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0) 20231212T121212
Key expires at Tue 12 Dec 2023 01:12:12 PM CET
Is this correct? (y/N) y

sec  rsa4096/035FFF499CFA7026
     created: 2023-10-25  expires: never       usage: C   
     trust: ultimate      validity: ultimate
ssb* rsa4096/EA383577AD04B33C
     created: 2023-10-25  expires: 2023-12-12  usage: S   
ssb  rsa4096/5FA5130A782665DD
     created: 2023-10-25  expires: 2024-10-24  usage: E   
[ultimate] (1). Your Name (Employee Cert Key) <[email protected]>

Fix: 180bb39

This comment has been minimized.

Sign in to view

Copy link
@krystian-hebel

krystian-hebel Oct 26, 2023

Member

Approved. I don't think I can mark this as resolved as it isn't technically part of the review.

This comment has been minimized.

Sign in to view

Copy link
@pietrushnic

pietrushnic Oct 26, 2023

Author Member

Thank you.
```

Now let's expire our main and associated subkeys:

```shell
gpg --edit-key KEYID
```

Procedure should look as follows:

```
gpg (GnuPG) 2.2.40; Copyright (C) 2022 g10 Code GmbH
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
sec rsa4096/8895D29C1B822905
created: 2023-05-05 expires: never usage: C
trust: ultimate validity: ultimate
ssb rsa4096/1B1C3210563730D9
created: 2023-05-05 expires: 2024-05-04 usage: S
ssb rsa4096/1F97D67F4B465248
created: 2023-05-05 expires: 2024-05-04 usage: E
[ultimate] (1). Your Name (Employee Cert Key) <[email protected]>
gpg> expire
Changing expiration time for the primary key.
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) 1d
Key expires at Fri 06 Oct 2023 07:08:05 PM CEST
Is this correct? (y/N) y
sec rsa4096/8895D29C1B822905
created: 2023-05-05 expires: 2023-10-06 usage: C
trust: ultimate validity: ultimate
ssb rsa4096/1B1C3210563730D9
created: 2023-05-05 expires: 2024-05-04 usage: S
ssb rsa4096/1F97D67F4B465248
created: 2023-05-05 expires: 2024-05-04 usage: E
[ultimate] (1). Your Name (Employee Cert Key) <[email protected]>
gpg> key 1
sec rsa4096/8895D29C1B822905
created: 2023-05-05 expires: 2023-10-06 usage: C
trust: ultimate validity: ultimate
ssb* rsa4096/1B1C3210563730D9
created: 2023-05-05 expires: 2024-05-04 usage: S
ssb rsa4096/1F97D67F4B465248
created: 2023-05-05 expires: 2024-05-04 usage: E
[ultimate] (1). Your Name (Employee Cert Key) <[email protected]>
gpg> expire
Changing expiration time for a subkey.
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) 1d
Key expires at Fri 06 Oct 2023 07:08:20 PM CEST
Is this correct? (y/N) y
sec rsa4096/8895D29C1B822905
created: 2023-05-05 expires: 2023-10-06 usage: C
trust: ultimate validity: ultimate
ssb* rsa4096/1B1C3210563730D9
created: 2023-05-05 expires: 2023-10-06 usage: S
ssb rsa4096/1F97D67F4B465248
created: 2023-05-05 expires: 2024-05-04 usage: E
[ultimate] (1). Your Name (Employee Cert Key) <[email protected]>
gpg> key 2
sec rsa4096/8895D29C1B822905
created: 2023-05-05 expires: 2023-10-06 usage: C
trust: ultimate validity: ultimate
ssb* rsa4096/1B1C3210563730D9
created: 2023-05-05 expires: 2023-10-06 usage: S
ssb* rsa4096/1F97D67F4B465248
created: 2023-05-05 expires: 2024-05-04 usage: E
[ultimate] (1). Your Name (Employee Cert Key) <[email protected]>
gpg> expire
Are you sure you want to change the expiration time for multiple subkeys? (y/N) y
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) 1d
Key expires at Fri 06 Oct 2023 07:08:35 PM CEST
Is this correct? (y/N) y
sec rsa4096/8895D29C1B822905
created: 2023-05-05 expires: 2023-10-06 usage: C
trust: ultimate validity: ultimate
ssb* rsa4096/1B1C3210563730D9
created: 2023-05-05 expires: 2023-10-06 usage: S
ssb* rsa4096/1F97D67F4B465248
created: 2023-05-05 expires: 2023-10-06 usage: E
[ultimate] (1). Your Name (Employee Cert Key) <[email protected]>
gpg> save
```

#### Upload revoked and expired key to the servers

Following this set of commands assumes that the machine on which you applied revocation
and machine on which you publish revoked key are different. If it is not the case,
Expand Down Expand Up @@ -455,7 +582,15 @@ procedure](#adding-key-to-repository).

#### Gitlab, Github and Gitea revocation

Go to all wesbites, upload your new public key and delete old one.
Go to all wesbites wher you used your GPG key. Delete key which you revoked and
expired. After deleting upload key which contain revocation and expiration
signature. On Github it should look as follows:

![](/img/certify_key_revoked.png)

Commits should looks as follows:

![](/img/certify_key_revoked_commit.png)

#### Obtain list of keys you signed

Expand Down

0 comments on commit fbb2fa6

Please sign in to comment.