[gentoo-dev] [PATCH v3 00/12] GLEP 63 update

[gentoo-dev] [PATCH v3 00/12] GLEP 63 update

[Michał Górny]

Hi,

Here's third version of the patches.  I've incorporated the feedback
so far and reordered the patches (again) to restore their
degree-of-compatibility order.  The full text is included below.


Michał Górny (12):
  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 separation 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: Make 2-yearly expiration term mandatory
  glep-0063: Require renewal 2 weeks before expiration
  glep-0063: Disallow using DSA keys

 glep-0063.rst | 97 +++++++++++++++++++++++++++++++++------------------
 1 file changed, 64 insertions(+), 33 deletions(-)


---
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>
Type: Standards Track
Status: Final
Version: 2
Created: 2013-02-18
Last-Modified: 2018-07-05
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 time of 2 years 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.

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. SHA2-series output digest (SHA1 digests internally permitted),
   256bit or more::

       personal-digest-preferences SHA256

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 at most 2 years

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. 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
   (OpenPGP v4 key format or later)

3. Key expiration renewed annually

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

5. 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, with optional spaces every 8 hex digits. Regular expression for
validation::

    ^([[:space:]]*[[:xdigit:]]{8}){5}$

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 by Robin Hugh Johnson, Andreas K. Hüttel, Marissa Fischer.

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/.


--
Best regards,
Michał Górny

-- 
2.18.0

[gentoo-dev] [PATCH v3 01/12] 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 | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/glep-0063.rst b/glep-0063.rst
index c59d545..dd61ecc 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -1,6 +1,6 @@
 ---
 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>
@@ -8,7 +8,7 @@ Type: Standards Track
 Status: Final
 Version: 1
 Created: 2013-02-18
-Last-Modified: 2015-08-25
+Last-Modified: 2018-07-02
 Post-History: 2013-11-10
 Content-Type: text/x-rst
 ---
@@ -21,22 +21,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 +125,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::
-- 
2.18.0

[gentoo-dev] [PATCH v3 02/12] 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 dd61ecc..8e4f0d5 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -49,7 +49,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
 
@@ -101,7 +101,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 v3 03/12] 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 | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/glep-0063.rst b/glep-0063.rst
index 8e4f0d5..a56ae65 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -8,7 +8,7 @@ Type: Standards Track
 Status: Final
 Version: 1
 Created: 2013-02-18
-Last-Modified: 2018-07-02
+Last-Modified: 2018-07-05
 Post-History: 2013-11-10
 Content-Type: text/x-rst
 ---
@@ -115,7 +115,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 v3 04/12] 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 a56ae65..318717a 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -45,7 +45,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
 
@@ -101,7 +101,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.
 
@@ -113,7 +113,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.
 
@@ -125,7 +125,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 v3 05/12] glep-0063: Split out the signing subkey into a separation 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 318717a..2d30f68 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -45,15 +45,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
 ---------------
@@ -105,7 +108,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 v3 06/12] 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 2d30f68..b995d8e 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -40,6 +40,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::
 
@@ -60,6 +64,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 v3 07/12] 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 b995d8e..60b68ca 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -6,7 +6,7 @@ Author: Robin H. Johnson <robbat2@gentoo.org>,
         Marissa Fischer <blogtodiffer@gmail.com>
 Type: Standards Track
 Status: Final
-Version: 1
+Version: 1.1
 Created: 2013-02-18
 Last-Modified: 2018-07-05
 Post-History: 2013-11-10
@@ -24,6 +24,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
 ==========
 
@@ -112,15 +121,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:
 
@@ -173,6 +180,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 v3 08/12] 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 60b68ca..f6f2959 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -33,6 +33,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
 ==========
 
@@ -67,6 +69,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 v3 09/12] 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 f6f2959..8c3dd1b 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -35,6 +35,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
 ==========
 
@@ -125,24 +128,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 v3 10/12] glep-0063: Make 2-yearly expiration term mandatory

[Michał Górny]

Replace the disjoint 'minimum' and 'recommendation' for expiration with
a single requirement.  Make it 2 years.  Also, remove disjoint
expiration recommendation for the primary key and subkeys since many
developers fail at implementing that anyway.
---
 glep-0063.rst | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/glep-0063.rst b/glep-0063.rst
index 8c3dd1b..0fdf5ed 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -6,7 +6,7 @@ Author: Robin H. Johnson <robbat2@gentoo.org>,
         Marissa Fischer <blogtodiffer@gmail.com>
 Type: Standards Track
 Status: Final
