1 |
On 2019-04-25 12:32, Rich Freeman wrote: |
2 |
|
3 |
> The OpenPGP smartcard standard, and the Nitrokey Pro smartcards that |
4 |
> are being distributed to Gentoo developers, do not support having a |
5 |
> separate primary/signing key for keys that are generated on the cards. |
6 |
> As a result they can only be used in accordance with our current |
7 |
> requirements if the keys are generated in software, which places them |
8 |
> at a higher risk of compromise. |
9 |
> |
10 |
> The intent of the separate primary key is to reduce the risk of it |
11 |
> being compromised by keeping it offline. However, if it were |
12 |
> generated on a smartcard it would be exclusively be maintained |
13 |
> offline, so it is counterproductive to require that it be generated |
14 |
> online and then recommend that it be kept offline after this. |
15 |
> Additionally this key needs to be brought back online anytime the key |
16 |
> expiration is updated, which is at least annually. |
17 |
> |
18 |
> I believe this is creating a false sense of security, and that |
19 |
> developers should be encouraged to generate new keys using their |
20 |
> smartcards, so that these keys are never stored outside the protected |
21 |
> hardware. By default gpg creates revocation certificates at this time |
22 |
> as well. If a key is lost it can still be revoked, and of course the |
23 |
> gpg fingerprint associated with the developer can be changed in any |
24 |
> case and is the de-facto root of our trust system. These failure |
25 |
> modes really are no different from an offline primary key that is |
26 |
> separate from the signing keys. |
27 |
> |
28 |
> The revision adds an exception for keys generated on a smartcard. |
29 |
|
30 |
I very much oppose this change, see my comments in the "Best way to |
31 |
create a GLEP 63 compliant GPG key on Nitrocard?" thread for details. |
32 |
|
33 |
Regarding the very accurate comment that requiring a separate primary |
34 |
key does not guarantee said primary key is handled securely - I know it |
35 |
might be overly optimistic of me but I kind of expect developers of a |
36 |
mainstream Linux distribution to be able to grasp and follow OpenPGP |
37 |
best practices. |
38 |
|
39 |
Incidentally, having been using smartcards of various sort in my |
40 |
workflows for 5+ years now I find their most obvious benefit is not that |
41 |
they store crypto keys securely but that they make the use of keys *more |
42 |
convenient*. Worried about persistence of the private key on your drive, |
43 |
especially on a shared system? Remove the card and the key is |
44 |
inaccessible, and since it was never handled by the system itself there |
45 |
should be no traces of it even in RAM. Fed up with resetting user |
46 |
passwords being a significant part of your sysadmin duties due to some |
47 |
people seemingly being unable to retain "at least 16 characters long and |
48 |
a minimum 3 character classes" in their wetware? Smartcard PINs can be |
49 |
much shorter because smartcards can lock up after a fairly small number |
50 |
of having entered the PIN wrong. In fact, although the official Gentoo |
51 |
rationale for the use of Nitrokeys as stated on the relevant Wiki page |
52 |
is that it makes the signing keys more secure, the recommendation to |
53 |
disable forcesig does hint at the ease-of-use factor as well. |
54 |
|
55 |
|
56 |
-- |
57 |
MS |