[gentoo-dev] [PATCH] glep-0063: Allow a single primary/signing key for smartcards

[Rich Freeman]

The OpenPGP smartcard standard, and the Nitrokey Pro smartcards that
are being distributed to Gentoo developers, do not support having a
separate primary/signing key for keys that are generated on the cards.
As a result they can only be used in accordance with our current
requirements if the keys are generated in software, which places them
at a higher risk of compromise.

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.

I believe this is creating a false sense of security, and that
developers should be encouraged to generate new keys using their
smartcards, so that these keys are never stored outside the protected
hardware.  By default gpg creates revocation certificates at this time
as well.  If a key is lost it can still be revoked, and of course the
gpg fingerprint associated with the developer can be changed in any
case and is the de-facto root of our trust system.  These failure
modes really are no different from an offline primary key that is
separate from the signing keys.

The revision adds an exception for keys generated on a smartcard.  It
does not prohibit those who wish to have separate keys from doing so,
though doing this with card-generated keys requires having two
smartcards.

An obvious objection I can see is that nobody will be able to tell
whether any particular key was generated on a smartcard or not.  While
this is true, it is also the case that there is no way to verify that
a primary key is being stored offline, or used on a non-compromised
PC, or that it even has a passphrase set.  Unless we want to use some
kind of hardware key that supports remote attestation we're going to
have to trust developers to be security conscious, and IMO making it
easy to generate keys on smartcards actually will facilitate security.
This change actually makes the more secure mode of operation simpler
than the less secure one (unless the primary key is kept online, in
which case it provides no benefit).

Full version online at:
https://gist.github.com/rich0/7d11e2297d8b8a5586997baec2a99e30

Patch follows:


diff --git a/glep-0063-v3.rst b/glep-0063-v3.rst
index 5895873..86e5fd9 100644
--- a/glep-0063-v3.rst
+++ b/glep-0063-v3.rst
@@ -12,6 +12,12 @@ OpenPGP key management policies for the Gentoo
Linux distribution.
 Changes
 =======

+v3
+  The requirement to have a separate signing and primary key was removed
+  in the case of keys generated/stored on smartcards, to encourage the use
+  of these keys, and acknowledging that the main use case for a separate
+  primary key is largely fulfilled by having all the keys stay offline.
+
 v2
   The distinct minimal and recommended expirations have been replaced
   by a single requirement. The rules have been simplified to use
@@ -69,7 +75,8 @@ not be used to commit.
    at least 256-bit.  All subkey self-signatures must use this digest.

 2. Signing subkey that is different from the primary key, and does not
-   have any other capabilities enabled.
+   have any other capabilities enabled.  This requirement does not apply
+   if the primary key was generated on a smartcard.

 3. Primary key and the signing subkey are both of type EITHER:


-- 
Rich