-Version: 1.1
+Version: 2
 Created: 2013-02-18
 Last-Modified: 2018-07-05
 Post-History: 2013-11-10
@@ -27,6 +27,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 time of 2 years 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]_.
@@ -74,7 +79,7 @@ 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 at most 2 years
 
 5. Upload your key to the SKS keyserver rotation before usage!
 
@@ -131,11 +136,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
 
 4. Create a revocation certificate & store it hardcopy offsite securely
    (it's about ~300 bytes).
-- 
2.18.0

[gentoo-dev] [PATCH v3 11/12] 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 0fdf5ed..d41a2a0 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -32,6 +32,10 @@ v2
   by a single requirement. The rules have been simplified to use
   the same time of 2 years 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]_.
@@ -81,7 +85,10 @@ not be used to commit.
 
 4. Expiration date on key and all subkeys set to at most 2 years
 
-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 v3 12/12] 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 d41a2a0..33cbb67 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -36,6 +36,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]_.
@@ -77,11 +79,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 at most 2 years
 
-- 
2.18.0

Re: [gentoo-dev] [PATCH v3 08/12] glep-0063: Allow ECC curve 25519 keys

[Jonas Stein]

[-- Attachment #1.1: Type: text/plain, Size: 488 bytes --]

>     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!

I think we should ensure first that everything works fine with ECC. Last
time I checked, ECC was a nightmare.

Some SKS server could not handle ECC... and so on.

It would be great if a ECC user could sum up in a list where we still
need some progress.

-- 
Best,
Jonas


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-dev] [PATCH v3 10/12] glep-0063: Make 2-yearly expiration term mandatory

[Ulrich Mueller]

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

>>>>> On Thu, 5 Jul 2018, Michał Górny wrote:

> Replace the disjoint 'minimum' and 'recommendation' for expiration
> with a single requirement. Make it 2 years. Also, remove disjoint
> expiration recommendation for the primary key and subkeys since many
> developers fail at implementing that anyway.

Still NACK. If expiration is exactly 2 years and renewal must happen
2 weeks before the expiry date, then it is not possible to keep the
same date.

Example: The key will expire at 2018-12-31, so it must be renewed at
2018-12-17 or earlier. This will make it impossible to keep the same
month and day (unless one would reset it to 2019-12-31, which is only
one year though).

So please, make it something like 2 years + 3 months.

Ulrich

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

Re: [gentoo-dev] [PATCH v3 08/12] glep-0063: Allow ECC curve 25519 keys

[Ulrich Mueller]

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

>>>>> On Thu, 5 Jul 2018, Jonas Stein wrote:

>> 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!

> I think we should ensure first that everything works fine with ECC.
> Last time I checked, ECC was a nightmare.

> Some SKS server could not handle ECC... and so on.

IIRC, it has also been pointed out that ECC is not part of the OpenPGP
standard (yet)?

Maybe we should better omit it. It shouldn't be too complicated for
developers to add a dedicated RSA signing key for Gentoo if necessary
(especially, since someone using ECC could be considered an advanced
GnuPG user).

Ulrich

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

Re: [gentoo-dev] [PATCH v3 10/12] glep-0063: Make 2-yearly expiration term mandatory

[Robin H. Johnson]

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

On Fri, Jul 06, 2018 at 07:43:56AM +0200, Ulrich Mueller wrote:
> >>>>> On Thu, 5 Jul 2018, Michał Górny wrote:
> 
> > Replace the disjoint 'minimum' and 'recommendation' for expiration
> > with a single requirement. Make it 2 years. Also, remove disjoint
> > expiration recommendation for the primary key and subkeys since many
> > developers fail at implementing that anyway.
> 
> Still NACK. If expiration is exactly 2 years and renewal must happen
> 2 weeks before the expiry date, then it is not possible to keep the
> same date.
> 
> Example: The key will expire at 2018-12-31, so it must be renewed at
> 2018-12-17 or earlier. This will make it impossible to keep the same
> month and day (unless one would reset it to 2019-12-31, which is only
> one year though).
> 
> So please, make it something like 2 years + 3 months.
option a)
2 years + N:
2 weeks <= N <= 3 months.

option b)
Change the wording to be 'at most 2 years' instead of 'exactly 2 years'.

Separately:
Is two weeks enough time for a new key distribution to users?

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

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

