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

[Richard Yao]

> On Jul 5, 2018, at 4:53 PM, Michał Górny <mgorny@g.o> 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@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-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@×××××××××××××××××××××××××××××××.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
>
>