[gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update; full text

[Michał Górny]

W dniu śro, 04.07.2018 o godzinie 12∶23 +0200, użytkownik Michał Górny
napisał:
> Hi, everyone.
>
> Following comments and other discussion, here's a bigger patch set
> that updates GLEP 63 to v2.

And of course I forgot to include the full text.  Here it is:

---
GLEP: 63
Title: Gentoo OpenPGP policies
Author: Robin H. Johnson <robbat2@g.o>,
        Andreas K. Hüttel <dilfridge@g.o>,
        Marissa Fischer <blogtodiffer@×××××.com>
Type: Standards Track
Status: Final
Version: 2
Created: 2013-02-18
Last-Modified: 2018-07-04
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 recommended key expiration rules have been moved to the minimal
  specification. Changing the expiration date of existing keys is possible
  in-place so there is no need to provide for transitional 'minimum' value.

  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. Primary key and a dedicated signing subkey, both of EITHER:

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

   b. ECC, curve 25519

3. Key expiration:

   a. Primary key: 3 years maximum

   b. Gentoo subkey: 1 year maximum

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

5. 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@×××××××××××××××××××××××××××××××.net=%g

       # when making an OpenPGP certification, use a stronger digest than the default SHA1:
       cert-digest-algo SHA256

2. Primary key and a dedicated signing subkey, both of type RSA, 2048 bits
   (OpenPGP v4 key format or later)

3. Key expiration renewal:

   a. Primary key: annual

   b. Gentoo subkey: every 6 months

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