Re: [gentoo-dev] [PATCH v3 10/12] glep-0063: Make 2-yearly expiration term mandatory

[Michał Górny]

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

W dniu pią, 06.07.2018 o godzinie 07∶43 +0200, użytkownik Ulrich Mueller
napisał:
> > > > > > On Thu, 5 Jul 2018, Michał Górny wrote:
> > Replace the disjoint 'minimum' and 'recommendation' for expiration
> > with a single requirement. Make it 2 years. Also, remove disjoint
> > expiration recommendation for the primary key and subkeys since many
> > developers fail at implementing that anyway.
> 
> Still NACK. If expiration is exactly 2 years and renewal must happen
> 2 weeks before the expiry date, then it is not possible to keep the
> same date.

Did you even read the text?  It's 'at most 2 years'.  If you renew it
every year, you can achieve the desired effect while keeping far ahead
of the required schedule.

> Example: The key will expire at 2018-12-31, so it must be renewed at
> 2018-12-17 or earlier. This will make it impossible to keep the same
> month and day (unless one would reset it to 2019-12-31, which is only
> one year though).
> 
> So please, make it something like 2 years + 3 months.
> 

I really see no point in added complexity just so that someone could
bend the standard to the limits.

-- 
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 v3 10/12] glep-0063: Make 2-yearly expiration term mandatory

[Michał Górny]

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

W dniu pią, 06.07.2018 o godzinie 06∶08 +0000, użytkownik Robin H.
Johnson napisał:
> On Fri, Jul 06, 2018 at 07:43:56AM +0200, Ulrich Mueller wrote:
> > > > > > > On Thu, 5 Jul 2018, Michał Górny wrote:
> > > Replace the disjoint 'minimum' and 'recommendation' for expiration
> > > with a single requirement. Make it 2 years. Also, remove disjoint
> > > expiration recommendation for the primary key and subkeys since many
> > > developers fail at implementing that anyway.
> > 
> > Still NACK. If expiration is exactly 2 years and renewal must happen
> > 2 weeks before the expiry date, then it is not possible to keep the
> > same date.
> > 
> > Example: The key will expire at 2018-12-31, so it must be renewed at
> > 2018-12-17 or earlier. This will make it impossible to keep the same
> > month and day (unless one would reset it to 2019-12-31, which is only
> > one year though).
> > 
> > So please, make it something like 2 years + 3 months.
> 
> option a)
> 2 years + N:
> 2 weeks <= N <= 3 months.
> 
> option b)
> Change the wording to be 'at most 2 years' instead of 'exactly 2 years'.

That *is* the wording.

> Separately:
> Is two weeks enough time for a new key distribution to users?

I originally wanted to specify one month but k_f insisted on something
shorter.  2 weeks were the compromise we agreed on.  That said, I'd say
weekly 'gpg --refresh' is what we should recommend as the bare minimum.

That said, the point of two weeks is mostly to give us time to remind
developers that their key is expiring and to give them time to actually
read their mail and do it before it actually expires.

-- 
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 v3 10/12] glep-0063: Make 2-yearly expiration term mandatory

[Ulrich Mueller]

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

>>>>> On Fri, 6 Jul 2018, Robin H Johnson wrote:

> On Fri, Jul 06, 2018 at 07:43:56AM +0200, Ulrich Mueller wrote:
>> Still NACK. If expiration is exactly 2 years and renewal must happen
>> 2 weeks before the expiry date, then it is not possible to keep the
>> same date.
>> 
>> Example: The key will expire at 2018-12-31, so it must be renewed at
>> 2018-12-17 or earlier. This will make it impossible to keep the same
>> month and day (unless one would reset it to 2019-12-31, which is only
>> one year though).
>> 
>> So please, make it something like 2 years + 3 months.

> option a)
> 2 years + N:
> 2 weeks <= N <= 3 months.

You don't want the first <= there. If it's 2 years + 2 weeks then devs
would have only one exact day for renewal of their key.

> option b)
> Change the wording to be 'at most 2 years' instead of 'exactly 2 years'.

I don't understand. How would this solve the problem?

> Separately:
> Is two weeks enough time for a new key distribution to users?

Ulrich

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

Re: [gentoo-dev] [PATCH v3 10/12] glep-0063: Make 2-yearly expiration term mandatory

[Robin H. Johnson]

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

