[gentoo-dev] [PATCH] glep-0063: Require encryption subkey, and make primary certify-only

[gentoo-dev] [PATCH] glep-0063: Require encryption subkey, and make primary certify-only

[Michał Górny]

Following the recent mailing list discussion indicating that developers
are taking GLEP 63 as only source of truth about OpenPGP keys, and can
make assumption that if encryption key is not listed there they should
not have one.  Amend the specification to extend it beyond the previous
limited scope of commit signing, and require an encryption key
appropriately.  This matches the GnuPG defaults.

While at it, add a recommendation that the primary key is certify-only.
Other usage is implicitly discouraged anyway via requiring subkeys.
Originally this recommendation was omitted as I wasn't aware that gpg
had a (hidden) option to change usage of existing keys.
---
 glep-0063.rst | 43 +++++++++++++++++++++++++++++--------------
 1 file changed, 29 insertions(+), 14 deletions(-)

diff --git a/glep-0063.rst b/glep-0063.rst
index 64fb437..b4bbe62 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -7,10 +7,10 @@ Author: Robin H. Johnson <robbat2@gentoo.org>,
         Michał Górny <mgorny@gentoo.org>
 Type: Standards Track
 Status: Final
-Version: 2
+Version: 2.1
 Created: 2013-02-18
-Last-Modified: 2018-07-21
-Post-History: 2013-11-10, 2018-07-03, 2018-07-21
+Last-Modified: 2019-02-24
+Post-History: 2013-11-10, 2018-07-03, 2018-07-21, 2019-02-24
 Content-Type: text/x-rst
 ---
 
@@ -28,6 +28,13 @@ OpenPGP key management policies for the Gentoo Linux distribution.
 Changes
 =======
 
+v2.1
+  A requirement for an encryption key has been added, in order to extend
+  the GLEP beyond commit signing and into use of OpenPGP for dev-to-dev
+  and user-to-dev communications.
+
+  A recommendation for primary key to be certify-only has been added.
+
 v2
   The distinct minimal and recommended expirations have been replaced
   by a single requirement. The rules have been simplified to use
@@ -70,22 +77,28 @@ Linux development are sorely needed.  This document provides both a set of
 bare minimum requirements and a set of best practice recommendations for
 the use of GnuPG (or other OpenPGP providers) by Gentoo Linux developers.
 It is intended to provide a basis for future improvements such as, e.g.,
-consistent ebuild or package signing and verifying by end users.
+consistent ebuild or package signing and verification by end users,
+and providing secure and authenticated communication channel between users
+and developers.
 
 Specifications for OpenPGP keys
 ===============================
 
 Bare minimum requirements
 -------------------------
-This section specifies obligatory requirements for all OpenPGP keys used
-to commit to Gentoo. Keys that do not conform to those requirements can
-not be used to commit.
+This section specifies obligatory requirements for all OpenPGP keys that
+are used in the context of Gentoo developer actions.  All developers
+are required to have at least one key conforming to those requirements.
+Keys that do not conform to them can not be used to commit.
 
 1. SHA-2 series output digest (SHA-1 digests internally permitted),
    at least 256-bit.  All subkey self-signatures must use this digest.
 
-2. Signing subkey that is different from the primary key, and does not
-   have any other capabilities enabled.
+2. a. Signing subkey that is different from the primary key, and does
+      not have any other capabilities enabled.
+
+   b. Encryption subkey that is different from the primary key, and does
+      not have any other capabilities enabled.
 
 3. Primary key and the signing subkey are both of type EITHER:
 
@@ -110,15 +123,17 @@ The developers should follow those practices unless there is a strong
 technical reason not to (e.g. hardware limitations, necessity of replacing
 their primary key).
 
-1. Primary key and the signing subkey are both of type RSA, 2048 bits
+1. Primary key has only ``certify`` capability enabled.
+
+2. Primary key and the signing subkey are both of type RSA, 2048 bits
    (OpenPGP v4 key format or later).
 
-2. Key expiration renewed annually to a fixed day of the year.
+3. Key expiration renewed annually to a fixed day of the year.
 
-3. Create a revocation certificate & store it hardcopy offsite securely
+4. Create a revocation certificate & store it hardcopy offsite securely
    (it's about ~300 bytes).
 
-4. Encrypted backup of your secret keys.
+5. Encrypted backup of your secret keys.
 
 Gentoo LDAP
 ===========
@@ -193,7 +208,7 @@ References
 
 Copyright
 =========
-Copyright (c) 2013-2018 by Robin Hugh Johnson, Andreas K. Hüttel,
+Copyright (c) 2013-2019 by Robin Hugh Johnson, Andreas K. Hüttel,
 Marissa Fischer, Michał Górny.
 
 This work is licensed under the Creative Commons Attribution-ShareAlike 3.0
-- 
2.21.0.rc2

Re: [gentoo-dev] [PATCH] glep-0063: Require encryption subkey, and make primary certify-only

[Rich Freeman]

On Sun, Feb 24, 2019 at 3:35 AM Michał Górny <mgorny@gentoo.org> wrote:
>
> Following the recent mailing list discussion indicating that developers
> are taking GLEP 63 as only source of truth about OpenPGP keys, and can
> make assumption that if encryption key is not listed there they should
> not have one.  Amend the specification to extend it beyond the previous
> limited scope of commit signing, and require an encryption key
> appropriately.  This matches the GnuPG defaults.

Does GLEP 63 actually match the gpg defaults?  That is, if you
generate a gpg key and accept every default value will the key be
acceptable?

If not, could we get some updated documentation as to how to generate
a minimally compliant key, similar to:
https://www.gentoo.org/glep/glep-0063.html#bare-minimum-requirements

-- 
Rich

Re: [gentoo-dev] [PATCH] glep-0063: Require encryption subkey, and make primary certify-only

[Michał Górny]

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

On Tue, 2019-04-02 at 08:02 -0600, Rich Freeman wrote:
> On Sun, Feb 24, 2019 at 3:35 AM Michał Górny <mgorny@gentoo.org> wrote:
> > Following the recent mailing list discussion indicating that developers
> > are taking GLEP 63 as only source of truth about OpenPGP keys, and can
> > make assumption that if encryption key is not listed there they should
> > not have one.  Amend the specification to extend it beyond the previous
> > limited scope of commit signing, and require an encryption key
> > appropriately.  This matches the GnuPG defaults.
> 
> Does GLEP 63 actually match the gpg defaults?  That is, if you
> generate a gpg key and accept every default value will the key be
> acceptable?
> 
> If not, could we get some updated documentation as to how to generate
> a minimally compliant key, similar to:
> https://www.gentoo.org/glep/glep-0063.html#bare-minimum-requirements
> 

There's:

https://wiki.gentoo.org/wiki/Project:Gentoo-keys/Generating_GLEP_63_based_OpenPGP_keys

It doesn't follow the best practices but is good enough to pass minimal
GLEP 63 requirements.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]