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

[gentoo-project] 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

[gentoo-project] 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-project] GLEP proposal: Gentoo GPG key policies

[Ulrich Mueller]

>>>>> On Mon, 11 Nov 2013, Robin H Johnson wrote:

> GLEP: xx
> Title: Gentoo GPG key policies

Looks all good to me, except for one point:

> Recommendations:
> ----------------

> 3. Dedicated signing subkey of EITHER:

> 3.1. DSA 2048 bits exactly.

> 3.2. RSA 4096 bits exactly.

Isn't it overkill to use 4096 bits for the signing subkey? I'd expect
that the level of protection of the keys themselves in a typical
developer's environment is far from being a match for this. (Do all
devs use a machine for signing that is isolated from the internet?
Or use a smartcard, at least?)

Also 4096 bits are generally not supported by smartcards. For example,
the OpenPGP card (see http://www.g10code.de/p-card.html) in its newest
version supports RSA up to 3072 bits only.

The following XKCD comic summarises the issue quite well. :-)
http://xkcd.com/538/

Ulrich

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

[Andreas K. Huettel]

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

Am Montag 11 November 2013, 11:22:29 schrieb Ulrich Mueller:
> 
> Looks all good to me, except for one point:
> > Recommendations:
> > ----------------
> > 
> > 3. Dedicated signing subkey of EITHER:
> > 
> > 3.1. DSA 2048 bits exactly.
> > 
> > 3.2. RSA 4096 bits exactly.
> 
> Isn't it overkill to use 4096 bits for the signing subkey? I'd expect
> that the level of protection of the keys themselves in a typical
> developer's environment is far from being a match for this. (Do all
> devs use a machine for signing that is isolated from the internet?
> Or use a smartcard, at least?)
> 
> Also 4096 bits are generally not supported by smartcards. For example,
> the OpenPGP card (see http://www.g10code.de/p-card.html) in its newest
> version supports RSA up to 3072 bits only.

These smartcards as currently delivered are perfectly fine with 4096 bit (even 
though 3072 is printed on the card!). That just isn't advertised since at the 
time of design gnupg (the software) had a hard limit at 3072. The limit is 
lifted since 2.0.20.

However, another question is whether to require a signing *subkey*. The cards 
have (as far as I understand it) only one sign/cert key store, meaning they 
can either hold the main key or the signing subkey, but never both.


http://dilfridge.blogspot.de/2013/05/openpgp-smartcards-and-gentoo-part-2.html

-- 
Andreas K. Huettel
Gentoo Linux developer
kde, council

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

[gentoo-project] 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 --]

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

[Robin H. Johnson]

On Mon, Nov 11, 2013 at 11:22:29AM +0100, Ulrich Mueller wrote:
> > 3.2. RSA 4096 bits exactly.
> Isn't it overkill to use 4096 bits for the signing subkey? I'd expect
> that the level of protection of the keys themselves in a typical
> developer's environment is far from being a match for this. (Do all
> devs use a machine for signing that is isolated from the internet?
> Or use a smartcard, at least?)
In the original thread, I posted timing data on slow & fast systems for
RSA3072 vs RSA4096. Even on a slow system, RSA4096 wasn't that much
slower.

> Also 4096 bits are generally not supported by smartcards. For example,
> the OpenPGP card (see http://www.g10code.de/p-card.html) in its newest
> version supports RSA up to 3072 bits only.
Wrong, many cards support 4096-bit, including this card. The printed
statement on the card was for GnuPG at the time of release, the hardware
DOES support RSA4096 fine. 

I will add one very strong recommendation for any smartcard user: By
design, it's possible to import secret keys ONTO a smartcard, but NOT
export them. Make a backup of your secret keys & revocation certificate
and don't put the ONLY copy of your secret key on a smartcard.

OpenPGP Card / Zeitcontrol:
http://www.g10code.de/p-card.html
http://shop.kernelconcepts.de/product_info.php?products_id=141
This is the Zeitcontrol BasicCard, with an OpenPGP payload. There was an
older v1.0 & v1.1 implementation of the card (non-Zeitcontorol), and
that only supports RSA1024, but those cards are a decade old now.

Crypto-Stick:
https://www.crypto-stick.com/
Integrated smartcard-in-USB form factor, supports RSA4096 in the v2
variant.

OpenPGP-Card:
https://github.com/FluffyKaon/OpenPGP-Card
This is a fully open-source implementation of the OpenPGP SmartCard v2
spec. It has a slight catch in that most JavaCards only support up to
RSA2048. If you load it on a BasicCard, RSA4096 will work.

FST-01:
http://www.seeedstudio.com/wiki/FST-01
Open-hardware version, also RSA2048 max due to hardware, also takes
~1.5s to make a signature.

Usage instructions for any of the above:
https://github.com/OpenSC/OpenSC/wiki/OpenPGP-card
http://wiki.fsfe.org/Card_howtos/Card_with_subkeys_using_backups

Notes:
There are no cards that implement DSA, or ECDSA yet, at least until
RFC6979 is available in hardware:
http://gnupg.10057.n7.nabble.com/New-GPLv3-OpenPGP-card-implementation-on-a-java-card-td32949.html

There was at least one other USB-based card I'd seen in person, but I
can't remember the name or find any references, I think it was at a
prototype state, so probably didn't make it to market.

> The following XKCD comic summarises the issue quite well. :-)
> http://xkcd.com/538/
I referenced this comic already in the thread earlier in this year.
If the well-funded-attacker wants to get into Gentoo, there are many
easier ways to do it, including 

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

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