On Fri, Jul 06, 2018 at 08:18:32AM +0200, Michał Górny wrote:
> > option a)
> > 2 years + N:
> > 2 weeks <= N <= 3 months.
> > 
> > option b)
> > Change the wording to be 'at most 2 years' instead of 'exactly 2 years'.
> That *is* the wording.
I apologize. I took ulm's post as canonical and didn't confirm in the
original GLEP text.

Further change to follow in response to the original text.

> > Separately:
> > Is two weeks enough time for a new key distribution to users?
> 
> I originally wanted to specify one month but k_f insisted on something
> shorter.  2 weeks were the compromise we agreed on.  That said, I'd say
> weekly 'gpg --refresh' is what we should recommend as the bare minimum.
> 
> That said, the point of two weeks is mostly to give us time to remind
> developers that their key is expiring and to give them time to actually
> read their mail and do it before it actually expires.
Please let's start reminding them BEFORE that. I have seen a lot of
.away files over the last decade, and taking a 2-week offline vacation
does happen.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

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

[gentoo-dev] Re: [PATCH v3 00/12] GLEP 63 update

[Robin H. Johnson]

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

On Thu, Jul 05, 2018 at 10:53:51PM +0200, Michał Górny wrote:
> Here's third version of the patches.  I've incorporated the feedback
> so far and reordered the patches (again) to restore their
> degree-of-compatibility order.  The full text is included below.
...
> v2
>   The distinct minimal and recommended expirations have been replaced
>   by a single requirement. The rules have been simplified to use
>   the same time of 2 years for both the primary key and subkeys.
-the same time of 2 years ...
+the same 2 year maximum renewal time ...

>   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.
Do we want to state that infra will start contact devs before this, or
keep that as an implementation detail?

> 4. Expiration date on key and all subkeys set to at most 2 years
-at most 2 years.
+at most 2 years from generation or refresh of expiry.

> Recommendations
> ---------------
...
> 3. Key expiration renewed annually
Can we please suggest it's updated to a fixed day of the year? 

> 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::
Can we please drop the spaces in the field in LDAP. I don't care if we
display it with spaces, but dropping them in LDAP would be helpful.

> Copyright
> =========
> Copyright (c) 2013 by Robin Hugh Johnson, Andreas K. Hüttel, Marissa Fischer.
Please update the copyright date:
2013,2018
and add yourself as a copyright owner for the scale of these changes.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

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

Re: [gentoo-dev] [PATCH v3 10/12] glep-0063: Make 2-yearly expiration term mandatory

[Ulrich Mueller]

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

>>>>> On Fri, 06 Jul 2018, Michał Górny wrote:

> Did you even read the text? It's 'at most 2 years'. If you renew it
> every year, you can achieve the desired effect while keeping far
> ahead of the required schedule.

So effectively we're down from 5 years to 1 year also for the main
key, as a mandatory requirement? That is not what I have perceived
as the consensus in the discussion so far.

> I really see no point in added complexity just so that someone could
> bend the standard to the limits.

It isn't complicated in the current version of GLEP 63 ("5 years
maximum"). Simply keep that wording, or moderately shorten it, to
something like 3 years, or 2.25 years. (Or if you prefer round
numbers, 800 days, or 70000000 seconds.) :-)

Ulrich

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

Re: [gentoo-dev] [PATCH v3 10/12] glep-0063: Make 2-yearly expiration term mandatory

[Michał Górny]

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

W dniu pią, 06.07.2018 o godzinie 06∶28 +0000, użytkownik Robin H.
Johnson napisał:
> On Fri, Jul 06, 2018 at 08:18:32AM +0200, Michał Górny wrote:
> > > option a)
> > > 2 years + N:
> > > 2 weeks <= N <= 3 months.
> > > 
> > > option b)
> > > Change the wording to be 'at most 2 years' instead of 'exactly 2 years'.
> > 
> > That *is* the wording.
> 
> I apologize. I took ulm's post as canonical and didn't confirm in the
> original GLEP text.
> 
> Further change to follow in response to the original text.
> 
> > > Separately:
> > > Is two weeks enough time for a new key distribution to users?
> > 
> > I originally wanted to specify one month but k_f insisted on something
> > shorter.  2 weeks were the compromise we agreed on.  That said, I'd say
> > weekly 'gpg --refresh' is what we should recommend as the bare minimum.
> > 
> > That said, the point of two weeks is mostly to give us time to remind
> > developers that their key is expiring and to give them time to actually
> > read their mail and do it before it actually expires.
> 
> Please let's start reminding them BEFORE that. I have seen a lot of
> .away files over the last decade, and taking a 2-week offline vacation
> does happen.

