[gentoo-dev] [PATCH v5 00/16] GLEP 63, once again

[gentoo-dev] [PATCH v5 00/16] GLEP 63, once again

[Michał Górny]

Hi,

Here's another updated version of GLEP 63, taking more feedback into
consideration.  Changes since v4:

- removed all gpg.conf bits (which proved obsolete),

- added SHA-2 requirement on subkeys (this is in RISEUP and gnupg
  default, and we require SHA-2 output anyway, so it makes sense
  to extend it),

- unified punctuation.

Full text below.

--
Best regards,
Michał Górny


Michał Górny (16):
  glep-0063: Use 'OpenPGP' as appropriate
  glep-0063: RSAv4 -> OpenPGP v4 key format
  glep-0063: 'Gentoo subkey' → 'Signing subkey'
  glep-0063: Root key → primary key
  glep-0063: Split out the signing subkey into a separate point
  glep-0063: Explain minimal & recommended sections
  glep-0063: Change the recommended RSA key size to 2048 bits
  glep-0063: Allow ECC curve 25519 keys
  glep-0063: Stop recommending DSA subkeys
  glep-0063: Update and unify expiration term
  glep-0063: Require renewal 2 weeks before expiration
  glep-0063: Disallow using DSA keys
  glep-0063: Remove whitespace from LDAP field
  glep-0063: Remove gpg.conf bits
  glep-0063: Extend SHA-2 requirement to self-signatures on subkeys
  glep-0063: Unify punctuation

 glep-0063.rst | 167 ++++++++++++++++++++++++--------------------------
 1 file changed, 81 insertions(+), 86 deletions(-)

-- 
2.18.0

---
GLEP: 63
Title: Gentoo OpenPGP policies
Author: Robin H. Johnson <robbat2@gentoo.org>,
        Andreas K. Hüttel <dilfridge@gentoo.org>,
        Marissa Fischer <blogtodiffer@gmail.com>,
        Michał Górny <mgorny@gentoo.org>
Type: Standards Track
Status: Final
Version: 2
Created: 2013-02-18
Last-Modified: 2018-07-07
Post-History: 2013-11-10
Content-Type: text/x-rst
---

Credits
=======

Many developers and external sources helped in this GLEP.

Abstract
========

This GLEP provides both a minimum requirement and a recommended set of
OpenPGP key management policies for the Gentoo Linux distribution.

Changes
=======

v2
  The distinct minimal and recommended expirations have been replaced
  by a single requirement. The rules have been simplified to use
  the same maximum time of 900 days for both the primary key and subkeys.

  An additional rule requesting key renewal 2 weeks before expiration
  has been added. This is in order to give services and other developers time
  to refresh the key.

  The usage of DSA keys has been disallowed.

  The ``gpgfingerprint`` LDAP field has been altered to remove optional
  whitespace.

  The ``gpg.conf`` contents have been removed as they were seriously
  outdated and decreased security over the modern defaults.

  The requirement of SHA-2 digest has been extended to apply to self-
  signatures made on subkeys.

