Re: [gentoo-project] Call for agenda items - Council meeting 2019-05-12

[Rich Freeman]

On Mon, Apr 29, 2019 at 11:10 AM Matthew Thode
<prometheanfire@g.o> wrote:
>
> On 19-04-28 21:46:24, Rich Freeman wrote:
> > On Sun, Apr 28, 2019 at 6:42 PM Thomas Deutschmann <whissi@g.o> wrote:
> > >
> > > Please respond to this message with agenda items. Do not hesitate to
> > > repeat your agenda item here with a pointer if you previously
> > > suggested one (since the last meeting).
> > >
> >
> > I would like the council to consider my patch to GLEP 63 to allow a
> > single combined primary/signing key when the key is stored on a
> > smartcard, so that keys may be generated on a Nitrokey without relying
> > on a primary key maintained offline in software, which I think will
> > not happen much in practice.  This should increase the security of
> > signing keys by reducing handling or even storage of primary keys on
> > internet-connected hosts (which the GLEP already allows for).
> >
> > Patch and discussion at:
> > https://archives.gentoo.org/gentoo-dev/message/d05070a200e4f5858642d308d9b3e39f
>
> My main concern here is devs needing to re-establish their keys with
> infra in a trusted maner when the key is lost/stolen or otherwise
> defunct.  Re-establishing that trust may be outside the scope of this
> request though.
>

Probably better to discuss in the other thread, but re-establishing
the key is just a matter of logging into dev.gentoo.org and changing
your fingerprint.  I just did it the other week to create a new key
for the nitrokey.  That issue exists with software keys as well,
though I will concede that it is possible to back up a software key,
and it is not possible to do this if it is generated on a smartcard.

The main downsides to having your primary key generated on a smartcard
and losing it are:
1. You do need to generate a new key and change the fingerprint on
dev.gentoo.org.  In practice the root of our security isn't actually
the gpg key but the ssh key, and ldap password.
2. You lose any WoT signatures from other devs or individuals on your
gpg key.  You will regain the signoff from infra when you change your
key in LDAP.
3. You lose the ability to decrypt any data that you are storing
encrypted to your lost key.  If you do use the key for encryption then
it would be better to either have a backup for this key, or to archive
this data unencrypted or encrypted with a key you can recover (the
latter isn't an equivalent problem, because you can encrypt that using
a key you never need to routinely use, and can also choose to encrypt
that data with multiple keys so that even if stored on hardware you
could have backups in practice).

I will also note, that the current GLEP already allows generating
primary keys on a smartcard, and thus already exposes us to the issue
of key loss without the possibility of backups.  It just requires two
different smartcards to accomplish, unless there is some way to hack
gpg to use an authentication key for the signing or primary role.  The
change is to allow a single combined primary/signing key when it is
generated on hardware, the existing policy says nothing about
maintaining backups of the primary key.

I would really suggest that the hardware-only key is most appropriate
when you're only signing commits, and not depending on a WoT.
However, in practice for most devs I think this is going to end up
being more secure than how they would otherwise end up managing their
keys (either not using hardware at all, or keeping their primary key
online, which basically defeats the point of having the hardware).

-- 
Rich