The problem is, Gentoo developers are really hostile people.  If you
remind them *before* the term, they are not very nice because how does
someone dare remind very important developer who was planning to do it
week before expiration, and now he needed to waste his precious time
reading your mail.

-- 
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 v3 10/12] glep-0063: Make 2-yearly expiration term mandatory

[Michał Górny]

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

W dniu pią, 06.07.2018 o godzinie 08∶40 +0200, użytkownik Ulrich Mueller
napisał:
> > > > > > On Fri, 06 Jul 2018, Michał Górny wrote:
> > Did you even read the text? It's 'at most 2 years'. If you renew it
> > every year, you can achieve the desired effect while keeping far
> > ahead of the required schedule.
> 
> So effectively we're down from 5 years to 1 year also for the main
> key, as a mandatory requirement? That is not what I have perceived
> as the consensus in the discussion so far.

No, effectively we have 2 years unless developers are picky, in which
case it's their problem and not mine.

> > I really see no point in added complexity just so that someone could
> > bend the standard to the limits.
> 
> It isn't complicated in the current version of GLEP 63 ("5 years
> maximum").

5 years is insane.

>  Simply keep that wording, or moderately shorten it, to
> something like 3 years, or 2.25 years. (Or if you prefer round
> numbers, 800 days, or 70000000 seconds.) :-)
> 

If I do it 3 years, you're going to complain that now you have to update
it every 2 years because it's not 3 years + 2 weeks...

-- 
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 v3 10/12] glep-0063: Make 2-yearly expiration term mandatory

[Brian Dolbec]

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

On Fri, 06 Jul 2018 08:18:32 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> W dniu pią, 06.07.2018 o godzinie 06∶08 +0000, użytkownik Robin H.
> Johnson napisał:
> > On Fri, Jul 06, 2018 at 07:43:56AM +0200, Ulrich Mueller wrote:  
> > > > > > > > On Thu, 5 Jul 2018, Michał Górny wrote:  
> > > > Replace the disjoint 'minimum' and 'recommendation' for
> > > > expiration with a single requirement. Make it 2 years. Also,
> > > > remove disjoint expiration recommendation for the primary key
> > > > and subkeys since many developers fail at implementing that
> > > > anyway.  
> > > 
> > > Still NACK. If expiration is exactly 2 years and renewal must
> > > happen 2 weeks before the expiry date, then it is not possible to
> > > keep the same date.
> > > 
> > > Example: The key will expire at 2018-12-31, so it must be renewed
> > > at 2018-12-17 or earlier. This will make it impossible to keep
> > > the same month and day (unless one would reset it to 2019-12-31,
> > > which is only one year though).
> > > 
> > > So please, make it something like 2 years + 3 months.  
> > 
> > option a)
> > 2 years + N:
> > 2 weeks <= N <= 3 months.
> > 
> > option b)
> > Change the wording to be 'at most 2 years' instead of 'exactly 2
> > years'.  
> 
> That *is* the wording.
> 
> > Separately:
> > Is two weeks enough time for a new key distribution to users?  
> 
> I originally wanted to specify one month but k_f insisted on something
> shorter.  2 weeks were the compromise we agreed on.  That said, I'd
> say weekly 'gpg --refresh' is what we should recommend as the bare
> minimum.
> 
> That said, the point of two weeks is mostly to give us time to remind
> developers that their key is expiring and to give them time to
> actually read their mail and do it before it actually expires.
> 

I have gkeys spec-check start warning at 30 days, and it has been my
experience that often it only gets renewed last minute (depends on how
active the developer is.  As it is one of those things that gets put
off thinking there is still lots of time... But also, many of those had
keys that did not meet the spec requirements.

-- 
Brian Dolbec <dolsen>


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-dev] [PATCH v3 10/12] glep-0063: Make 2-yearly expiration term mandatory

[Brian Dolbec]

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