[Robin H. Johnson]

On Mon, Nov 11, 2013 at 12:38:47PM +0100, Andreas K. Huettel wrote:
> However, another question is whether to require a signing *subkey*. The cards 
> have (as far as I understand it) only one sign/cert key store, meaning they 
> can either hold the main key or the signing subkey, but never both.
> http://dilfridge.blogspot.de/2013/05/openpgp-smartcards-and-gentoo-part-2.html
Nothing in my proposal required a signing subkey. See the min
requirement vs the recommendation. To take the recommendations into a
smartkey environment isn't entirely practical.

I think if that the key in the sign/cert slot, be it a subkey or the
main key, should be valid to use for Gentoo signing.

I see 3 variations of developer:
1. Those with long-standing existing keys, that hopefully meet the min
   requirement. It would be nice to encourage them to migrate over time.
2. New Software keys: New devs, existing devs rekeying
3. New Hardware keys: New devs, existing devs rekeying or migrating

The GLEP has to make all 3 groups happy, hence the breakdown between the
requirement and the recommendation. My own key is more than a decade
old, and has an extensive trust network. I do need to fully rotate it
sometime soon, but I want this GLEP to be finalized first. Sadly I don't
think I'll ever manage to meet all of the same people again to certify
my key.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

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

[Patrick Lauer]

On 11/11/2013 08:01 AM, Robin H. Johnson wrote:
> 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.

That's a pretty good summary, and pretty much what I wanted as guidelines.
Thanks for writing it up, let me just nitpick a few minor points ...

> ================================================
> GLEP: xx
> Title: Gentoo GPG key policies

> 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
Equal, or at least?

> 2.1.1. Exception: if your hardware token only supports 1024-bit, you may use it
Is that a relevant corner case? I'd prefer to not have that around.

> 2.2. RSA, >=2048 bits, 
> 2.2.1. RSAv4 or later only: v3 and older are FORBIDDEN.
> 3. Key expiry: 5 years max.
Minimum?
I'd suggest 6 months from the point in time of adding it

> 4.1. Root key: 3 year max, expiry renewed annually.
You said 5 years just above

> 4.2. Gentoo subkey: 1 year max, expiry renewed every 6 months.
Move that from recommendation to standard? See above.
> 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?
Is this a real problem? (I already have 30sec+ network lag often enough
... )


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

Make that mandatory then.
That might be obsoleted by dolsen's work on key seeds - what's the
current status?


Thanks for accelerating this discussion,

Patrick

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

[Robin H. Johnson]

On Thu, Nov 14, 2013 at 07:52:49PM +0800, Patrick Lauer wrote:
> 
> > ================================================
> > GLEP: xx
> > Title: Gentoo GPG key policies
> 
> > 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
> Equal, or at least?
2.1. DSA, >=2048-bit.

I hadn't seen that 3072-bit DSA was supported yet.

> > 2.1.1. Exception: if your hardware token only supports 1024-bit, you may use it
> Is that a relevant corner case? I'd prefer to not have that around.
I'll reword:
If using a hardware token that does NOT support RSA4096 or DSA2048, you
may degrade only to RSA2048/DSA1024 only.

This is more common than you think, most JavaCards don't have the
hardware to go beyond RSA2048.

Here's another software load for JavaCards, that may be easier than
trying to get an FSFE card or a CryptoStick:
https://github.com/CSSHL/MyPGPid
You just need to get a JavaCard w/ the programming keys.

> > 2.2. RSA, >=2048 bits, 
> > 2.2.1. RSAv4 or later only: v3 and older are FORBIDDEN.
> > 3. Key expiry: 5 years max.
> Minimum?
> I'd suggest 6 months from the point in time of adding it
> 
> > 4.1. Root key: 3 year max, expiry renewed annually.
> You said 5 years just above
> > 4.2. Gentoo subkey: 1 year max, expiry renewed every 6 months.
> Move that from recommendation to standard? See above.
You crossed sections, but let's collapse both to:

