GLEP:63

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

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

Bare minimum requirements
  SHA2-series output digest (SHA1 digests internally permitted), 256bit or more personal-digest-preferences SHA256  Root key and signing subkey of EITHER:   DSA, 2048-bit  RSA, >=2048 bits, RSAv4 or later only   Key expiry: 5 years maximum  Upload your key to the SKS keyserver rotation before usage! 

Recommendations
  Copy /usr/share/gnupg/gpg-conf.skel to ~/.gnupg/gpg.conf, append the block given in the FAQ section of this GLEP. <li> SHA2-series digest on output and certifications personal-digest-preferences SHA256 cert-digest-algo SHA256 <li> Root key type RSA, 4096 bits, RSAv4 or later This may require creating an entirely new key. <li> Dedicated signing subkey of EITHER:  <li> DSA 2048 bits exactly. <li> RSA 4096 bits exactly. </ol> <li> Key expiry:  <li> Root key: 3 years maximum, expiry date renewed annually. <li> Gentoo subkey: 1 year maximum, expiry date renewed every 6 months. </ol> <li> Create a revocation certificate & store it hardcopy offsite securely (it's about ~300 bytes). <li> Encrypted backup of your secret keys. <li> Include an unambiguous indicator of which key made a signature: in your gpg.conf, add: sig-notation issuer-fpr@notations.openpgp.fifthhorseman.net=%g </ol>
 * 1) include an unambiguous indicator of which key made a signature:
 * 2) (see http://thread.gmane.org/gmane.mail.notmuch.general/3721/focus=7234)
 * 3) (and http://www.ietf.org/mail-archive/web/openpgp/current/msg00405.html)

Notes / FAQ
keyserver pool.sks-keyservers.net
 * Ok, so how do I follow this? : See the Debian GPG documentation, or this guide to creating a new GPG key
 * How can I be really sure / paranoid enough? : See the RiseUp.net OpenPGP best practices
 * When should I update my key expiry date? : You should update your key expiry date with the 'expire</tt>' command (remember to do all subkeys) every 3-6 months, as well as before key expiry and major keysigning events.
 * Can you give me a full ~/.gnupg/gpg.conf</tt> file? :

emit-version

default-recipient-self


 * 1) -- All of the below portion from the RiseUp.net OpenPGP best practices, and
 * 2) -- many of them are also in the Debian GPG documentation.

fixed-list-mode
 * 1) when outputting certificates, view user IDs distinctly from keys:

keyid-format 0xlong
 * 1) long keyids are more collision-resistant than short keyids (it's trivial to make a key
 * 2) with any desired short keyid)
 * 3) NOTE: this breaks kmail gnupg support!

personal-digest-preferences SHA512 SHA384 SHA256 SHA224
 * 1) when multiple digests are supported by all recipients, choose the strongest one:

default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 BZIP2 ZLIB ZIP Uncompressed
 * 1) preferences chosen for new keys should prioritize stronger algorithms:

use-agent
 * 1) If you use a graphical environment (and even if you don't) you should be using an agent:
 * 2) (similar arguments as  https://www.debian-administration.org/users/dkg/weblog/64)

verify-options show-uid-validity list-options show-uid-validity
 * 1) You should always know at a glance which User IDs gpg thinks are legitimately bound to
 * 2) the keys in your keyring:

sig-notation issuer-fpr@notations.openpgp.fifthhorseman.net=%g
 * 1) include an annotation of the certifying key fingerprint

cert-digest-algo SHA256 FEATURES="${FEATURES} sign"
 * 1) when making an OpenPGP certification, use a stronger digest than the default SHA1:
 * What about elliptic-curve/ECC keys? : They are not used finalized in the OpenPGP draft specification, esp. in light of concerns that the NSA may have chosen some of the key values to be backdoor values; when the specification includes curves that are known to be free of this concern, this GLEP should be revised.
 * What about larger keys? : Keys with sizes RSA >4096 bits, and DSA >2048 bits are not supported in the OpenPGP specification, and there may be interoperability issues with them.
 * How about make.conf</tt> settings? :

PORTAGE_GPG_DIR="/home/exampleuser/.gnupg"

PORTAGE_GPG_KEY="0x1234567890ABCDEF!"
 * 1) You should use the full 16-character key handle to your signing
 * 2) subkey, with a '!' on the end to ensure that subkey is used.
 * What's this weird fifthhorseman</tt> thingy? : It's actually a workaround for a protocol weakness (which will be addressed in a future version of the OpenPGP standard). The identifier "issuer-fpr@notations.openpgp.fifthhorseman.net</tt>" is from the developer that proposed the extension and stays constant. "%g" is automatically replaced by the fingerprint of the key that makes the signature. The resulting annotation is added in the signature.

Gentoo LDAP
All Gentoo developers must list the complete GPG fingerprint for their root keys in the "gpgfingerprint</tt>" 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</tt>" field will be removed, as it is a subset of the fingerprint field. In any place that presently displays the "gpgkey</tt>" field, the last 16 hex digits of the fingerprint should be displayed instead.

Recommended / planned tools
This section is included for informational purposes; the exact specification of these tools is outside the scope of this GLEP.

Most of the key tracking is work in progress in the gentoo-keys project. The resulting toolset should also include easy-to-use tools for developers to generate new keys (using the recommendations) and update expiry dates. A final user-formatted keyring will be generated to be hosted on the Gentoo API site.

Backwards Compatibility
There is no consistent standard for GPG usage in Gentoo to date. There is conflicting information in the Devmanual and the GnuPG Gentoo user guide. 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
 * Debian GPG documentation
 * RiseUp.net OpenPGP best practices
 * ENISA Algorithms, Key Sizes and Parameters Report 2013

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