On Fri, 06 Jul 2018 08:51:12 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> W dniu pią, 06.07.2018 o godzinie 06∶28 +0000, użytkownik Robin H.
> Johnson napisał:
> > On Fri, Jul 06, 2018 at 08:18:32AM +0200, Michał Górny wrote:  
> > > > option a)
> > > > 2 years + N:
> > > > 2 weeks <= N <= 3 months.
> > > > 
> > > > option b)
> > > > Change the wording to be 'at most 2 years' instead of 'exactly
> > > > 2 years'.  
> > > 
> > > That *is* the wording.  
> > 
> > I apologize. I took ulm's post as canonical and didn't confirm in
> > the original GLEP text.
> > 
> > Further change to follow in response to the original text.
> >   
> > > > Separately:
> > > > Is two weeks enough time for a new key distribution to users?  
> > > 
> > > I originally wanted to specify one month but k_f insisted on
> > > something shorter.  2 weeks were the compromise we agreed on.
> > > That said, I'd say weekly 'gpg --refresh' is what we should
> > > recommend as the bare minimum.
> > > 
> > > That said, the point of two weeks is mostly to give us time to
> > > remind developers that their key is expiring and to give them
> > > time to actually read their mail and do it before it actually
> > > expires.  
> > 
> > Please let's start reminding them BEFORE that. I have seen a lot of
> > .away files over the last decade, and taking a 2-week offline
> > vacation does happen.  
> 
> The problem is, Gentoo developers are really hostile people.  If you
> remind them *before* the term, they are not very nice because how does
> someone dare remind very important developer who was planning to do it
> week before expiration, and now he needed to waste his precious time
> reading your mail.
> 

I never experienced a single developer show or say anything like you
are suggesting.  Most, thanked me for the reminder whether it was in
IRC or email.  And since I always cc'd the gkeys alias (most needed
changes to meet the spec too), I'm sure Kristian will confirm this.

-- 
Brian Dolbec <dolsen>


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-dev] Re: [PATCH v3 00/12] GLEP 63 update

[Michał Górny]

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

W dniu pią, 06.07.2018 o godzinie 06∶36 +0000, użytkownik Robin H.
Johnson napisał:
> On Thu, Jul 05, 2018 at 10:53:51PM +0200, Michał Górny wrote:
> > Here's third version of the patches.  I've incorporated the feedback
> > so far and reordered the patches (again) to restore their
> > degree-of-compatibility order.  The full text is included below.
> 
> ...
> > v2
> >   The distinct minimal and recommended expirations have been replaced
> >   by a single requirement. The rules have been simplified to use
> >   the same time of 2 years for both the primary key and subkeys.
> 
> -the same time of 2 years ...
> +the same 2 year maximum renewal time ...
> 
> >   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.
> 
> Do we want to state that infra will start contact devs before this, or
> keep that as an implementation detail?

Implementation detail.

> 
> > 4. Expiration date on key and all subkeys set to at most 2 years
> 
> -at most 2 years.
> +at most 2 years from generation or refresh of expiry.

Now, this won't really work because it's self-propagating date.  You're
soon going to see keys with 10 years to expiration because if you update
the date 5 times from 'refresh of expiry', that's what you get.

I get what you're trying to say but I can't really think of a sane way
of stating that.  Maybe I should just explicitly state '(plus the period
specified in point 5)'.

> 
> > Recommendations
> > ---------------
> 
> ...
> > 3. Key expiration renewed annually
> 
> Can we please suggest it's updated to a fixed day of the year? 

Sure.

> 
> > 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::
> 
> Can we please drop the spaces in the field in LDAP. I don't care if we
> display it with spaces, but dropping them in LDAP would be helpful.

I'm all for it.  I really do wonder how they ended up there in the first
place.

> 
> > Copyright
> > =========
> > Copyright (c) 2013 by Robin Hugh Johnson, Andreas K. Hüttel, Marissa Fischer.
> 
> Please update the copyright date:
> 2013,2018
> and add yourself as a copyright owner for the scale of these changes.
> 

-- 
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 v3 08/12] glep-0063: Allow ECC curve 25519 keys

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 1543 bytes --]

On 07/06/2018 07:49 AM, Ulrich Mueller wrote:
>>>>>> On Thu, 5 Jul 2018, Jonas Stein wrote:
> 
>>> 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!
> 
>> I think we should ensure first that everything works fine with ECC.
>> Last time I checked, ECC was a nightmare.
> 
>> Some SKS server could not handle ECC... and so on.
> 
> IIRC, it has also been pointed out that ECC is not part of the OpenPGP
> standard (yet)?
> 

