|author||Michał Górny <firstname.lastname@example.org>||2019-02-24 10:18:13 +0100|
|committer||Michał Górny <email@example.com>||2019-05-02 07:42:48 +0200|
|parent||glep-0080: Update URI of Creative Commons license. (diff)|
glep-0063: Require encryption subkey, and make primary certify-only
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. Closes: https://bugs.gentoo.org/681802 Signed-off-by: Michał Górny <firstname.lastname@example.org>
1 files changed, 29 insertions, 14 deletions
diff --git a/glep-0063.rst b/glep-0063.rst
index aae7dc5..becbadd 100644
@@ -7,10 +7,10 @@ Author: Robin H. Johnson <email@example.com>,
Michał Górny <firstname.lastname@example.org>
Type: Standards Track
-Post-History: 2013-11-10, 2018-07-03, 2018-07-21
+Post-History: 2013-11-10, 2018-07-03, 2018-07-21, 2019-02-24
@@ -28,6 +28,13 @@ OpenPGP key management policies for the Gentoo Linux distribution.
+ 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.
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
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.
@@ -193,7 +208,7 @@ References
-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