[gentoo-dev] GLEP proposal: Gentoo GPG key policies

[gentoo-dev] GLEP proposal: Gentoo GPG key policies

[Robin H. Johnson]

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" <robbat2@gentoo.org>
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 issuer-fpr@notations.openpgp.fifthhorseman.net=%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 issuer-fpr@notations.openpgp.fifthhorseman.net=%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     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] GLEP proposal: Gentoo GPG key policies

[Brian Dolbec]

[-- Attachment #1: Type: text/plain, Size: 4808 bytes --]

On Mon, 2013-11-11 at 00:01 +0000, Robin H. Johnson wrote:
> 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 problem I can see happening allowing the optional spaces is that
currently the fingerpint field is a space separated list of
fingerprints.  In the ldap-seeds code used to generate the
developer.seeds file.  I am splitting that field data on the spaces to
get a python list of individual fingerprints.  There are developers that
have 2 fingerprints listed.  If spaces are to be allowed in the
fingerprint then we will need to use and enforce a different separator
to divide the fingerprints.  Currently in gentoo-keys I use the ":" as a
separator in the gpgkey and fingerprint fields of the seed file.  A "|"
is used to separate the fields of the seed info.


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

++

Currently running some checks on the gpgkey and fingerprint fields,
there are many developers with errors.  Some have 2 gpgkeys listed, but
only 1 fingerprint, some the gpgkey does not match the fingerprint.  One
dev's fingerprint is only 39 chars in length.  Please check if yours has
errors and correct them please.  See below for the links.

By eliminating the gpgkey field in ldap it will reduce the chance for
errors and is redundant data anyway.  I will later establish a policy &
code to test the developer.seeds file to look for errors in installing
the keys before it is pushed to the server for public download.  I
already have code to install the complete set of developer seeds, but
need to add/tweak the code to log the errors correctly.

For the current file of the valid developer seeds:

   http://dev.gentoo.org/~dolsen/developer.seeds

   record entries are 1 dev per line.
   fields are ['nick', 'name', 'keyid', 'longkeyid','keydir', 'fingerprint']

For the latest log of the seed file generation run which lists the
errors found:

    http://dev.gentoo.org/~dolsen/gkeyldap-latest.log


P.S. If any python coders are interested in helping, please contact
me :)

> 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)
> 

-- 
Brian Dolbec <dolsen@gentoo.org>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 620 bytes --]

Re: [gentoo-dev] GLEP proposal: Gentoo GPG key policies

[Brian Dolbec]

[-- Attachment #1: Type: text/plain, Size: 1388 bytes --]

On Sun, 2013-11-10 at 17:45 -0800, Brian Dolbec wrote:
> On Mon, 2013-11-11 at 00:01 +0000, Robin H. Johnson wrote:
> > 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 problem I can see happening allowing the optional spaces is that
> currently the fingerpint field is a space separated list of
> fingerprints.  In the ldap-seeds code used to generate the
> developer.seeds file.  I am splitting that field data on the spaces to
> get a python list of individual fingerprints.  There are developers that
> have 2 fingerprints listed.  If spaces are to be allowed in the
> fingerprint then we will need to use and enforce a different separator
> to divide the fingerprints.  Currently in gentoo-keys I use the ":" as a
> separator in the gpgkey and fingerprint fields of the seed file.  A "|"
> is used to separate the fields of the seed info.
> 

Forget I said the above.  I should have re-read my code first.  Multiple
fingerprints are already returned as a list from python ldap.  I already
had code in place to condense spaces in the fingerprint before the
checks.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 620 bytes --]