Right, the NIST curves prime curves are defined in RFC6637 but
Curve25519/EdDSA is only implemented in GnuPG and part of the draft
rfc4880bis (WG isn't currently active, so not expected a v5 any time soon).

ECC is also only implemented in gnupg >=2.1 , so as mentioned earlier,
gnupg 1.4 (which is still maintained and often used for smaller
footprint or backwards compat to v3 keys) will not be able to use it.

> Maybe we should better omit it. It shouldn't be too complicated for
> developers to add a dedicated RSA signing key for Gentoo if necessary
> (especially, since someone using ECC could be considered an advanced
> GnuPG user).

If the primary key is ECC, clients not supporting it won't be able to
use the key material even if the signing subkey is RSA.

> 
> Ulrich
> 


-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] Re: [PATCH v3 00/12] GLEP 63 update

[Christopher Head]

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

>> > 4. Expiration date on key and all subkeys set to at most 2 years
>> 
>> -at most 2 years.
>> +at most 2 years from generation or refresh of expiry.
>
>Now, this won't really work because it's self-propagating date.  You're
>soon going to see keys with 10 years to expiration because if you
>update
>the date 5 times from 'refresh of expiry', that's what you get.
>
>I get what you're trying to say but I can't really think of a sane way
>of stating that.  Maybe I should just explicitly state '(plus the
>period
>specified in point 5)'.

“The expiry date of the key shall never be more than two years in the future”?

-- 
Christopher Head

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 244 bytes --]

Re: [gentoo-dev] [PATCH v3 00/12] GLEP 63 update

[Richard Yao]

> On Jul 5, 2018, at 4:53 PM, Michał Górny <mgorny@gentoo.org> wrote:
> 
> Hi,
> 
> Here's third version of the patches.  I've incorporated the feedback
> so far and reordered the patches (again) to restore their
> degree-of-compatibility order.  The full text is included below.
> 
> 
> Michał Górny (12):
>  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 separation 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: Make 2-yearly expiration term mandatory
>  glep-0063: Require renewal 2 weeks before expiration
>  glep-0063: Disallow using DSA keys
> 
> glep-0063.rst | 97 +++++++++++++++++++++++++++++++++------------------
> 1 file changed, 64 insertions(+), 33 deletions(-)
> 
> 
> ---
> 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>
> Type: Standards Track
> Status: Final
> Version: 2
> Created: 2013-02-18
> Last-Modified: 2018-07-05
> 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 time of 2 years 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.
> 
> 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. SHA2-series output digest (SHA1 digests internally permitted),
>   256bit or more::
> 
>       personal-digest-preferences SHA256
> 
> 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 at most 2 years
> 
> 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. Copy ``/usr/share/gnupg/gpg-conf.skel`` to ``~/.gnupg/gpg.conf``, append
>   the following block::
That file no longer exists.
> 
>       keyserver pool.sks-keyservers.net
This is less secure than the default according to K_F in #gentoo-infra.
> 
>       emit-version
K_F indicated that this harms security too.
> 
>       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
This makes the key ids shorter. ^_^;;
> 
>       # 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

Could we just drop the recommended gpg.conf? Many of these suggestions are outdated.
> 
> 2. Primary key and the signing subkey are both of type RSA, 2048 bits
>   (OpenPGP v4 key format or later)
> 
> 3. Key expiration renewed annually
> 
> 4. Create a revocation certificate & store it hardcopy offsite securely
>   (it's about ~300 bytes).
> 
> 5. 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, with optional spaces every 8 hex digits. Regular expression for
> validation::
> 
>    ^([[:space:]]*[[:xdigit:]]{8}){5}$
> 
> 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 by Robin Hugh Johnson, Andreas K. Hüttel, Marissa Fischer.
> 
> 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/.
> 
> 
> --
> Best regards,
> Michał Górny
> 
> -- 
> 2.18.0
> 
> 

Re: [gentoo-dev] Re: [PATCH v3 00/12] GLEP 63 update

[Michał Górny]

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

W dniu pią, 06.07.2018 o godzinie 06∶36 +0000, użytkownik Robin H.
Johnson napisał:
> On Thu, Jul 05, 2018 at 10:53:51PM +0200, Michał Górny wrote:
> > Here's third version of the patches.  I've incorporated the feedback
> > so far and reordered the patches (again) to restore their
> > degree-of-compatibility order.  The full text is included below.
> 
> ...
> > v2
> >   The distinct minimal and recommended expirations have been replaced
> >   by a single requirement. The rules have been simplified to use
> >   the same time of 2 years for both the primary key and subkeys.
> 
> -the same time of 2 years ...
> +the same 2 year maximum renewal time ...

I've changed this as part of different changes, please wait for v4.

> 
> >   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.
> 
> Do we want to state that infra will start contact devs before this, or
> keep that as an implementation detail?
> 
> > 4. Expiration date on key and all subkeys set to at most 2 years
> 
> -at most 2 years.
> +at most 2 years from generation or refresh of expiry.

I've instead went for lengthening the period.

> > Recommendations
> > ---------------
> 
> ...
> > 3. Key expiration renewed annually
> 
> Can we please suggest it's updated to a fixed day of the year? 

Done.

> 
> > 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::
> 
> Can we please drop the spaces in the field in LDAP. I don't care if we
> display it with spaces, but dropping them in LDAP would be helpful.

Included an extra commit for this.

> 
> > Copyright
> > =========
> > Copyright (c) 2013 by Robin Hugh Johnson, Andreas K. Hüttel, Marissa Fischer.
> 
> Please update the copyright date:
> 2013,2018
> and add yourself as a copyright owner for the scale of these changes.

Done in the first commit.  I've also added myself as an Author.

-- 
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 v3 00/12] GLEP 63 update