Bare minimum requirements:
3. Key expiry: 6 months min, 3 years max.
Recommendations:
4.1. Root key: 6 months min, 3 year max;
4.2. Signing subkey: 3 months min, 1 year max;
4.3. For both keys, expiry date should always be update at least 1 month before expiry.

> > 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?
> Is this a real problem? (I already have 30sec+ network lag often enough
> ... )
Slow arches: this is your time to weigh in. Do you mind signing on a
local machine? Network lag shouldn't matter at all here, you should be
signing locally.

> > 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?
> Make that mandatory then.
9. You must make your key available in at least the following two
places:
9.1. Uploaded to pool.sks-keyservers.net
9.2. An ASCII-armored copy at: dev.g.o:~/public_html/.gpgkey.asc

This is because the keys themselves can be quite large, my key with
signatures is about 500kb. Having it in both locations allows:
- redundancy when the keyserver rotation is offline.
- an extra check that keyserver copy is not modified.
- quicker validation of developer key existence.
- easy of use for LDAP interaction (possible workflow: upload your key
  and have it placed in LDAP by a tool when you run and use your
  password).

Regardless, LDAP will remain the canonical source for key fingerprints,
because to update your LDAP entry, you require both your SSH key, and
your developer password.

> That might be obsoleted by dolsen's work on key seeds - what's the
> current status?
No, the key-seeds code is mostly using LDAP to fetch the dev keys from
keyservers.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

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

[Kristian Fiskerstrand]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 11/15/2013 07:23 AM, Robin H. Johnson wrote:
> On Thu, Nov 14, 2013 at 07:52:49PM +0800, Patrick Lauer wrote:

..

> 9. You must make your key available in at least the following two 
> places: 9.1. Uploaded to pool.sks-keyservers.net 9.2. An
> ASCII-armored copy at: dev.g.o:~/public_html/.gpgkey.asc
> 
> This is because the keys themselves can be quite large, my key
> with signatures is about 500kb. Having it in both locations
> allows: - redundancy when the keyserver rotation is offline. - an
> extra check that keyserver copy is not modified.

I'm not entirely sure I understand the point above. OpenPGP keys are
self-contained in terms of object security, whereby the various
elements are signed by the master Certificate key. Any modification
done on a keyserver would invalidate the signature and invalidate e.g.
a UID or a subkey.

One thing that could be practically done is to remove an entire
element (e.g. a UID or a subkey), but since the keyservers are
add-only by design (in particular to preserve revocation
certificates), this would mean that either a non-trusted keyserver is
used or it has been manipulated in transit.

The latter can be mitigated using the HKPS  protocol[0] as also
suggested in [1]. For the former some level of trust has to be put in
the keyserver operators of a given pool, but since the servers are
reconciliation, and are merge only, any attack like this would need to
simultaneously attack the 80 or so keyservers in the main pool at any
given time (or for HKPS about 20)[2] as the client will select a
random keyserver from a DNS round-robin for each query. An alternative
is of course to run a local keyserver.

I'm new to this list, so excuse me for not following the entire
discussion, I've only browsed through the archives, but maybe a bit
too quickly.

An interesting point with PKI is obviously key validation. How would
this be setup in this environment? A central "Gentoo Developer CA" or
through some form of hierarchy with CA signing project leads that
again validate members' keys?

References:
[0] https://sks-keyservers.net/overview-of-pools.php#pool_hkps
[1]
https://we.riseup.net/riseuplabs+paow/openpgp-best-practices#consider-making-your-default-keyserver-use-a-keyse
[2] https://sks-keyservers.net/status/

- -- 
- ----------------------------
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- ----------------------------
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- ----------------------------
Corruptissima re publica plurimæ leges
The greater the degeneration of the republic, the more of its laws
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJShk/gAAoJEAt/i2Dj7frjGRcP/18FGQ+uraJlP5mszry3c43p
Cdm24lLEaL+bjgjUXZkGImB+220C8fSMnwov+w/Lqqirfth4SVmeFKHdic4mNQzX
kuk5kIFfdviCcGpXwuhmROCKz5Pz2UObQKSqpjUaci0gzDzB/8s0BM7+/EJKUxxc
e3opxezxlyo/FHEVlIAMwxDK+whJhf7ByszztzWecnNWAKlVKKPQQD2EhWXEhXvt
NedPVbneXVC6ViHDxSd1vPddWsR71dMR0t6WTUB7sA9m9s0AAxdsBvRLTMYhkXP7
uZa/L+BrUcAjW7yHjIHTRcY9Rc31HS9yIlMUu3tNQtnG6SfeEvkAYzd7NtZjx0Hx
CEioBldThJg6hXqQttd8llSy9FhznkJju/jpkpRF65UoaCJrRFyme94EjRHRwn2F
+EfWtdwOyn+JXq8RZvnHEC2IipT18TtZLVRrp/Qcv4I51CcG7DSnLg/0levx5nIG
iLP4XzEU2DOxNty6Gd/Q9F2lmyICdhepyvidXyvFteNTYU1TvGEbTYjnchFaDpzQ
lPtpHjDednRQDuU74auHkY7A/Bc2bdlQVOB2fO66FpGpj3UMS+fUNN6bjnnEmx3y
9CVwe662b9f+Sis3utAw+VrsZatQjtqlUEZ1vQgPn2Ye9wnI8m+26Xyroz9qGLkl
U/FXh1uG9zL6mrzWm5zc
=fWaT
-----END PGP SIGNATURE-----

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

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/15/2013 01:23 AM, Robin H. Johnson wrote:
> You crossed sections, but let's collapse both to:
> 
> Bare minimum requirements:
> 3. Key expiry: 6 months min, 3 years max.
> Recommendations:
> 4.1. Root key: 6 months min, 3 year max;
> 4.2. Signing subkey: 3 months min, 1 year max;
> 4.3. For both keys, expiry date should always be update at least 1 month before expiry.

How are we planning on updating keys on user's systems to verify things?
 I only ask because 3 months on the signing key means whatever we do
needs to happen *securely* every 3 months at most.  So like, if we are
pushing an ebuild with a keyring then we have to update it every 2
months so keys don't expire and then that would break if the user
doesn't update every 3 months...  Might be an issue as we try as a whole
to keep systems updatable for 1 year.

- -Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJShm0zAAoJEKXdFCfdEflK0YcP/jBttkSGpJI6huDHz0VDGyB1
B53cUxTn+yZZcqAlcoeLojhox/Fz2Zhw+J2pNXXOTXC8+FrQ3B25elrEqJGRmMbf
uhpuIq2k2PzKOqp6sQHhUTS6bd3vwUnarJO/3jUEzuqT2BsFz0emnkM10CO1G6os
EQSMXRl2MDHSlWSVAPkl6SP0F8HRGp5FuBt0f99bNe3wrcAYTvhCrKvZfxgH/E61
Mx0UUaCZaZGg/n9PdB5D6reRgMkKE33SwcK1ReilSnGT+rxM1zTX7UMlXHxLvqgn
iSpYVq9tad3ZgukilDRjziKGp3h0q91HTwh8FdyrmylU6ryUBkF3uEL2X31pR2Tz
X96MMXfk7BXHCcETTtLvHlsR6OTvvoEqMIk8n3BXpzEoTdvqRFZUe8IlHzii/xMX
UO6EFfOWBIepkuX4jRCC68A38zQW/JheW5anZXvhs90+3P271juVN4atHWOIbtDr
CzErZV3dQN3bwxtp9PAhoifdFf0AuHtT2/KTpLBSydYzkFIYBTemIm0xCD8NbRbj
N8Weu9K/c6fY3KX9HSL7ZP6gd6bAv9CRyf++2hFm9VUq4St+5/tgN9ef9wTlKMg1
XdSUnz70Kq6mPNH9ELrCuGTPNDjwtbRodDPLSiEPI/bftHepiSqVhf518mkJi6Nz
WzwWKSV5QsIICdJOPCUj
=BCjG
-----END PGP SIGNATURE-----

[gentoo-project] GPG Keyring distribution & packages

[Robin H. Johnson]

On Fri, Nov 15, 2013 at 01:51:32PM -0500, Rick "Zero_Chaos" Farina wrote:
> On 11/15/2013 01:23 AM, Robin H. Johnson wrote:
> > You crossed sections, but let's collapse both to:
> > 
> > Bare minimum requirements:
> > 3. Key expiry: 6 months min, 3 years max.
> > Recommendations:
> > 4.1. Root key: 6 months min, 3 year max;
> > 4.2. Signing subkey: 3 months min, 1 year max;
> > 4.3. For both keys, expiry date should always be update at least 1 month before expiry.
> How are we planning on updating keys on user's systems to verify things?
>  I only ask because 3 months on the signing key means whatever we do
> needs to happen *securely* every 3 months at most.  So like, if we are
> pushing an ebuild with a keyring then we have to update it every 2
> months so keys don't expire and then that would break if the user
> doesn't update every 3 months...  Might be an issue as we try as a whole
> to keep systems updatable for 1 year.
So some more details regarding how we plan to deploy keys is probably
needed here. It was out of scope for the discussion about what keys
should look like.

There are a few parts to it:
- gentoo-keys (lead by dolsen)
  This is a mostly infra-level tool that takes the data in LDAP, does
  validation, mixes in the keys from keyserver/homedir, and generates
  keyrings.
- keyring packages:
  Thus far, based on the Debian keyring model, where keyrings of trusted
  keys are installed locally in /usr/share/keyrings/, and the package
  manager (or other tools) looks there for validation. I've got a few
  planned so far:
  $CAT/gentoo-dev-keyring
  $CAT/gentoo-releng-keyring
  $CAT/gentoo-master-keyring
  To ease the 1-year-updatability requirement, these three packages
  should explicitly be signed by the master key (and not a dev key),
  which has a much longer validity. This would always enable you to
  rsync, install the latest gentoo-dev-keyring, and then install other
  packages thereafter.
- layman keyrings:
  dolsen is also working on allowing overlays to specify keyrings in the
  repositories.xml; there's a few unanswered questions about how to
  ensure nobody does MITM attacks on those keyrings (either convince the
  overlays admins to change the URL to the keyring, or simply intercept
  requests for the keyring itself). This maps to how Ubuntu's Launchpad
  handles keys for PPAs.
 
TODO:
We need a way for a given repo, once installed, to specify what keyrings
to use for validation. I'm thinking of adding it to
metadata/layout.conf.
The main gentoo-x86 repo would have for example:
keyrings = gentoo-master gentoo-releng gentoo-dev

Overlays might have:
keyrings = gentoo-overlay-mysql 

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-project] GPG Keyring distribution & packages

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/15/2013 02:37 PM, Robin H. Johnson wrote:
> On Fri, Nov 15, 2013 at 01:51:32PM -0500, Rick "Zero_Chaos" Farina wrote:
>> On 11/15/2013 01:23 AM, Robin H. Johnson wrote:
>>> You crossed sections, but let's collapse both to:
>>>
>>> Bare minimum requirements:
>>> 3. Key expiry: 6 months min, 3 years max.
>>> Recommendations:
>>> 4.1. Root key: 6 months min, 3 year max;
>>> 4.2. Signing subkey: 3 months min, 1 year max;
>>> 4.3. For both keys, expiry date should always be update at least 1 month before expiry.
>> How are we planning on updating keys on user's systems to verify things?
>>  I only ask because 3 months on the signing key means whatever we do
>> needs to happen *securely* every 3 months at most.  So like, if we are
>> pushing an ebuild with a keyring then we have to update it every 2
>> months so keys don't expire and then that would break if the user
>> doesn't update every 3 months...  Might be an issue as we try as a whole
>> to keep systems updatable for 1 year.
> So some more details regarding how we plan to deploy keys is probably
> needed here. It was out of scope for the discussion about what keys
> should look like.
> 
> There are a few parts to it:
> - gentoo-keys (lead by dolsen)
>   This is a mostly infra-level tool that takes the data in LDAP, does
>   validation, mixes in the keys from keyserver/homedir, and generates
>   keyrings.
> - keyring packages:
>   Thus far, based on the Debian keyring model, where keyrings of trusted
>   keys are installed locally in /usr/share/keyrings/, and the package
>   manager (or other tools) looks there for validation. I've got a few
>   planned so far:
>   $CAT/gentoo-dev-keyring
>   $CAT/gentoo-releng-keyring
>   $CAT/gentoo-master-keyring
>   To ease the 1-year-updatability requirement, these three packages
>   should explicitly be signed by the master key (and not a dev key),
>   which has a much longer validity. This would always enable you to
>   rsync, install the latest gentoo-dev-keyring, and then install other
>   packages thereafter.
I think this is a great idea, BUT, we would need to handle "the latest
gentoo-dev-keyring" like portage updates used to be handled.  If there
is an update, warn the user, and if gentoo-dev-keyring is in the update
list it *must* be merged first.  Again, these implementation details
don't necessarily have to be in the glep, but we need to make sure as we
go through that we account for such things.  My day job is pretty much
running man in the middle on things and laughing at the result, so I'm
super excited to see all this hard work going in.

> - layman keyrings:
>   dolsen is also working on allowing overlays to specify keyrings in the
>   repositories.xml; there's a few unanswered questions about how to
>   ensure nobody does MITM attacks on those keyrings (either convince the
>   overlays admins to change the URL to the keyring, or simply intercept
>   requests for the keyring itself). This maps to how Ubuntu's Launchpad
>   handles keys for PPAs.