v1.1
  The recommended RSA key size has been changed from 4096 bits
  to 2048 bits to match the GnuPG recommendations [#GNUPG-FAQ-11-4]_.
  The larger recommendation was unjustified and resulted in people
  unnecessarily replacing their RSA-2048 keys.

  Minimal specification has been amended to allow for ECC keys.

  The option of using DSA subkey has been removed from recommendations.
  The section now specifies a single recommendation of using RSA.

Motivation
==========

Given the increasing use and importance of cryptographic protocols in internet
transactions of any kind, unified requirements for OpenPGP keys used in Gentoo
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.

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.

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.

3. Primary key and the signing subkey are both of type EITHER:

   a. RSA, >=2048 bits (OpenPGP v4 key format or later only),

   b. ECC curve 25519.

4. Expiration date on key and all subkeys set to no more than 900 days
   into the future.

5. Key expiration date renewed at least 2 weeks before the previous
   expiration date.

6. Upload your key to the SKS keyserver rotation before usage!

Recommendations
---------------
This section specifies the best practices for Gentoo developers.
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
   (OpenPGP v4 key format or later).

2. Key expiration renewed annually to a fixed day of the year.

3. Create a revocation certificate & store it hardcopy offsite securely
   (it's about ~300 bytes).

4. Encrypted backup of your secret keys.

Gentoo LDAP
===========

All Gentoo developers must list the complete fingerprint for their primary
keys in the "``gpgfingerprint``" LDAP field. It must be exactly 40 hex digits,
uppercase, without whitespace.

The prior "``gpgkey``" field will be removed, as it is a subset
of the fingerprint field. In any place that presently displays
the "``gpgkey``" field, the last 16 hex digits of the fingerprint should
be displayed instead.

Backwards Compatibility
=======================

There is no consistent standard for GPG usage in Gentoo to date. There is
conflicting information in the Devmanual [#DEVMANUAL-MANIFEST]_ and the GnuPG
Gentoo user guide [#GNUPG-USER]_. As there is little enforcement of Manifest
signing and very little commit signing to date, there are no backwards
compatibility concerns.

External documentation
======================

Much of the above was driven by the following:

* NIST SP 800-57 recommendations [#NISTSP800571]_, [#NISTSP800572]_,

* Debian GPG documentation [#DEBIANGPG]_,

* RiseUp.net OpenPGP best practices [#RISEUP]_,

* ENISA Algorithms, Key Sizes and Parameters Report 2013 [#ENISA2013]_.

References
==========

.. [#GNUPG-FAQ-11-4] GnuPG FAQ: Why doesn’t GnuPG default to using RSA-4096?
   (https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096)

.. [#DEBIANGPG] Debian GPG documentation
   (https://wiki.debian.org/Keysigning)

.. [#EKAIA] Ana's blog: Creating a new GPG key
   (http://ekaia.org/blog/2009/05/10/creating-new-gpgkey/)

.. [#RISEUP] RiseUp.net OpenPGP best practices
   (https://help.riseup.net/en/security/message-security/openpgp/best-practices)

.. [#DEVMANUAL-MANIFEST] Gentoo Development Guide: Manifest
   (http://devmanual.gentoo.org/general-concepts/manifest/index.html)

.. [#GNUPG-USER] GnuPG Gentoo User Guide
   (http://www.gentoo.org/doc/en/gnupg-user.xml)

.. [#NISTSP800571] NIST SP 800-57: Recommendation for Key Management:
   Part 1: General (Revision 3)
   (http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf)

.. [#NISTSP800572] NIST SP 800-57: Recommendation for Key Management:
   Part 2: Best Practices for Key Management Organization
   (http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part2.pdf)

.. [#ISSUER-ANNOTATE] Including the entire fingerprint of the issuer
  in an OpenPGP certification
  (http://thread.gmane.org/gmane.mail.notmuch.general/3721/focus=7234)

.. [#ENISA2013] ENISA Algorithms, Key Sizes and Parameters Report,
   2013 recommendations, version 1.0 (October 2013)
   (https://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report)

Copyright
=========
Copyright (c) 2013-2018 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
Unported License.  To view a copy of this license, visit
http://creativecommons.org/licenses/by-sa/3.0/.

[gentoo-dev] [PATCH v5 01/16] glep-0063: Use 'OpenPGP' as appropriate

[Michał Górny]

Replace many of the incorrect uses of GPG/GnuPG [key] with OpenPGP.
G[nu]PG has been left where the text clearly refers to the specific
implementation of OpenPGP rather than the standard itself.
---
 glep-0063.rst | 28 +++++++++++++++-------------
 1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/glep-0063.rst b/glep-0063.rst
index c59d545..d1dfe3d 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -1,14 +1,15 @@
 ---
 GLEP: 63
-Title: Gentoo GPG key policies
+Title: Gentoo OpenPGP policies
 Author: Robin H. Johnson <robbat2@gentoo.org>,
         Andreas K. Hüttel <dilfridge@gentoo.org>,
-        Marissa Fischer <blogtodiffer@gmail.com>
+        Marissa Fischer <blogtodiffer@gmail.com>,
+        Michał Górny <mgorny@gentoo.org>
 Type: Standards Track
 Status: Final
 Version: 1
 Created: 2013-02-18
-Last-Modified: 2015-08-25
+Last-Modified: 2018-07-07
 Post-History: 2013-11-10
 Content-Type: text/x-rst
 ---
@@ -21,22 +22,22 @@ Many developers and external sources helped in this GLEP.
 Abstract
 ========
 
-This GLEP provides both a minimum requirement and a recommended set of GPG
-key management policies for the Gentoo Linux distribution.
+This GLEP provides both a minimum requirement and a recommended set of
+OpenPGP key management policies for the Gentoo Linux distribution.
 
 Motivation
 ==========
 
 Given the increasing use and importance of cryptographic protocols in internet
-transactions of any kind, unified requirements for GnuPG keys used in Gentoo
+transactions of any kind, unified requirements for OpenPGP keys used in Gentoo
 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 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.
+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.
 
-Specifications for GnuPG keys
-=============================
+Specifications for OpenPGP keys
+===============================
 
 Bare minimum requirements
 -------------------------
@@ -125,7 +126,7 @@ Recommendations
 Gentoo LDAP
 ===========
 
-All Gentoo developers must list the complete GPG fingerprint for their root
+All Gentoo developers must list the complete fingerprint for their root
 keys in the "``gpgfingerprint``" LDAP field. It must be exactly 40 hex digits,
 uppercase, with optional spaces every 8 hex digits. Regular expression for
 validation::
@@ -195,7 +196,8 @@ References
 
 Copyright
 =========
-Copyright (c) 2013 by Robin Hugh Johnson, Andreas K. Hüttel, Marissa Fischer.
+Copyright (c) 2013-2018 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
 Unported License.  To view a copy of this license, visit
-- 
2.18.0

[gentoo-dev] [PATCH v5 02/16] glep-0063: RSAv4 -> OpenPGP v4 key format

[Michał Górny]

Replace the 'RSAv4' with 'OpenPGP v4 key format'.  The RSA algorithm
does not really have versions, and the author most likely meant the v4
of OpenPGP key format as outlined in RFC 4880, section 12.1.

This was figured out and explained to me by Kristian Fiskerstrand.
---
 glep-0063.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/glep-0063.rst b/glep-0063.rst
index d1dfe3d..0773e3b 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -50,7 +50,7 @@ Bare minimum requirements
 
    a. DSA, 2048-bit
 
-   b. RSA, >=2048 bits, RSAv4 or later only
+   b. RSA, >=2048 bits (OpenPGP v4 key format or later only)
 
 3. Key expiry: 5 years maximum
 
@@ -102,7 +102,7 @@ Recommendations
        # when making an OpenPGP certification, use a stronger digest than the default SHA1:
        cert-digest-algo SHA256
 
-2. Root key type RSA, 4096 bits, RSAv4 or later
+2. Root key type RSA, 4096 bits (OpenPGP v4 key format or later)
 
    This may require creating an entirely new key.
 
-- 
2.18.0

[gentoo-dev] [PATCH v5 03/16] glep-0063: 'Gentoo subkey' → 'Signing subkey'

[Michał Górny]

Replace the 'Gentoo subkey' term that might wrongly suggest that
the developers are expected to create an additional, dedicated subkey
for Gentoo.

Suggested-by: Kristian Fiskerstrand <k_f@gentoo.org>
---
 glep-0063.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/glep-0063.rst b/glep-0063.rst
index 0773e3b..f02537d 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -116,7 +116,7 @@ Recommendations
 
    a. Root key: 3 years maximum, expiry date renewed annually.
 
-   b. Gentoo subkey: 1 year maximum, expiry date renewed every 6 months.
+   b. Signing subkey: 1 year maximum, expiry date renewed every 6 months.
 
 5. Create a revocation certificate & store it hardcopy offsite securely
    (it's about ~300 bytes).
-- 
2.18.0

[gentoo-dev] [PATCH v5 04/16] glep-0063: Root key → primary key

[Michał Górny]

Replace the custom term 'root key' with much more common 'primary key'.
This is also the term used in GnuPG output.
---
 glep-0063.rst | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/glep-0063.rst b/glep-0063.rst
index f02537d..8542031 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -46,7 +46,7 @@ Bare minimum requirements
 
        personal-digest-preferences SHA256
 
-2. Root key and signing subkey of EITHER:
+2. Primary key and signing subkey of EITHER:
 
    a. DSA, 2048-bit
 
@@ -102,7 +102,7 @@ Recommendations
        # when making an OpenPGP certification, use a stronger digest than the default SHA1:
        cert-digest-algo SHA256
 
-2. Root key type RSA, 4096 bits (OpenPGP v4 key format or later)
+2. Primary key type RSA, 4096 bits (OpenPGP v4 key format or later)
 
    This may require creating an entirely new key.
 
@@ -114,7 +114,7 @@ Recommendations
 
 4. Key expiry:
 
-   a. Root key: 3 years maximum, expiry date renewed annually.
+   a. Primary key: 3 years maximum, expiry date renewed annually.
 
    b. Signing subkey: 1 year maximum, expiry date renewed every 6 months.
 
@@ -126,7 +126,7 @@ Recommendations
 Gentoo LDAP
 ===========
 
-All Gentoo developers must list the complete fingerprint for their root
+All Gentoo developers must list the complete fingerprint for their primary
 keys in the "``gpgfingerprint``" LDAP field. It must be exactly 40 hex digits,
 uppercase, with optional spaces every 8 hex digits. Regular expression for
 validation::
-- 
2.18.0

[gentoo-dev] [PATCH v5 05/16] glep-0063: Split out the signing subkey into a separate point

[Michał Górny]

Reword the specification to express the requirement for separate signing
subkey more verbosely.  Replace the ambiguous term 'dedicated' with
clear explanation that it needs to be different from the primary key
and not used for other purposes.

Suggested-by: Kristian Fiskerstrand <k_f@gentoo.org>
---
 glep-0063.rst | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/glep-0063.rst b/glep-0063.rst
index 8542031..14541d7 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -46,15 +46,18 @@ Bare minimum requirements
 
        personal-digest-preferences SHA256
 
-2. Primary key and signing subkey of EITHER:
+2. Signing 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:
 
    a. DSA, 2048-bit
 
    b. RSA, >=2048 bits (OpenPGP v4 key format or later only)
 
-3. Key expiry: 5 years maximum
+4. Key expiry: 5 years maximum
 
-4. Upload your key to the SKS keyserver rotation before usage!
+5. Upload your key to the SKS keyserver rotation before usage!
 
 Recommendations
 ---------------
@@ -106,7 +109,7 @@ Recommendations
 
    This may require creating an entirely new key.
 
-3. Dedicated signing subkey of EITHER:
+3. The signing subkey of EITHER:
 
    a. DSA 2048 bits exactly.
 
-- 
2.18.0

[gentoo-dev] [PATCH v5 06/16] glep-0063: Explain minimal & recommended sections

[Michał Górny]

---
 glep-0063.rst | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/glep-0063.rst b/glep-0063.rst
index 14541d7..f4b49c2 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -41,6 +41,10 @@ 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.
+
 1. SHA2-series output digest (SHA1 digests internally permitted),
    256bit or more::
 
@@ -61,6 +65,10 @@ Bare minimum requirements
 
 Recommendations
 ---------------
+This section specifies the best practices for Gentoo developers.
+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. Copy ``/usr/share/gnupg/gpg-conf.skel`` to ``~/.gnupg/gpg.conf``, append
    the following block::
-- 
2.18.0

[gentoo-dev] [PATCH v5 07/16] glep-0063: Change the recommended RSA key size to 2048 bits

[Michał Górny]

Change the recommended key size recommendation for RSA from 4096 bits
to 2048 bits.  Use of larger keys is unjustified due to negligible gain
in security, and recommending RSA-4096 unnecessarily resulted
in developers replacing their RSA-2048 keys for no good reason.
---
 glep-0063.rst | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/glep-0063.rst b/glep-0063.rst
index f4b49c2..fb09dd8 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -7,7 +7,7 @@ Author: Robin H. Johnson <robbat2@gentoo.org>,
         Michał Górny <mgorny@gentoo.org>
 Type: Standards Track
 Status: Final
-Version: 1
+Version: 1.1
 Created: 2013-02-18
 Last-Modified: 2018-07-07
 Post-History: 2013-11-10
@@ -25,6 +25,15 @@ Abstract
 This GLEP provides both a minimum requirement and a recommended set of
 OpenPGP key management policies for the Gentoo Linux distribution.
 
+Changes
+=======
+
+v1.1
+  The recommended RSA key size has been changed from 4096 bits
+  to 2048 bits to match the GnuPG recommendations [#GNUPG-FAQ-11-4]_.
+  The larger recommendation was unjustified and resulted in people
+  unnecessarily replacing their RSA-2048 keys.
+
 Motivation
 ==========
 
@@ -113,15 +122,13 @@ their primary key).
        # when making an OpenPGP certification, use a stronger digest than the default SHA1:
        cert-digest-algo SHA256
 
-2. Primary key type RSA, 4096 bits (OpenPGP v4 key format or later)
-
-   This may require creating an entirely new key.
+2. Primary key type RSA, 2048 bits (OpenPGP v4 key format or later)
 
 3. The signing subkey of EITHER:
 
    a. DSA 2048 bits exactly.
 
-   b. RSA 4096 bits exactly.
+   b. RSA 2048 bits exactly.
 
 4. Key expiry:
 
@@ -174,6 +181,9 @@ Much of the above was driven by the following:
 References
 ==========
 
+.. [#GNUPG-FAQ-11-4] GnuPG FAQ: Why doesn’t GnuPG default to using RSA-4096?
+   (https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096)
+
 .. [#DEBIANGPG] Debian GPG documentation
    (https://wiki.debian.org/Keysigning)
 
-- 
2.18.0

[gentoo-dev] [PATCH v5 08/16] glep-0063: Allow ECC curve 25519 keys

[Michał Górny]

Optionally allow using ECC curve 25519 keys.  We already have
developers using those keys, and given that they are supported
by GnuPG 2.2, there's probably no reason to ban them.  However, they're
not recommended due to interoperability issues.
---
 glep-0063.rst | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/glep-0063.rst b/glep-0063.rst
index fb09dd8..2402c34 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -34,6 +34,8 @@ v1.1
   The larger recommendation was unjustified and resulted in people
   unnecessarily replacing their RSA-2048 keys.
 
+  Minimal specification has been amended to allow for ECC keys.
+
 Motivation
 ==========
 
@@ -68,6 +70,8 @@ not be used to commit.
 
    b. RSA, >=2048 bits (OpenPGP v4 key format or later only)
 
+   c. ECC curve 25519
+
 4. Key expiry: 5 years maximum
 
 5. Upload your key to the SKS keyserver rotation before usage!
-- 
2.18.0

[gentoo-dev] [PATCH v5 09/16] glep-0063: Stop recommending DSA subkeys

[Michał Górny]

There is really no technical reason to use DSA these days, and we should
focus on having a single recommendation.  DSA keys are still permitted
via 'minimal' requirements.
---
 glep-0063.rst | 18 ++++++++----------
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/glep-0063.rst b/glep-0063.rst
index 2402c34..7f870bb 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -36,6 +36,9 @@ v1.1
 
   Minimal specification has been amended to allow for ECC keys.
 
+  The option of using DSA subkey has been removed from recommendations.
+  The section now specifies a single recommendation of using RSA.
+
 Motivation
 ==========
 
@@ -126,24 +129,19 @@ their primary key).
        # when making an OpenPGP certification, use a stronger digest than the default SHA1:
        cert-digest-algo SHA256
 
-2. Primary key type RSA, 2048 bits (OpenPGP v4 key format or later)
-
-3. The signing subkey of EITHER:
-
-   a. DSA 2048 bits exactly.
-
-   b. RSA 2048 bits exactly.
+2. Primary key and the signing subkey are both of type RSA, 2048 bits
+   (OpenPGP v4 key format or later)
 
-4. Key expiry:
+3. Key expiry:
 
    a. Primary key: 3 years maximum, expiry date renewed annually.
 
    b. Signing subkey: 1 year maximum, expiry date renewed every 6 months.
 
-5. Create a revocation certificate & store it hardcopy offsite securely
+4. Create a revocation certificate & store it hardcopy offsite securely
    (it's about ~300 bytes).
 
-6. Encrypted backup of your secret keys.
+5. Encrypted backup of your secret keys.
 
 Gentoo LDAP
 ===========
-- 
2.18.0

[gentoo-dev] [PATCH v5 10/16] glep-0063: Update and unify expiration term

[Michał Górny]

Replace the disjoint 'minimum' and 'recommendation' for expiration with
a single requirement.  Make it 2.5 years with recommended annual renewal
to a fixed day of the year (2 years + some grace time for renewal).
Also, remove disjoint expiration recommendation for the primary key
and subkeys since many developers fail at implementing that anyway.
---
 glep-0063.rst | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/glep-0063.rst b/glep-0063.rst
index 7f870bb..9ba778b 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -7,7 +7,7 @@ Author: Robin H. Johnson <robbat2@gentoo.org>,
         Michał Górny <mgorny@gentoo.org>
 Type: Standards Track
 Status: Final
-Version: 1.1
+Version: 2
 Created: 2013-02-18
 Last-Modified: 2018-07-07
 Post-History: 2013-11-10
@@ -28,6 +28,11 @@ OpenPGP key management policies for the Gentoo Linux distribution.
 Changes
 =======
 
+v2
+  The distinct minimal and recommended expirations have been replaced
+  by a single requirement. The rules have been simplified to use
+  the same maximum time of 900 days for both the primary key and subkeys.
+
 v1.1
   The recommended RSA key size has been changed from 4096 bits
   to 2048 bits to match the GnuPG recommendations [#GNUPG-FAQ-11-4]_.
@@ -75,7 +80,8 @@ not be used to commit.
 
    c. ECC curve 25519
 
-4. Key expiry: 5 years maximum
+4. Expiration date on key and all subkeys set to no more than 900 days
+   into the future
 
 5. Upload your key to the SKS keyserver rotation before usage!
 
@@ -132,11 +138,7 @@ their primary key).
 2. Primary key and the signing subkey are both of type RSA, 2048 bits
    (OpenPGP v4 key format or later)
 
-3. Key expiry:
-
-   a. Primary key: 3 years maximum, expiry date renewed annually.
-
-   b. Signing subkey: 1 year maximum, expiry date renewed every 6 months.
+3. Key expiration renewed annually to a fixed day of the year
 
 4. Create a revocation certificate & store it hardcopy offsite securely
    (it's about ~300 bytes).
-- 
2.18.0

[gentoo-dev] [PATCH v5 11/16] glep-0063: Require renewal 2 weeks before expiration

[Michał Górny]

Add a rule requesting renewal of keys at least two weeks before their
expiration date, in order to give services time to refresh.
---
 glep-0063.rst | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/glep-0063.rst b/glep-0063.rst
index 9ba778b..ca834a8 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -33,6 +33,10 @@ v2
   by a single requirement. The rules have been simplified to use
   the same maximum time of 900 days for both the primary key and subkeys.
 
+  An additional rule requesting key renewal 2 weeks before expiration
+  has been added. This is in order to give services and other developers time
+  to refresh the key.
+
 v1.1
   The recommended RSA key size has been changed from 4096 bits
   to 2048 bits to match the GnuPG recommendations [#GNUPG-FAQ-11-4]_.
@@ -83,7 +87,10 @@ not be used to commit.
 4. Expiration date on key and all subkeys set to no more than 900 days
    into the future
 
-5. Upload your key to the SKS keyserver rotation before usage!
+5. Key expiration date renewed at least 2 weeks before the previous
+   expiration date
+
+6. Upload your key to the SKS keyserver rotation before usage!
 
 Recommendations
 ---------------
-- 
2.18.0

[gentoo-dev] [PATCH v5 12/16] glep-0063: Disallow using DSA keys

[Michał Górny]

There really is no technical reason to use DSA keys and people who are
still using old DSA keys should finally replace them, so remove them
from the minimal requirements.
---
 glep-0063.rst | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/glep-0063.rst b/glep-0063.rst
index ca834a8..300456b 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -37,6 +37,8 @@ v2
   has been added. This is in order to give services and other developers time
   to refresh the key.
 
+  The usage of DSA keys has been disallowed.
+
 v1.1
   The recommended RSA key size has been changed from 4096 bits
   to 2048 bits to match the GnuPG recommendations [#GNUPG-FAQ-11-4]_.
@@ -78,11 +80,9 @@ not be used to commit.
 
 3. Primary key and the signing subkey are both of type EITHER:
 
-   a. DSA, 2048-bit
-
-   b. RSA, >=2048 bits (OpenPGP v4 key format or later only)
+   a. RSA, >=2048 bits (OpenPGP v4 key format or later only)
 
-   c. ECC curve 25519
+   b. ECC curve 25519
 
 4. Expiration date on key and all subkeys set to no more than 900 days
    into the future
-- 
2.18.0

[gentoo-dev] [PATCH v5 13/16] glep-0063: Remove whitespace from LDAP field

[Michał Górny]

Requested-by: Robin H. Johnson <robbat2@gentoo.org>
---
 glep-0063.rst | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/glep-0063.rst b/glep-0063.rst
index 300456b..37b1f4d 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -39,6 +39,9 @@ v2
 
   The usage of DSA keys has been disallowed.
 
+  The ``gpgfingerprint`` LDAP field has been altered to remove optional
+  whitespace.
+
 v1.1
   The recommended RSA key size has been changed from 4096 bits
   to 2048 bits to match the GnuPG recommendations [#GNUPG-FAQ-11-4]_.
@@ -157,10 +160,7 @@ Gentoo LDAP
 
 All Gentoo developers must list the complete fingerprint for their primary
 keys in the "``gpgfingerprint``" LDAP field. It must be exactly 40 hex digits,
-uppercase, with optional spaces every 8 hex digits. Regular expression for
-validation::
-
-    ^([[:space:]]*[[:xdigit:]]{8}){5}$
+uppercase, without whitespace.
 
 The prior "``gpgkey``" field will be removed, as it is a subset
 of the fingerprint field. In any place that presently displays
-- 
2.18.0

[gentoo-dev] [PATCH v5 14/16] glep-0063: Remove gpg.conf bits

[Michał Górny]

Remove the gpg.conf bits from recommended and minimal specification.
Apparently they are seriously obsolete and worse than the modern
defaults.  While at it, editorial corrections to 'SHA2' bit.

Requested-by: Richard Yao <ryao@gentoo.org>
---
 glep-0063.rst | 60 ++++++++-------------------------------------------
 1 file changed, 9 insertions(+), 51 deletions(-)

diff --git a/glep-0063.rst b/glep-0063.rst
index 37b1f4d..84d87d2 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -42,6 +42,9 @@ v2
   The ``gpgfingerprint`` LDAP field has been altered to remove optional
   whitespace.
 
+  The ``gpg.conf`` contents have been removed as they were seriously
+  outdated and decreased security over the modern defaults.
+
 v1.1
   The recommended RSA key size has been changed from 4096 bits
   to 2048 bits to match the GnuPG recommendations [#GNUPG-FAQ-11-4]_.
@@ -73,10 +76,8 @@ 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.
 
-1. SHA2-series output digest (SHA1 digests internally permitted),
-   256bit or more::
-
-       personal-digest-preferences SHA256
+1. SHA-2 series output digest (SHA-1 digests internally permitted),
+   at least 256-bit.
 
 2. Signing subkey that is different from the primary key, and does not
    have any other capabilities enabled
@@ -102,58 +103,15 @@ 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. Copy ``/usr/share/gnupg/gpg-conf.skel`` to ``~/.gnupg/gpg.conf``, append
-   the following block::
-
-       keyserver pool.sks-keyservers.net
-
-       emit-version
-
-       default-recipient-self
-
-       # -- All of the below portion from the RiseUp.net OpenPGP best practices, and
-       # -- many of them are also in the Debian GPG documentation.
-
-       # when outputting certificates, view user IDs distinctly from keys:
-       fixed-list-mode
-
-       # long keyids are more collision-resistant than short keyids (it's trivial to make a key
-       # with any desired short keyid)
-       # NOTE: this breaks kmail gnupg support!
-       keyid-format 0xlong
-
-       # when multiple digests are supported by all recipients, choose the strongest one:
-       personal-digest-preferences SHA512 SHA384 SHA256 SHA224
-
-       # preferences chosen for new keys should prioritize stronger algorithms:
-       default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 BZIP2 ZLIB ZIP Uncompressed
-
-       # If you use a graphical environment (and even if you don't) you should be using an agent:
-       # (similar arguments as  https://www.debian-administration.org/users/dkg/weblog/64)
-       use-agent
-
-       # You should always know at a glance which User IDs gpg thinks are legitimately bound to
-       # the keys in your keyring:
-       verify-options show-uid-validity
-       list-options show-uid-validity
-
-       # include an unambiguous indicator of which key made a signature:
-       # (see http://thread.gmane.org/gmane.mail.notmuch.general/3721/focus=7234)
-       # (and http://www.ietf.org/mail-archive/web/openpgp/current/msg00405.html)
-       sig-notation issuer-fpr@notations.openpgp.fifthhorseman.net=%g
-
-       # when making an OpenPGP certification, use a stronger digest than the default SHA1:
-       cert-digest-algo SHA256
-
-2. Primary key and the signing subkey are both of type RSA, 2048 bits
+1. Primary key and the signing subkey are both of type RSA, 2048 bits
    (OpenPGP v4 key format or later)
 
-3. Key expiration renewed annually to a fixed day of the year
+2. Key expiration renewed annually to a fixed day of the year
 
-4. Create a revocation certificate & store it hardcopy offsite securely
+3. Create a revocation certificate & store it hardcopy offsite securely
    (it's about ~300 bytes).
 
-5. Encrypted backup of your secret keys.
+4. Encrypted backup of your secret keys.
 
 Gentoo LDAP
 ===========
-- 
2.18.0

[gentoo-dev] [PATCH v5 15/16] glep-0063: Extend SHA-2 requirement to self-signatures on subkeys

[Michał Górny]

---
 glep-0063.rst | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/glep-0063.rst b/glep-0063.rst
index 84d87d2..ae36d36 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -45,6 +45,9 @@ v2
   The ``gpg.conf`` contents have been removed as they were seriously
   outdated and decreased security over the modern defaults.
 
+  The requirement of SHA-2 digest has been extended to apply to self-
+  signatures made on subkeys.
+
 v1.1
   The recommended RSA key size has been changed from 4096 bits
   to 2048 bits to match the GnuPG recommendations [#GNUPG-FAQ-11-4]_.
@@ -77,7 +80,7 @@ to commit to Gentoo. Keys that do not conform to those requirements can
 not be used to commit.
 
 1. SHA-2 series output digest (SHA-1 digests internally permitted),
-   at least 256-bit.
+   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.18.0

[gentoo-dev] [PATCH v5 16/16] glep-0063: Unify punctuation

[Michał Górny]

Requested-by: Ulrich Müller <ulm@gentoo.org>
---
 glep-0063.rst | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/glep-0063.rst b/glep-0063.rst
index ae36d36..c02b89e 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -83,19 +83,19 @@ not be used to commit.
    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
+   have any other capabilities enabled.
 
 3. Primary key and the signing subkey are both of type EITHER:
 
-   a. RSA, >=2048 bits (OpenPGP v4 key format or later only)
+   a. RSA, >=2048 bits (OpenPGP v4 key format or later only),
 
-   b. ECC curve 25519
+   b. ECC curve 25519.
 
 4. Expiration date on key and all subkeys set to no more than 900 days
-   into the future
+   into the future.
 
 5. Key expiration date renewed at least 2 weeks before the previous
-   expiration date
+   expiration date.
 
 6. Upload your key to the SKS keyserver rotation before usage!
 
@@ -107,9 +107,9 @@ 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
-   (OpenPGP v4 key format or later)
+   (OpenPGP v4 key format or later).
 
-2. Key expiration renewed annually to a fixed day of the year
+2. Key expiration renewed annually to a fixed day of the year.
 
 3. Create a revocation certificate & store it hardcopy offsite securely
    (it's about ~300 bytes).
@@ -142,13 +142,13 @@ External documentation
 
 Much of the above was driven by the following:
 
-* NIST SP 800-57 recommendations [#NISTSP800571]_, [#NISTSP800572]_
+* NIST SP 800-57 recommendations [#NISTSP800571]_, [#NISTSP800572]_,
 
-* Debian GPG documentation [#DEBIANGPG]_
+* Debian GPG documentation [#DEBIANGPG]_,
 
-* RiseUp.net OpenPGP best practices [#RISEUP]_
+* RiseUp.net OpenPGP best practices [#RISEUP]_,
 
-* ENISA Algorithms, Key Sizes and Parameters Report 2013 [#ENISA2013]_
+* ENISA Algorithms, Key Sizes and Parameters Report 2013 [#ENISA2013]_.
 
 References
 ==========
-- 
2.18.0

Re: [gentoo-dev] [PATCH v5 03/16] glep-0063: 'Gentoo subkey' → 'Signing subkey'

[Joshua Kinard]

On 7/8/2018 2:38 PM, Michał Górny wrote:
> Replace the 'Gentoo subkey' term that might wrongly suggest that
> the developers are expected to create an additional, dedicated subkey
> for Gentoo.
> 
> Suggested-by: Kristian Fiskerstrand <k_f@gentoo.org>
> ---
>  glep-0063.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/glep-0063.rst b/glep-0063.rst
> index 0773e3b..f02537d 100644
> --- a/glep-0063.rst
> +++ b/glep-0063.rst
> @@ -116,7 +116,7 @@ Recommendations
>  
>     a. Root key: 3 years maximum, expiry date renewed annually.
>  
> -   b. Gentoo subkey: 1 year maximum, expiry date renewed every 6 months.
> +   b. Signing subkey: 1 year maximum, expiry date renewed every 6 months.
>  
>  5. Create a revocation certificate & store it hardcopy offsite securely
>     (it's about ~300 bytes).
> 

I lost track of this due to other priorities, but picking through some of the
follow-up messages about the lead time on renewals and all, I don't have a
problem with that.  But why is the maximum of one year on subkey/signing key
expiration still here?

I'm not seeing a lot of additional follow-up on that, but that is still too
short.  Two years is perfectly fine in this case.  I'd prefer three years
myself, but am willing to compromise for two.  I am not doing one year unless
someone drops some really convincing logic on me.  And no, scrawling "logic" on
the side of an anvil doesn't count.

Does anyone know what the other projects require for their keys?  Without a
proper explanation of //why// one year needs to be the maximum, looking to what
other projects use seems sensible for guidance.

I can't seem to find any specific guidance from Debian, but FreeBSD appears to
be fine with three years on their committer keys:

"""
A three year key lifespan is short enough to obsolete keys weakened by
advancing computer power, but long enough to reduce key management problems.
"""

https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/article.html#pgpkeys

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: [gentoo-dev] [PATCH v5 03/16] glep-0063: 'Gentoo subkey' → 'Signing subkey'

[Michał Górny]

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

W dniu śro, 25.07.2018 o godzinie 01∶28 -0400, użytkownik Joshua Kinard
napisał:
> On 7/8/2018 2:38 PM, Michał Górny wrote:
> > Replace the 'Gentoo subkey' term that might wrongly suggest that
> > the developers are expected to create an additional, dedicated subkey
> > for Gentoo.
> > 
> > Suggested-by: Kristian Fiskerstrand <k_f@gentoo.org>
> > ---
> >  glep-0063.rst | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/glep-0063.rst b/glep-0063.rst
> > index 0773e3b..f02537d 100644
> > --- a/glep-0063.rst
> > +++ b/glep-0063.rst
> > @@ -116,7 +116,7 @@ Recommendations
> >  
> >     a. Root key: 3 years maximum, expiry date renewed annually.
> >  
> > -   b. Gentoo subkey: 1 year maximum, expiry date renewed every 6 months.
> > +   b. Signing subkey: 1 year maximum, expiry date renewed every 6 months.
> >  
> >  5. Create a revocation certificate & store it hardcopy offsite securely
> >     (it's about ~300 bytes).
> > 
> 
> I lost track of this due to other priorities, but picking through some of the
> follow-up messages about the lead time on renewals and all, I don't have a
> problem with that.  But why is the maximum of one year on subkey/signing key
> expiration still here?

Because I've started with small changes, and the thing you're asking
about is changed in a followup patch.  Please read the final text
instead of wrongly assuming something from irrelevant change.

> 
> I'm not seeing a lot of additional follow-up on that, but that is still too
> short.  Two years is perfectly fine in this case.  I'd prefer three years
> myself, but am willing to compromise for two.  I am not doing one year unless
> someone drops some really convincing logic on me.  And no, scrawling "logic" on
> the side of an anvil doesn't count.
> 
> Does anyone know what the other projects require for their keys?  Without a
> proper explanation of //why// one year needs to be the maximum, looking to what
> other projects use seems sensible for guidance.
> 
> I can't seem to find any specific guidance from Debian, but FreeBSD appears to
> be fine with three years on their committer keys:
> 
> """
> A three year key lifespan is short enough to obsolete keys weakened by
> advancing computer power, but long enough to reduce key management problems.
> """
> 
> https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/article.html#pgpkeys
> 

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] [PATCH v5 03/16] glep-0063: 'Gentoo subkey' → 'Signing subkey'

[Aaron Bauman]

On July 25, 2018 1:28:52 AM EDT, Joshua Kinard <kumba@gentoo.org> wrote:
>On 7/8/2018 2:38 PM, Michał Górny wrote:
>> Replace the 'Gentoo subkey' term that might wrongly suggest that
>> the developers are expected to create an additional, dedicated subkey
>> for Gentoo.
>> 
>> Suggested-by: Kristian Fiskerstrand <k_f@gentoo.org>
>> ---
>>  glep-0063.rst | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/glep-0063.rst b/glep-0063.rst
>> index 0773e3b..f02537d 100644
>> --- a/glep-0063.rst
>> +++ b/glep-0063.rst
>> @@ -116,7 +116,7 @@ Recommendations
>>  
>>     a. Root key: 3 years maximum, expiry date renewed annually.
>>  
>> -   b. Gentoo subkey: 1 year maximum, expiry date renewed every 6
>months.
>> +   b. Signing subkey: 1 year maximum, expiry date renewed every 6
>months.
>>  
>>  5. Create a revocation certificate & store it hardcopy offsite
>securely
>>     (it's about ~300 bytes).
>> 
>
>I lost track of this due to other priorities, but picking through some
>of the
>follow-up messages about the lead time on renewals and all, I don't
>have a
>problem with that.  But why is the maximum of one year on
>subkey/signing key
>expiration still here?
>
>I'm not seeing a lot of additional follow-up on that, but that is still
>too
>short.  Two years is perfectly fine in this case.  I'd prefer three
>years
>myself, but am willing to compromise for two.  I am not doing one year
>unless
>someone drops some really convincing logic on me.  And no, scrawling
>"logic" on
>the side of an anvil doesn't count.
>
>Does anyone know what the other projects require for their keys? 
>Without a
>proper explanation of //why// one year needs to be the maximum, looking
>to what
>other projects use seems sensible for guidance.
>
>I can't seem to find any specific guidance from Debian, but FreeBSD
>appears to
>be fine with three years on their committer keys:
>
>"""
>A three year key lifespan is short enough to obsolete keys weakened by
>advancing computer power, but long enough to reduce key management
>problems.
>"""
>
>https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/article.html#pgpkeys

Everyone will have a different opinion.  NIST, Debian, Redhat, etc.

Shouldn't you be providing the logic as to why it is a bad idea?

Someone wants to set a reasonable standard for the sake of having *a* policy in place.  They did the work, proposed it, and it isn't something awful or intrusive.  

The whole, "I am not doing one year..." and then the "anvil doesn't count" seems uncooperative and contradictory.

Is there some obstacle stopping you from updating your key expiration once a year?  It takes at most 20 minutes.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-dev] [PATCH v5 03/16] glep-0063: 'Gentoo subkey' → 'Signing subkey'

[Ulrich Mueller]

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

>>>>> On Wed, 25 Jul 2018, Aaron Bauman wrote:

> The whole, "I am not doing one year..." and then the "anvil doesn't
> count" seems uncooperative and contradictory.

> Is there some obstacle stopping you from updating your key
> expiration once a year? It takes at most 20 minutes.

It is *not* one year. Patch 10 of the series updates it:

+4. Expiration date on key and all subkeys set to no more than 900 days
+   into the future

900 days are 2.46 years. So the expiry time can be renewed every two
years to the same month and day, with an ample time window of about
five months for renewal.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] [PATCH v5 03/16] glep-0063: 'Gentoo subkey' → 'Signing subkey'

[Joshua Kinard]

On 7/25/2018 1:38 AM, Michał Górny wrote:
> W dniu śro, 25.07.2018 o godzinie 01∶28 -0400, użytkownik Joshua Kinard
> napisał:
>> On 7/8/2018 2:38 PM, Michał Górny wrote:
>>> Replace the 'Gentoo subkey' term that might wrongly suggest that
>>> the developers are expected to create an additional, dedicated subkey
>>> for Gentoo.
>>>
>>> Suggested-by: Kristian Fiskerstrand <k_f@gentoo.org>
>>> ---
>>>  glep-0063.rst | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/glep-0063.rst b/glep-0063.rst
>>> index 0773e3b..f02537d 100644
>>> --- a/glep-0063.rst
>>> +++ b/glep-0063.rst
>>> @@ -116,7 +116,7 @@ Recommendations
>>>  
>>>     a. Root key: 3 years maximum, expiry date renewed annually.
>>>  
>>> -   b. Gentoo subkey: 1 year maximum, expiry date renewed every 6 months.
>>> +   b. Signing subkey: 1 year maximum, expiry date renewed every 6 months.
>>>  
>>>  5. Create a revocation certificate & store it hardcopy offsite securely
>>>     (it's about ~300 bytes).
>>>
>>
>> I lost track of this due to other priorities, but picking through some of the
>> follow-up messages about the lead time on renewals and all, I don't have a
>> problem with that.  But why is the maximum of one year on subkey/signing key
>> expiration still here?
> 
> Because I've started with small changes, and the thing you're asking
> about is changed in a followup patch.  Please read the final text
> instead of wrongly assuming something from irrelevant change.

Yep, you're right.  Sorry about that!  I am fine with the specified timeframe
in the current iteration.


>>
>> I'm not seeing a lot of additional follow-up on that, but that is still too
>> short.  Two years is perfectly fine in this case.  I'd prefer three years
>> myself, but am willing to compromise for two.  I am not doing one year unless
>> someone drops some really convincing logic on me.  And no, scrawling "logic" on
>> the side of an anvil doesn't count.
>>
>> Does anyone know what the other projects require for their keys?  Without a
>> proper explanation of //why// one year needs to be the maximum, looking to what
>> other projects use seems sensible for guidance.
>>
>> I can't seem to find any specific guidance from Debian, but FreeBSD appears to
>> be fine with three years on their committer keys:
>>
>> """
>> A three year key lifespan is short enough to obsolete keys weakened by
>> advancing computer power, but long enough to reduce key management problems.
>> """
>>
>> https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/article.html#pgpkeys
>>

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic