GLEP:63

Warning
This GLEP is no longer maintained in the Gentoo Wiki and remains here only as a historical record. Please visit https://www.gentoo.org/glep/glep-0063.html for the current version of this GLEP.

GLEP 63: Gentoo GPG key policies
Type	Standards Track
Status	Final
Author	Robin H. Johnson <robbat2@gentoo.org>, Andreas K. Hüttel <dilfridge@gentoo.org>, Marissa Fischer <blogtodiffer@gmail.com>
Editor
Replaces
Replaced by	(none)
Requires
Post History

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.

Specifications for GnuPG keys

Bare minimum requirements

1. SHA2-series output digest (SHA1 digests internally permitted), 256bit or more

   personal-digest-preferences SHA256
   

2. Root key and signing subkey of EITHER:
   1. DSA, 2048-bit
   2. RSA, >=2048 bits, RSAv4 or later only
3. Key expiry: 5 years maximum
4. Upload your key to the SKS keyserver rotation before usage!

Recommendations

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. Root key type RSA, 4096 bits, RSAv4 or later
   This may require creating an entirely new key.
3. Dedicated signing subkey of EITHER:
   1. DSA 2048 bits exactly.
   2. RSA 4096 bits exactly.
4. Key expiry:
   1. Root key: 3 years maximum, expiry date renewed annually.
   2. Gentoo 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).
6. Encrypted backup of your secret keys.

Gentoo LDAP

All Gentoo developers must list the complete GPG 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:

^([[: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 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/.