On Thu, 2019-04-25 at 07:32 -0400, Rich Freeman wrote: > The intent of the separate primary key is to reduce the risk of it > being compromised by keeping it offline. However, if it were > generated on a smartcard it would be exclusively be maintained > offline, so it is counterproductive to require that it be generated > online and then recommend that it be kept offline after this. > Additionally this key needs to be brought back online anytime the key > expiration is updated, which is at least annually.
You seem to be using 'offline' in two different meanings here. Yes, smartcard technically prevents the PC from *reading* the secret key material. However, it isn't really 'offline' as the PC can *use* the secret key material. In the scenario of Gentoo development, the primary use of the 'signing slot' key is to sign commits, pushes and messages, a lot. This means that for practical reasons you need to disable 'forcesig', or you'll have to repeatedly enter PIN for every commit made, for every message sent and twice for every push. If you include the extra delay due to that, and the necessity of rebasing, you may end up being unable to commit otherwise. Now, the smartcard can't (or doesn't -- I haven't looked into the details) distinguish the signing usage vs certification usage. In other words, once you unlock the key e.g. to sign a commit, any program can freely use the card to sign any key or subkey, without even raising your suspicion. To summarize, there is still a major benefit to keeping the primary key offline -- as in, not normally accessible to the system. Whether you do it via keeping the key on an offline system, on a dedicated smartcard that is normally disconnected or in a dedicated smartcard slot that requires PIN for *every* certification made, doesn't matter that much. However, when you open it to direct abuse when using it to sign commits, it is not 'offline'. -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part