From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 379FE138334 for ; Tue, 19 Feb 2019 21:55:00 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E69C1E086E; Tue, 19 Feb 2019 21:54:58 +0000 (UTC) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 5CAB2E07D0 for ; Tue, 19 Feb 2019 21:54:57 +0000 (UTC) Received: by mail-lj1-x232.google.com with SMTP id d14so7781408ljl.9 for ; Tue, 19 Feb 2019 13:54:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gentoo-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=z9Za/+4ZKkVoGaSgrXKElCzmrftghcNTBGTaTvfJeIk=; b=CoqEaCJ3wlbRJo3weLfhv2WQ1UEy/RY+9s+H00r+80U2nBy/WqeKWrlanABEtdRwct g1OHYI0WzLvVRnLYZglFpdxtG7hiNQ6wkOo13cFYh6t98cluP11duxthy8iuSB9PNPkW 1139OlnicWUJmd0rsnK6edJoXI2uwm5nbIEPmLhoSBg9zL1KL1T7KyPH14xkwaoGRIou md/nOFAiBYhv8tIfzpi/D9ALEIDo1Rb3CSvfcWakIxyuyWJ4ILOrFg4q4F5dkkJlLC+g CT26sO22yeBBNPPnNPgmUkRmDlE1VQb6Y2MnQKXBVDasOF0hulX/chHB0UiSvz3CHwe0 wdaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=z9Za/+4ZKkVoGaSgrXKElCzmrftghcNTBGTaTvfJeIk=; b=O+Ec5rbTxjzvlOCCT90rcQNQmDkK5GsBpLvyyHnAsp8Av9NY/uAuHJGDlgQWNxHU5u sE40ZuvC+CYeXROZt9n4CcqwPSbj2SGeZLxcdhaVCiMW9jK+9xK+jMm+o+HthUjxf5aW w3J76voY/hQ1ywwvmux6CfaHFKt69p/jWoOPth93qdZlowYaCm9tYtmSvaInVyMPry6s pxxYhj7P2Q3YnglSxpf95e2pMDwmVo8B9cXI9JptI3xXgyAYJHo8NS+GWs8wkksYk16B ayMsNvZB9PhorQxnpZIkbfIe0Y1RVMgSjabFaxigEFEd4oVq3hycTS84M+E8wOmz3OII e/CQ== X-Gm-Message-State: AHQUAuaCWX2V9SDKlBFn16xFzT1hLQ4+X2mghGueXq8kosH0NAdBJ5hf h9gLihBlkJ8GklC3QwNhdLnK2HQwQRrvA8Ore8w4OIpozFo= X-Google-Smtp-Source: AHgI3IZ7oilPwQg+JdOXB/laOpD6ad4bqxI78BxP9R9p4yq1NmH3keqEdfz0r4PBErdEWzlooxhHoeEVAjKHldIfACk= X-Received: by 2002:a2e:98c8:: with SMTP id s8mr10482920ljj.84.1550613295523; Tue, 19 Feb 2019 13:54:55 -0800 (PST) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: <1550306421.831.16.camel@gentoo.org> <1550393754.1257.5.camel@gentoo.org> <20190217185416.nbgwm266moyk6j2u@gentoo.org> <1550496176.727.9.camel@gentoo.org> <1550606478.912.10.camel@gentoo.org> In-Reply-To: From: Alec Warner Date: Tue, 19 Feb 2019 16:54:43 -0500 Message-ID: Subject: Re: [gentoo-project] [RFC] OpenPGP Authority Keys to provide validity of developer/service keys To: gentoo-project Content-Type: multipart/alternative; boundary="000000000000aa003a0582464a97" X-Archives-Salt: cf280dda-63be-463a-980e-5f5757695946 X-Archives-Hash: 8376d711ef55b1a132940241aa0bf8dd --000000000000aa003a0582464a97 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 19, 2019 at 3:16 PM Rich Freeman wrote: > On Tue, Feb 19, 2019 at 3:01 PM Micha=C5=82 G=C3=B3rny 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 > > --000000000000aa003a0582464a97 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Feb 19, 2019 at 3:16 PM Rich = Freeman <rich0@gen= too.org> wrote:
On Tue, Feb 19, 2019 at 3:01 PM Micha=C5=82 G=C3=B3rny <mgorny@gentoo.org> w= rote:
>
> 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 goo= d
> > life-signs to undertakers.
>
> Maybe.=C2=A0 However, we're practically talking about one-time che= ck 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 *alrea= dy* in use today. We currently allow any FP in LDAP=C2=A0 with an=C2=A0@gentoo.org address to commit. This proposal = just standardizes it using existing tooling so that users can consume the t= rust graph easily. The base proposal doesn't change any of the rules, j= ust the implementation; to make it *easier* for end users to use the author= ity 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 a= nd does not verify gpg fingerprints in LDAP.

C= AFF addresses a deficiency in the current system. Currently we don't va= lidate 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.
<= div>
With CAFF, the attacker has more work to do because CAFF= will make the attacker show ownership of the private portion of the keypai= r before we grant it authority. This has some benefit as it makes it more l= ikely for the attacker to make a mistake and get caught, or leave a trail f= or 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 im= plementation of the authority scheme.
=C2=A0

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 minute= s. Its required once every 12 months.

Where should= we set the bar here, if not "please contribute at least 30 minutes ev= ery 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.=C2=A0 I'm not sure if such signing-keys wil= l be
signed by Gentoo under this proposal.=C2=A0 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.=C2=A0 Of course it<= br> could still be used for verifying email signatures if we sign
signing-only keys.

This does seem like = a gap.

-A
=C2=A0

--
Rich

--000000000000aa003a0582464a97--