It is really tough to bootstrap things like this.  honestly I would
suggest that this is good enough and overlay maintainers who really care
can post things on their website to help further manual verification.
Not that we should ignore issues here, but I wouldn't spend dozens of
hours trying to figure out how we secure overlays full of non-gentoo
official content.  For the official ones we can sign their key with the
master key and that should take care of any trust issues.
>  
> TODO:
> We need a way for a given repo, once installed, to specify what keyrings
> to use for validation. I'm thinking of adding it to
> metadata/layout.conf.
> The main gentoo-x86 repo would have for example:
> keyrings = gentoo-master gentoo-releng gentoo-dev
> 
> Overlays might have:
> keyrings = gentoo-overlay-mysql 
> 
Love it.  This should probably make it into the glep.

Thanks,
Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJShpFdAAoJEKXdFCfdEflKtpQQALDKZfiVfSbRZJEg/fTEvpUo
CpMl+h4zxNxZQV3sE5GTZyhFfTGQ+2B+leS4pxDFgKVSmu+bu6rzYGgU5+BdrvKt
Vg6DrKe56HkmKu6kB28VuXVZ+euXPF0fyjcO/fr3ij1KvEdEz3ALea+GZ1dbEgr4
hD0XV6mKCQZ6qAnaSETpaQERgcXcw/6tgYGAhY4yy5Q+0ECEB6/fe3kWDeDuw0iK
FyLkiawh6GilTmm8h2e5isFipGL+Wqwnqa0xeuJbD/2FlfZjnA3RzsE0vY5Snw4r
9a3UoDHUtGcmNUn5S62iPJRPAzNu1EoYBwAVIMIX5qHmnTSZ+G04lHLeLLLDmr8b
L/W470IP/MhqcKcrXHJlcHvOMDvEz5jxnbPdEcv6dB3FCzaIN6gC80B0sUKco+lU
00Eq3qjneo58zQi01lMsu5LFx0lfL55w/Bb6uRb38RtUcxLgzrTTyLawzqM0KJNw
ZxUX3KcTYHvIBj4ZLEffOmvEBNcIC4R9sDV8aD2ENPQvZt3IH3izCgSKKz7TiiaW
4xmQJtgT8zGSLbuBfSap9wK2+JVSKro97plBxBUe4Ay1hVlYYINRYWusQqciIf3N
KehGd7oAQa6f4QjsxrqknvAEPW9JpAFQRhphkzv+z942kCg4abDUVu8ltuseHDeX
WiUnfhquOGimc8QeXXJx
=UxX6
-----END PGP SIGNATURE-----

Re: [gentoo-project] GPG Keyring distribution & packages

[Brian Dolbec]

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

On Fri, 2013-11-15 at 16:25 -0500, Rick "Zero_Chaos" Farina wrote:
> On 11/15/2013 02:37 PM, Robin H. Johnson wrote:
> > On Fri, Nov 15, 2013 at 01:51:32PM -0500, Rick "Zero_Chaos" Farina wrote:
> >> On 11/15/2013 01:23 AM, Robin H. Johnson wrote:
> >>> You crossed sections, but let's collapse both to:
> >>>
> >>> Bare minimum requirements:
> >>> 3. Key expiry: 6 months min, 3 years max.
> >>> Recommendations:
> >>> 4.1. Root key: 6 months min, 3 year max;
> >>> 4.2. Signing subkey: 3 months min, 1 year max;
> >>> 4.3. For both keys, expiry date should always be update at least 1 month before expiry.
> >> How are we planning on updating keys on user's systems to verify things?
> >>  I only ask because 3 months on the signing key means whatever we do
> >> needs to happen *securely* every 3 months at most.  So like, if we are
> >> pushing an ebuild with a keyring then we have to update it every 2
> >> months so keys don't expire and then that would break if the user
> >> doesn't update every 3 months...  Might be an issue as we try as a whole
> >> to keep systems updatable for 1 year.
> > So some more details regarding how we plan to deploy keys is probably
> > needed here. It was out of scope for the discussion about what keys
> > should look like.
> > 
> > There are a few parts to it:
> > - gentoo-keys (lead by dolsen)
> >   This is a mostly infra-level tool that takes the data in LDAP, does
> >   validation, mixes in the keys from keyserver/homedir, and generates
> >   keyrings.

Not quite right.  The gentoo-keys project is a repository with two main
components.

1) gkeyldap cli and python pkg.  This is all the code that needs to run
on infra machines to get the data from ldap and generate the dev seed
file.  It will likely never be installed on a user system (but some noob
will likely try).  It could be adapted to run on other derivative
distro's with some additional code wrapping or patches.  Or they could
just create their own script to generate the seed files.  Please note
that seed files can be manually generated and maintained using the gkey
app in 2 below.

2) gkey cli and python pkg.

 a) This is the code and library that will be installed on users and
