Gentoo Archives: gentoo-dev

From: Rich Freeman <rich0@g.o>
To: gentoo-dev <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?
Date: Thu, 25 Apr 2019 22:30:56
In Reply to: Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard? by James Le Cuirot
1 On Thu, Apr 25, 2019 at 5:54 PM James Le Cuirot <chewi@g.o> wrote:
2 >
3 > if I understood it correctly, it only removes the primary private key
4 > from the online copy and not the entire primary key. The --list-keys
5 > option shows an [SC] primary with an [E] subkey and an [S] subkey and I
6 > gathered from a conversation in #gentoo-dev that this is correct. Are
7 > you suggesting the [SC] primary should not appear here at all?
9 No, the public key should remain in your keychain. It is, after all,
10 public, so there is no risk of compromise. You really want it to be
11 published as widely as possible actually to reduce the risk of
12 somebody using the wrong key.
14 >
15 > > Secondly, the reason for that is not (just) to have a backup
16 > > but that the primary private key gives you virtually unlimited control.
17 >
18 > Are you contradicting yourself here? You explained why the private key
19 > must be kept secure but you didn't say anything about the rest of the
20 > primary key.
22 The only keys you need to secure are the private keys. These keys are
23 created in public/private pairs always. In the case of our GLEP we
24 have three pairs: a primary, a signing, and an encryption. The
25 signing and encryption pairs are referred to as subkeys, but this is
26 just a convention - mathematically they work exactly the same.
27 Ideally you want all your keys to be secure, but the concept of having
28 tiered keys is that you can keep the primary in a safer place, since
29 it can be used to invalidate and issue new subkeys, and thus you don't
30 have to completely replace the trust chain if one key is compromised.
32 --
33 Rich