Re: [gentoo-project] [RFC] OpenPGP Authority Keys to provide validity of developer/service keys

[Rich Freeman <rich0@gentoo.org>]

On Tue, Feb 19, 2019 at 4:54 PM Alec Warner <antarus@gentoo.org> wrote:
> On Tue, Feb 19, 2019 at 3:16 PM Rich Freeman <rich0@gentoo.org> wrote:
>>
>> Now it is sounding like a proposal that both requires manual
>> participation, and may also require manual updating, to avoid
>> undertaking.
>
>
> The authority scheme is *already* in use today.

I'm referring to the need to do CAFF, not the need to have a gpg key in LDAP.

> With CAFF, the attacker has more work to do because CAFF will make
> the attacker show ownership of the private portion of the keypair
> before we grant it authority. This has some benefit as it makes it
> more likely for the attacker to make a mistake and get caught, or
> leave a trail for us to find. If they fail CAFF (e.g. use the wrong
> key) or commit without a CAFF key, we can use those as signals to
> detect tampering and intrusion.

Why would an attacker replace a key in LDAP with one they don't control?

If they control LDAP, then they control the @gentoo.org email address
already, should they exercise this control.  That means they can
redirect the email, change the key, obtain their signature, and upload
their signature.  That is more steps, but not more security.

>> It seems like it would make far more sense to look at other direct
>> measures of activity than how up-to-date their gpg key is in the
>> keyservers.
>
> I'm bad at GPG. However, I believe updating my keys to adapt to the policy took me about 30 minutes. Its required once every 12 months.

Updating your keys is a one-liner with a shell script.  It doesn't not
require messing with emails.  Sure, shell-scripting email isn't
impossible, but I don't see what value it adds.

You can already test whether devs are updating their gpg keys or not
without messing with CAFF.

>
> Where should we set the bar here, if not "please contribute at least 30 minutes every year to retain your developership."

How about doing ACTUAL activity?  Not make-work?

If somebody is actually doing commits in the tree, you know they're
active and don't need them to jump through some additional hoops.

And of course there are other types of activity where git signing keys
aren't needed, and thus those hoops don't even add value in the first
place, and where that other activity could be measured (number of
forum logins/posts/whatevers, and so on).

>
>>
>> Also, as far as I'm aware GLEP 63 does not require an encryption key
>> at all, just a signing key.  I'm not sure if such signing-keys will be
>> signed by Gentoo under this proposal.  If not then there is nothing to
>> upload to the keyserver, and in any case it seems like the main use
>> case of this (sending encrypted email) would not apply.  Of course it
>> could still be used for verifying email signatures if we sign
>> signing-only keys.
>
> This does seem like a gap.
>

Only if you make it into one.  If some dev has zero interest in
receiving gpg-encrypted mail, encouraging people to gpg-encrypt mail
to them just means that their mail goes to /dev/null, especially if
they have their mail clients configured to auto-encrypt stuff.

I mean, if I'm in infra and somebody needs to mail me the root keys to
some box I can see the point in it, but 99% of what would get
encrypted is stuff that could probably get by just being clear signed.

-- 
Rich