infra systems to manage and install the keys to the appropriate keyring
or keyrings.  It will have code for doing regular maintenance and upkeep
of the keyrings.  As I see it so far, there will be no need for it to
require binary keyrings or ebuilds with version bumps to perform
updates.  It will be able to download updated seed files just like
layman does with the repositories.xml file.  keyring updates can be done
automatically with a cron job, emerge --sync hook or even make use of
it's python API to run the maintenance actions from within the package
manager (see b)

  b)  A python library of predefined functions and methods to perform
the regular verification and maintenance operations.  They will be
available from both the cli interface supplied or through use of it's
python API.

  c) a cli interface for performing all the operations it is capable of.

  d) It leaves open the possibility of getting a gui interface that
users can use for maintenance.  Hey, I wouldn't code it any other way
than to be able to switch out the interface without having to recode the
operational routines.


Ebuild installed seed files could be done as well for overlay use or
other repositories of pkgs whether layman maintained or not.  They would
be subject to regular tree rules.  All that is needed is to install the
keyring's seed file to the gkey seedfile directory and call the gkey cli
with the correct parameters for it to install the keys it specifies.
Something easily done the the pkg_post_intall().

> > - keyring packages:
> >   Thus far, based on the Debian keyring model, where keyrings of trusted
> >   keys are installed locally in /usr/share/keyrings/, and the package
> >   manager (or other tools) looks there for validation. I've got a few
> >   planned so far:
> >   $CAT/gentoo-dev-keyring
> >   $CAT/gentoo-releng-keyring

Yes, the code is set up for those 2 primary seed files and keyrings.
They are not also needed to be installed via ebuild.  The url's will be
included in the pkg,  They will be downloaded and installed the same as
layman's repositories.xml file.  It will save having it be version
bumped up to several times a day in the case of the dev's seed file.
I have yet to add the code in gkeyldap to check if the new seed file has
indeed changed or not before changing the existing seed file.  The gkey
sync operation will send the "if-Modified-since" header like I did for
layman-2.0, so only an updated seed file will trigger an update to the
keys the seed file is responsible for and installed on the user's
system.

The dev keyrings are set up to be one keyring per dev. all under one
umbrella dev-keyring directory.  This was the setup requested by Brian
Harring, to be used for the git commit verification hooks.  It also
provides some cross contamination protection.


> >   $CAT/gentoo-master-keyring
Interesting...  Good idea :)

I have also started setting up a known_seeds variable to be used
similarly to layman's repositories.xml.  It could be for keys known to
us for non-dev commits to official overlays and such.  But have not put
much thought into it.  At any rate the code will be there to handle it
regardless if it comes into being or not.  

> >   To ease the 1-year-updatability requirement, these three packages
> >   should explicitly be signed by the master key (and not a dev key),
> >   which has a much longer validity. This would always enable you to
> >   rsync, install the latest gentoo-dev-keyring, and then install other
> >   packages thereafter.
> I think this is a great idea, BUT, we would need to handle "the latest
> gentoo-dev-keyring" like portage updates used to be handled.  If there
> is an update, warn the user, and if gentoo-dev-keyring is in the update
> list it *must* be merged first.  Again, these implementation details
> don't necessarily have to be in the glep, but we need to make sure as we
> go through that we account for such things.  My day job is pretty much
> running man in the middle on things and laughing at the result, so I'm
> super excited to see all this hard work going in.
> 
> > - layman keyrings:
> >   dolsen is also working on allowing overlays to specify keyrings in the
> >   repositories.xml; there's a few unanswered questions about how to
> >   ensure nobody does MITM attacks on those keyrings (either convince the
> >   overlays admins to change the URL to the keyring, or simply intercept
> >   requests for the keyring itself). This maps to how Ubuntu's Launchpad
> >   handles keys for PPAs.
> 
> It is really tough to bootstrap things like this.  honestly I would
> suggest that this is good enough and overlay maintainers who really care
> can post things on their website to help further manual verification.
> Not that we should ignore issues here, but I wouldn't spend dozens of
> hours trying to figure out how we secure overlays full of non-gentoo
> official content.  For the official ones we can sign their key with the
> master key and that should take care of any trust issues.

The fingerprint for the overlay's signed seed file could be added to
repositories.xml which is controlled by gentoo devs and signed by the
master key.  That should take care of our end of it.  Of course the user
must take responsibility for installing and using the overlay ebuilds in
the first place, so we can not offer any guarantees as to the validity
of the overlay and the keys it offers unless it is an official overlay.
For that use case any non-dev's must supply an equivalent of a dev's gpg
signing key, following the same rules as dev's for it.  It is those keys
which we may have to create a central repo for, since they will not have
a dev.g.o account to store them in (if that is the route taken).

