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? |
8 |
|
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. |
13 |
|
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. |
21 |
|
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. |
31 |
|
32 |
-- |
33 |
Rich |