> On Jul 5, 2018, at 4:53 PM, Michał Górny <mgo...@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 <robb...@gentoo.org>,
> Andreas K. Hüttel <dilfri...@gentoo.org>,
> Marissa Fischer <blogtodif...@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-...@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
>
>
