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 68465138334 for ; Sat, 23 Feb 2019 13:38:28 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 20B9BE0870; Sat, 23 Feb 2019 13:38:26 +0000 (UTC) Received: from mail-pg1-f178.google.com (mail-pg1-f178.google.com [209.85.215.178]) (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 D17EEE082D for ; Sat, 23 Feb 2019 13:38:25 +0000 (UTC) Received: by mail-pg1-f178.google.com with SMTP id m1so2394533pgq.8 for ; Sat, 23 Feb 2019 05:38:25 -0800 (PST) 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:content-transfer-encoding; bh=SFIGrCZHD4BhQpooiI5O3bOMIN18c4scdF/A+n/pLwY=; b=LFsc+i5f5snSvR78+tCQ+p9Q4DxEknSjrRgpMzgRzOE6RlyOVxZxII4YKPP8GRt2wf d3VkPx3+ctbyCL/OzzjJ+sTdJn6wTYW3BxBtz9gLwOCapeGJrpTyHrj/jceNK6LR6vAD J2hIuG8SfGhknMWjtX7b1S0lvDXS7VsXx+gDnv7u/KhhD8abJLFLmGoZIy1BCgfC0ggI R71ldz+u8vIqkRn3h8HRKanxcB0ARd4I+9+GrTa71jt8UQMIHUzeyLpPs3/c5h44uSK0 xF+z5rfnU2mP+DGydsWWbOgaeM4taJYjXSnt2tfSrU4C5nz60sBpNYpr6yKfNy8rp+FL dI9A== X-Gm-Message-State: AHQUAuaTccsK+zZn8xGfalTh7L5e+S7RwsHjuI3J11FkQLTQ3gq1vSpY 7rmLaCz0CHwtwkphnU3UeSf1URs/NfmNCZ2Y3o4hXvIl X-Google-Smtp-Source: AHgI3IbdvDS2z6LQm5fPuN3SMByL3Or6SMRcIa2xJ2nsrEromjM/FdsOQdWg5h5gYsheRJsKjfGLP+e3IvYn60pUogY= X-Received: by 2002:aa7:9289:: with SMTP id j9mr9579328pfa.130.1550929104066; Sat, 23 Feb 2019 05:38:24 -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> <1550907966.752.2.camel@gentoo.org> In-Reply-To: <1550907966.752.2.camel@gentoo.org> From: Rich Freeman Date: Sat, 23 Feb 2019 08:38:13 -0500 Message-ID: Subject: Re: [gentoo-project] [RFC] OpenPGP Authority Keys to provide validity of developer/service keys To: gentoo-project Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 61f4ecc1-850e-4d46-ba3d-704df06abc30 X-Archives-Hash: bb37db8d257fb5de516574846b8bf38b On Sat, Feb 23, 2019 at 2:46 AM Micha=C5=82 G=C3=B3rny = wrote: > > On Tue, 2019-02-19 at 15:16 -0500, Rich Freeman wrote: > > 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. > > If someone really believes it's fine to have no encryption subkey just > because the GLEP doesn't require one explicitly... It either means that > person is seriously lacking the technical competence, or is a horrible > troll. In either case, I don't believe such a person should be a Gentoo > developer. The reason we write policies down is so that we can follow them. I have a signing-only key, which I think was created following some published procedure at the time. I see a newer wiki article on the subject that talks about creating a Gentoo key and it mentions that creating an encryption subkey is recommended, though it does not say it is required (which is correct). In any case, if we want everybody to have an encryption subkey, then just make it part of the GLEP. No trolling is intended, at least for my part. My Gentoo commit signing key is not used for anything else. I generate it to follow the requirements of the GLEP, and it is designed to be throw-away so that if the GLEP changes I can just roll up a new key anytime. I have no need to receive encrypted email using this key, so it isn't set up. Decrypting mail sent to me would be a pain since I don't use a gpg-aware MUA, so I really don't want to do anything to encourage people to send me encrypted mail. However, I think I have my Gentoo email address on my regular gpg key that is part of the strong set and it allows encryption. It isn't in LDAP so it wouldn't be signed using the proposed scheme. BTW, I'll also note that the guidelines for creating keys requires modification to gpg config vs just using command line options. That seems like a rather painful way of making Gentoo-specific keys. I think I ended up just setting up a container for Gentoo key generation so that I could just meet whatever specific requirements are set out and not interfere with the real world. Maybe one of these days I'll get around to shell-scripting the entire process so that instead of extending key expiry I can just revoke my old key, generate a new key, put it in LDAP, add it to my regular keyring, and update make.conf. On a side note I will note that gpg is a bit annoying in its interactivity when it comes to key manipulation. --=20 Rich