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

[Alec Warner <antarus@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 3230 bytes --]

On Tue, Feb 19, 2019 at 3:16 PM Rich Freeman <rich0@gentoo.org> wrote:

> On Tue, Feb 19, 2019 at 3:01 PM Michał Górny <mgorny@gentoo.org> wrote:
> >
> > On Tue, 2019-02-19 at 19:47 +0000, Robin H. Johnson wrote:
> > >
> > > 3) would be good to detect on the less-active devs, and gives good
> > > life-signs to undertakers.
> >
> > Maybe.  However, we're practically talking about one-time check here.
> > Once the key is initially signed (and if the developer ignores GLEP 63
> > expiration suggestions), there will be no reason to mail him again.
>
> Until now this has seemed like something that didn't require any
> manual developer participation.
>

> 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. We currently allow any FP
in LDAP  with an @gentoo.org address to commit. This proposal just
standardizes it using existing tooling so that users can consume the trust
graph easily. The base proposal doesn't change any of the rules, just the
implementation; to make it *easier* for end users to use the authority
scheme. This is a net good for Gentoo, IMHO, as we should use and adopt
standards of the time. Our current authority scheme doesn't use CAFF and
does not verify gpg fingerprints in LDAP.

CAFF addresses a deficiency in the current system. Currently we don't
validate control over fingerprints in LDAP. This means once an attacker
gains LDAP access, they only need to add a key fingerprint to an LDAP
record in order to get their commits through the GPG verification process.

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.

I consider CAFF to be important (as something we should do) but not a
requirement (something we must do in order) in this implementation of the
authority scheme.


>
> 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.

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


> 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.

-A


>
> --
> Rich
>
>

[-- Attachment #2: Type: text/html, Size: 4509 bytes --]