Gentoo Archives: gentoo-dev

From: Rich Freeman <rich0@g.o>
To: gentoo-dev <gentoo-dev@l.g.o>
Subject: [gentoo-dev] [PATCH] glep-0063: Allow a single primary/signing key for smartcards
Date: Thu, 25 Apr 2019 11:32:23
1 The OpenPGP smartcard standard, and the Nitrokey Pro smartcards that
2 are being distributed to Gentoo developers, do not support having a
3 separate primary/signing key for keys that are generated on the cards.
4 As a result they can only be used in accordance with our current
5 requirements if the keys are generated in software, which places them
6 at a higher risk of compromise.
8 The intent of the separate primary key is to reduce the risk of it
9 being compromised by keeping it offline. However, if it were
10 generated on a smartcard it would be exclusively be maintained
11 offline, so it is counterproductive to require that it be generated
12 online and then recommend that it be kept offline after this.
13 Additionally this key needs to be brought back online anytime the key
14 expiration is updated, which is at least annually.
16 I believe this is creating a false sense of security, and that
17 developers should be encouraged to generate new keys using their
18 smartcards, so that these keys are never stored outside the protected
19 hardware. By default gpg creates revocation certificates at this time
20 as well. If a key is lost it can still be revoked, and of course the
21 gpg fingerprint associated with the developer can be changed in any
22 case and is the de-facto root of our trust system. These failure
23 modes really are no different from an offline primary key that is
24 separate from the signing keys.
26 The revision adds an exception for keys generated on a smartcard. It
27 does not prohibit those who wish to have separate keys from doing so,
28 though doing this with card-generated keys requires having two
29 smartcards.
31 An obvious objection I can see is that nobody will be able to tell
32 whether any particular key was generated on a smartcard or not. While
33 this is true, it is also the case that there is no way to verify that
34 a primary key is being stored offline, or used on a non-compromised
35 PC, or that it even has a passphrase set. Unless we want to use some
36 kind of hardware key that supports remote attestation we're going to
37 have to trust developers to be security conscious, and IMO making it
38 easy to generate keys on smartcards actually will facilitate security.
39 This change actually makes the more secure mode of operation simpler
40 than the less secure one (unless the primary key is kept online, in
41 which case it provides no benefit).
43 Full version online at:
46 Patch follows:
49 diff --git a/glep-0063-v3.rst b/glep-0063-v3.rst
50 index 5895873..86e5fd9 100644
51 --- a/glep-0063-v3.rst
52 +++ b/glep-0063-v3.rst
53 @@ -12,6 +12,12 @@ OpenPGP key management policies for the Gentoo
54 Linux distribution.
55 Changes
56 =======
58 +v3
59 + The requirement to have a separate signing and primary key was removed
60 + in the case of keys generated/stored on smartcards, to encourage the use
61 + of these keys, and acknowledging that the main use case for a separate
62 + primary key is largely fulfilled by having all the keys stay offline.
63 +
64 v2
65 The distinct minimal and recommended expirations have been replaced
66 by a single requirement. The rules have been simplified to use
67 @@ -69,7 +75,8 @@ not be used to commit.
68 at least 256-bit. All subkey self-signatures must use this digest.
70 2. Signing subkey that is different from the primary key, and does not
71 - have any other capabilities enabled.
72 + have any other capabilities enabled. This requirement does not apply
73 + if the primary key was generated on a smartcard.
75 3. Primary key and the signing subkey are both of type EITHER:
78 --
79 Rich