> >  
> > TODO:
> > We need a way for a given repo, once installed, to specify what keyrings
> > to use for validation. I'm thinking of adding it to
> > metadata/layout.conf.
> > The main gentoo-x86 repo would have for example:
> > keyrings = gentoo-master gentoo-releng gentoo-dev
> > 
> > Overlays might have:
> > keyrings = gentoo-overlay-mysql 
> > 
> Love it.  This should probably make it into the glep.
> 
> Thanks,
> Zero


Sounds good to me.

P.S.  OH my, this turned out to be along reply :/
But I hope it clears up any questions people may have about it.
It is a work in progress...
-- 
Brian Dolbec <dolsen@gentoo.org>

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

Re: [gentoo-project] GPG Keyring distribution & packages

["Paweł Hajdan, Jr."]

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

Just checking: Brian (dol-sen), Rick (Zero_Chaos), Robin (robbat2) - are
all the issues resolved here?

Please see some quotes below for what might appear to indicate some
further changes to the GLEP. The key distribution part doesn't seem to
be fully ready, but feel free to correct me.

Thank you for working on this, I think better security there is
important for Gentoo.

By the way, one more suggestion that came up is splitting the GLEP into two:

1) individual developer key and gpg guidelines (looks like this could be
approved now)

2) distro-wide key/keyring distribution mechanism/policy (looks like it
may need more work)

Paweł

On 11/16/13, 12:43 AM, Brian Dolbec wrote:
> On Fri, 2013-11-15 at 16:25 -0500, Rick "Zero_Chaos" Farina wrote:
>> On 11/15/2013 02:37 PM, Robin H. Johnson wrote:
>>> On Fri, Nov 15, 2013 at 01:51:32PM -0500, Rick "Zero_Chaos" Farina wrote:
>>>> On 11/15/2013 01:23 AM, Robin H. Johnson wrote:
>>> There are a few parts to it:
>>> - gentoo-keys (lead by dolsen)
>>>   This is a mostly infra-level tool that takes the data in LDAP, does
>>>   validation, mixes in the keys from keyserver/homedir, and generates
>>>   keyrings.
> 
> Not quite right.  The gentoo-keys project is a repository with two main
> components.
> 
> 1) gkeyldap cli and python pkg.  [...]
> 
> 2) gkey cli and python pkg. [...]
>  [...]
>> I think this is a great idea, BUT, we would need to handle "the latest
>> gentoo-dev-keyring" like portage updates used to be handled.  If there
>> is an update, warn the user, and if gentoo-dev-keyring is in the update
>> list it *must* be merged first.  Again, these implementation details
>> don't necessarily have to be in the glep, but we need to make sure as we
>> go through that we account for such things.  My day job is pretty much
>> running man in the middle on things and laughing at the result, so I'm
>> super excited to see all this hard work going in.
>> [...]
>>> TODO:
>>> We need a way for a given repo, once installed, to specify what keyrings
>>> to use for validation. I'm thinking of adding it to
>>> metadata/layout.conf.
>>> The main gentoo-x86 repo would have for example:
>>> keyrings = gentoo-master gentoo-releng gentoo-dev
>>>
>>> Overlays might have:
>>> keyrings = gentoo-overlay-mysql 
>>>
>> Love it.  This should probably make it into the glep.
>>
> Sounds good to me.
> 
> P.S.  OH my, this turned out to be along reply :/
> But I hope it clears up any questions people may have about it.
> It is a work in progress...



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [gentoo-project] GPG Keyring distribution & packages

[Michael Orlitzky]

On 12/10/2013 02:50 PM, "Paweł Hajdan, Jr." wrote:
> Just checking: Brian (dol-sen), Rick (Zero_Chaos), Robin (robbat2) - are
> all the issues resolved here?
> 

I ran through this the other day, and there was a small issue I noticed.

> 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!"

The latter two, not being global, probably belong in ~/.bashrc or
wherever ECHANGELOG_USER is set.

Re: [gentoo-project] GPG Keyring distribution & packages

[Brian Dolbec]

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

On Tue, 2013-12-10 at 15:11 -0500, Michael Orlitzky wrote:
> On 12/10/2013 02:50 PM, "Paweł Hajdan, Jr." wrote:
> > Just checking: Brian (dol-sen), Rick (Zero_Chaos), Robin (robbat2) - are
> > all the issues resolved here?
> > 
> 
> I ran through this the other day, and there was a small issue I noticed.
> 
> > 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!"
> 
> The latter two, not being global, probably belong in ~/.bashrc or
> wherever ECHANGELOG_USER is set.
> 
> 

I know that Zac has preferred that portage do everything on it's own.
that way there would be no additional dependencies.  But I would like to
migrate portage to using gentoo-keys gkey lib which will manage that for
gentoo.  That way there will be a single point for changes to be made
and keep up to date.

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