Foreword: This a wrap up of my previous email "RFC: Gentoo GPG key policies", from 2013/02/18, incorporating all of the changes from the thread at the time. http://thread.gmane.org/gmane.linux.gentoo.devel/83996 This thread does contain other implementation suggestions for Repoman, but I think that is outside the scope of this GLEP.
Apologies if my GLEP formatting is a bit rusty, it's been a while since I wrote one, and I wasn't sure how to combine many of the pieces of information here. Suggestions on breaking down the information differently welcomed. This should hopefully be a sufficient final proposal for the council to take as strongly guidelines and/or a GLEP. This was originally intended to be part of the tree-signing GLEP series, but was in one of the unpublished ones (GLEPxx+3 in the references). ================================================ GLEP: xx Title: Gentoo GPG key policies Version: x Last-Modified: x Author: "Robin H. Johnson" <[email protected]> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 2013/02/18 Post-History: 2013/11/10 Credits: ======== Many developers and external sources helped in this GLEP. Abstract: ========= This GLEP provides a both a minimum requirement and a recommended set of GPG key management policies for the Gentoo Linux distribution. Motivation: =========== ... Specification: ============== Bare minimum requirements: -------------------------- 1. SHA2-series output digest (SHA1 digests internally permitted). "personal-digest-preferences SHA256" 2. root key & signing subkey of EITHER: 2.1. DSA, 2048-bit 2.1.1. Exception: if your hardware token only supports 1024-bit, you may use it 2.2. RSA, >=2048 bits, 2.2.1. RSAv4 or later only: v3 and older are FORBIDDEN. 3. Key expiry: 5 years max. Recommendations: ---------------- 0. Copy /usr/share/gnupg/gpg-conf.skel to ~/.gnupg/gpg.conf, append the block given in step 5 of the FAQ. TODO: The upstream skeleton config file has improved over the years, it would be useful for all users to get updates to it, but etc-update only works for /etc, since this is deployed per-user. Suggestions welcome on getting users to do this. 1. SHA2-series digest on output & certifications: "personal-digest-preferences SHA256" "cert-digest-algo SHA256" 2. Root key type of RSAv4, 4096 bits 2.1. This may require creating an entirely new key. 3. Dedicated signing subkey of EITHER: 3.1. DSA 2048 bits exactly. 3.2. RSA 4096 bits exactly. 4. Key expiry: 4.1. Root key: 3 year max, expiry renewed annually. 4.2. Gentoo subkey: 1 year max, expiry 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. 7. In your gpg.conf: :: # include an unambiguous indicator of which key made a signature: # (and http://www.ietf.org/mail-archive/web/openpgp/current/msg00405.html) # (see http://thread.gmane.org/gmane.mail.notmuch.general/3721/focus=7234) sig-notation [email protected]=%g Notes/FAQ: ---------- 1. "Ok, so how do I follow this?" [#DEBIANGPG]_ [#EKAIA]_ 2. "How can I be really sure/paranoid enough?" [#RISEUP]_. 3. Every 3-6 months, and/or before key expiry and major keysigning events, you should update your key expiry date with the 'expire' command (remember to do all subkeys). Put it on your calendar! 4. If you intend to sign on a very slow alternative-arch, you may find adding a DSA1024 subkey significantly speeds up the signing. TODO: should we codify this exception? 5. Can you give me a full ~/.gnupg/gpg.conf file? :: 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) 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) sig-notation [email protected]=%g # when making an OpenPGP certification, use a stronger digest than the default SHA1: cert-digest-algo SHA256 6. "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. 7. RSA >4096 bits, and DSA >2048 bits are not supported in the OpenPGP specification, and there may be interoperability issues with them. 8. make.conf settings: :: FEATURES="${FEATURES} sign" PORTAGE_GPG_DIR="/home/exampleuser/.gnupg" # You should use the full 16-character key handle to your signing # subkey, with a '!' on the end to ensure that subkey is used. PORTAGE_GPG_KEY="0x1234567890ABCDEF!" 9. You MUST upload your key to the SKS keyserver rotation before usage! TODO: we had considered running an internal keyserver for developers only, is this still in demand, or not needing with a good public keyserver and the gentoo-keys project? Gentoo LDAP: ============ All developers must list the complete GPG fingerprint for their root keys in the "gpgfingerprint" LDAP field. It should be exactly 40 hex digits, uppercase, with optional spaces every 8 hex digits. Regular expression for validation: ^[[:xdigit]]{8}( ?[[:xdigit]]{8}){4}$ 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. Tools: ====== We have most of the key-tracking in progress in the gentoo-keys project [#GENTOOKEYS]_. This toolset should also include easy-to-use tools for developers to generate new keys [#TOOLSET]_ (using the recommendations) and update expiry dates. This tool should generate a final user-formatted keyring, 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 [#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 [#NIST-SP800-57-1]_, [##NIST-SP800-57-2]_ - Debian GPG documentation [#DEBIANGPG]_ - RiseUp.net OpenPGP best practices [#RISEUP]_ References: =========== .. [#GENTOOKEYS] Gentoo Keys project (http://git.overlays.gentoo.org/gitweb/?p=proj/gentoo-keys.git) .. [#TOOLSET] http://thread.gmane.org/gmane.linux.gentoo.devel/83996/focus=84220 .. [#NIST-SP800-57-1] 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) .. [#NIST-SP800-57-2] 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) .. [#EKAIA] Ana's blog: Creating a new GPG key (http://ekaia.org/blog/2009/05/10/creating-new-gpgkey/) .. [#DEBIANGPG] Debian GPG documentation (https://wiki.debian.org/Keysigning) .. [#RISEUP] RiseUp.net OpenPGP best practices (https://we.riseup.net/riseuplabs+paow/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) -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : [email protected] GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