[Michał Górny]

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

W dniu pią, 06.07.2018 o godzinie 21∶26 -0400, użytkownik Richard Yao
napisał:
> > On Jul 5, 2018, at 4:53 PM, Michał Górny <mgorny@gentoo.org> wrote:
> > 
> > Hi,
> > 
> > Here's third version of the patches.  I've incorporated the feedback
> > so far and reordered the patches (again) to restore their
> > degree-of-compatibility order.  The full text is included below.
> > 
> > 
> > Michał Górny (12):
> >  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 separation 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: Make 2-yearly expiration term mandatory
> >  glep-0063: Require renewal 2 weeks before expiration
> >  glep-0063: Disallow using DSA keys
> > 
> > glep-0063.rst | 97 +++++++++++++++++++++++++++++++++------------------
> > 1 file changed, 64 insertions(+), 33 deletions(-)
> > 
> > 
> > ---
> > 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>
> > Type: Standards Track
> > Status: Final
> > Version: 2
> > Created: 2013-02-18
> > Last-Modified: 2018-07-05
> > 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 time of 2 years 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.
> > 
> > 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. SHA2-series output digest (SHA1 digests internally permitted),
> >   256bit or more::
> > 
> >       personal-digest-preferences SHA256
> > 
> > 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 at most 2 years
> > 
> > 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. Copy ``/usr/share/gnupg/gpg-conf.skel`` to ``~/.gnupg/gpg.conf``, append
> >   the following block::
> 
> That file no longer exists.
> > 
> >       keyserver pool.sks-keyservers.net
> 
> This is less secure than the default according to K_F in #gentoo-infra.
> > 
> >       emit-version
> 
> K_F indicated that this harms security too.
> > 
> >       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
> 
> This makes the key ids shorter. ^_^;;
> > 
> >       # 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
> 
> Could we just drop the recommended gpg.conf? Many of these suggestions are outdated.
> > 

I didn't like it either but didn't want to spent time updating it. 
Dropping completely works for me.  Done in v4.

-- 
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 v3 10/12] glep-0063: Make 2-yearly expiration term mandatory

[Michał Górny]

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

W dniu pią, 06.07.2018 o godzinie 08∶40 +0200, użytkownik Ulrich Mueller
napisał:
> > > > > > On Fri, 06 Jul 2018, Michał Górny wrote:
> > Did you even read the text? It's 'at most 2 years'. If you renew it
> > every year, you can achieve the desired effect while keeping far
> > ahead of the required schedule.
> 
> So effectively we're down from 5 years to 1 year also for the main
> key, as a mandatory requirement? That is not what I have perceived
> as the consensus in the discussion so far.
> 
> > I really see no point in added complexity just so that someone could
> > bend the standard to the limits.
> 
> It isn't complicated in the current version of GLEP 63 ("5 years
> maximum"). Simply keep that wording, or moderately shorten it, to
> something like 3 years, or 2.25 years. (Or if you prefer round
> numbers, 800 days, or 70000000 seconds.) :-)
> 

Went for 900 days.  This will be easier to test script-wise
(i.e. without having to fight over how many days a year has)
and give you a long grace period for early renewal (and for keys created
late in the year).

-- 
Best regards,
Michał Górny

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