Re: [gentoo-dev] [PATCH v3 00/12] GLEP 63 update

2018-07-06 Thread Michał Górny
W dniu pią, 06.07.2018 o godzinie 21∶26 -0400, użytkownik Richard Yao
napisał:
> > On Jul 5, 2018, at 4:53 PM, Michał Górny  wrote:
> > 
> > Hi,
> > 
> > Here's third version of the patches.  I've incorporated the feedback
> > so far and reordered the patches (again) to restore their
> > degree-of-compatibility order.  The full text is included below.
> > 
> > 
> > Michał Górny (12):
> >  glep-0063: Use 'OpenPGP' as appropriate
> >  glep-0063: RSAv4 -> OpenPGP v4 key format
> >  glep-0063: 'Gentoo subkey' → 'Signing subkey'
> >  glep-0063: Root key → primary key
> >  glep-0063: Split out the signing subkey into a separation point
> >  glep-0063: Explain minimal & recommended sections
> >  glep-0063: Change the recommended RSA key size to 2048 bits
> >  glep-0063: Allow ECC curve 25519 keys
> >  glep-0063: Stop recommending DSA subkeys
> >  glep-0063: Make 2-yearly expiration term mandatory
> >  glep-0063: Require renewal 2 weeks before expiration
> >  glep-0063: Disallow using DSA keys
> > 
> > glep-0063.rst | 97 +--
> > 1 file changed, 64 insertions(+), 33 deletions(-)
> > 
> > 
> > ---
> > GLEP: 63
> > Title: Gentoo OpenPGP policies
> > Author: Robin H. Johnson ,
> >Andreas K. Hüttel ,
> >Marissa Fischer 
> > Type: Standards Track
> > Status: Final
> > Version: 2
> > Created: 2013-02-18
> > Last-Modified: 2018-07-05
> > Post-History: 2013-11-10
> > Content-Type: text/x-rst
> > ---
> > 
> > Credits
> > ===
> > 
> > Many developers and external sources helped in this GLEP.
> > 
> > Abstract
> > 
> > 
> > This GLEP provides both a minimum requirement and a recommended set of
> > OpenPGP key management policies for the Gentoo Linux distribution.
> > 
> > Changes
> > ===
> > 
> > v2
> >  The distinct minimal and recommended expirations have been replaced
> >  by a single requirement. The rules have been simplified to use
> >  the same time of 2 years for both the primary key and subkeys.
> > 
> >  An additional rule requesting key renewal 2 weeks before expiration
> >  has been added. This is in order to give services and other developers time
> >  to refresh the key.
> > 
> >  The usage of DSA keys has been disallowed.
> > 
> > v1.1
> >  The recommended RSA key size has been changed from 4096 bits
> >  to 2048 bits to match the GnuPG recommendations [#GNUPG-FAQ-11-4]_.
> >  The larger recommendation was unjustified and resulted in people
> >  unnecessarily replacing their RSA-2048 keys.
> > 
> >  Minimal specification has been amended to allow for ECC keys.
> > 
> >  The option of using DSA subkey has been removed from recommendations.
> >  The section now specifies a single recommendation of using RSA.
> > 
> > Motivation
> > ==
> > 
> > Given the increasing use and importance of cryptographic protocols in 
> > internet
> > transactions of any kind, unified requirements for OpenPGP 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 (or other OpenPGP providers) 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 OpenPGP keys
> > ===
> > 
> > Bare minimum requirements
> > -
> > This section specifies obligatory requirements for all OpenPGP keys used
> > to commit to Gentoo. Keys that do not conform to those requirements can
> > not be used to commit.
> > 
> > 1. SHA2-series output digest (SHA1 digests internally permitted),
> >   256bit or more::
> > 
> >   personal-digest-preferences SHA256
> > 
> > 2. Signing subkey that is different from the primary key, and does not
> >   have any other capabilities enabled.
> > 
> > 3. Primary key and the signing subkey are both of type EITHER:
> > 
> >   a. RSA, >=2048 bits (OpenPGP v4 key format or later only)
> > 
> >   b. ECC curve 25519
> > 
> > 4. Expiration date on key and all subkeys set to at most 2 years
> > 
> > 5. Key expiration date renewed at least 2 weeks before the previous
> >   expiration date.
> > 
> > 6. Upload your key to the SKS keyserver rotation before usage!
> > 
> > Recommendations
> > ---
> > This section specifies the best practices for Gentoo developers.
> > The developers should follow those practices unless there is a strong
> > technical reason not to (e.g. hardware limitations, necessity of replacing
> > their primary key).
> > 
> > 1. Copy ``/usr/share/gnupg/gpg-conf.skel`` to ``~/.gnupg/gpg.conf``, append
> >   the following block::
> 
> That file no longer exists.
> > 
> >   keyserver pool.sks-keyservers.net
> 
> This is less secure than the default according to K_F in #gentoo-infra.
> > 
> >   emit-version
> 
> K_F indicated that this harms security too.
> > 
> >   

Re: [gentoo-dev] [PATCH v3 00/12] GLEP 63 update

2018-07-06 Thread Richard Yao



> On Jul 5, 2018, at 4:53 PM, Michał Górny  wrote:
> 
> Hi,
> 
> Here's third version of the patches.  I've incorporated the feedback
> so far and reordered the patches (again) to restore their
> degree-of-compatibility order.  The full text is included below.
> 
> 
> Michał Górny (12):
>  glep-0063: Use 'OpenPGP' as appropriate
>  glep-0063: RSAv4 -> OpenPGP v4 key format
>  glep-0063: 'Gentoo subkey' → 'Signing subkey'
>  glep-0063: Root key → primary key
>  glep-0063: Split out the signing subkey into a separation point
>  glep-0063: Explain minimal & recommended sections
>  glep-0063: Change the recommended RSA key size to 2048 bits
>  glep-0063: Allow ECC curve 25519 keys
>  glep-0063: Stop recommending DSA subkeys
>  glep-0063: Make 2-yearly expiration term mandatory
>  glep-0063: Require renewal 2 weeks before expiration
>  glep-0063: Disallow using DSA keys
> 
> glep-0063.rst | 97 +--
> 1 file changed, 64 insertions(+), 33 deletions(-)
> 
> 
> ---
> GLEP: 63
> Title: Gentoo OpenPGP policies
> Author: Robin H. Johnson ,
>Andreas K. Hüttel ,
>Marissa Fischer 
> Type: Standards Track
> Status: Final
> Version: 2
> Created: 2013-02-18
> Last-Modified: 2018-07-05
> Post-History: 2013-11-10
> Content-Type: text/x-rst
> ---
> 
> Credits
> ===
> 
> Many developers and external sources helped in this GLEP.
> 
> Abstract
> 
> 
> This GLEP provides both a minimum requirement and a recommended set of
> OpenPGP key management policies for the Gentoo Linux distribution.
> 
> Changes
> ===
> 
> v2
>  The distinct minimal and recommended expirations have been replaced
>  by a single requirement. The rules have been simplified to use
>  the same time of 2 years for both the primary key and subkeys.
> 
>  An additional rule requesting key renewal 2 weeks before expiration
>  has been added. This is in order to give services and other developers time
>  to refresh the key.
> 
>  The usage of DSA keys has been disallowed.
> 
> v1.1
>  The recommended RSA key size has been changed from 4096 bits
>  to 2048 bits to match the GnuPG recommendations [#GNUPG-FAQ-11-4]_.
>  The larger recommendation was unjustified and resulted in people
>  unnecessarily replacing their RSA-2048 keys.
> 
>  Minimal specification has been amended to allow for ECC keys.
> 
>  The option of using DSA subkey has been removed from recommendations.
>  The section now specifies a single recommendation of using RSA.
> 
> Motivation
> ==
> 
> Given the increasing use and importance of cryptographic protocols in internet
> transactions of any kind, unified requirements for OpenPGP 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 (or other OpenPGP providers) 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 OpenPGP keys
> ===
> 
> Bare minimum requirements
> -
> This section specifies obligatory requirements for all OpenPGP keys used
> to commit to Gentoo. Keys that do not conform to those requirements can
> not be used to commit.
> 
> 1. SHA2-series output digest (SHA1 digests internally permitted),
>   256bit or more::
> 
>   personal-digest-preferences SHA256
> 
> 2. Signing subkey that is different from the primary key, and does not
>   have any other capabilities enabled.
> 
> 3. Primary key and the signing subkey are both of type EITHER:
> 
>   a. RSA, >=2048 bits (OpenPGP v4 key format or later only)
> 
>   b. ECC curve 25519
> 
> 4. Expiration date on key and all subkeys set to at most 2 years
> 
> 5. Key expiration date renewed at least 2 weeks before the previous
>   expiration date.
> 
> 6. Upload your key to the SKS keyserver rotation before usage!
> 
> Recommendations
> ---
> This section specifies the best practices for Gentoo developers.
> The developers should follow those practices unless there is a strong
> technical reason not to (e.g. hardware limitations, necessity of replacing
> their primary key).
> 
> 1. Copy ``/usr/share/gnupg/gpg-conf.skel`` to ``~/.gnupg/gpg.conf``, append
>   the following block::
That file no longer exists.
> 
>   keyserver pool.sks-keyservers.net
This is less secure than the default according to K_F in #gentoo-infra.
> 
>   emit-version
K_F indicated that this harms security too.
> 
>   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 

[gentoo-dev] [PATCH v3 00/12] GLEP 63 update

2018-07-05 Thread Michał Górny
Hi,

Here's third version of the patches.  I've incorporated the feedback
so far and reordered the patches (again) to restore their
degree-of-compatibility order.  The full text is included below.


Michał Górny (12):
  glep-0063: Use 'OpenPGP' as appropriate
  glep-0063: RSAv4 -> OpenPGP v4 key format
  glep-0063: 'Gentoo subkey' → 'Signing subkey'
  glep-0063: Root key → primary key
  glep-0063: Split out the signing subkey into a separation point
  glep-0063: Explain minimal & recommended sections
  glep-0063: Change the recommended RSA key size to 2048 bits
  glep-0063: Allow ECC curve 25519 keys
  glep-0063: Stop recommending DSA subkeys
  glep-0063: Make 2-yearly expiration term mandatory
  glep-0063: Require renewal 2 weeks before expiration
  glep-0063: Disallow using DSA keys

 glep-0063.rst | 97 +--
 1 file changed, 64 insertions(+), 33 deletions(-)


---
GLEP: 63
Title: Gentoo OpenPGP policies
Author: Robin H. Johnson ,
Andreas K. Hüttel ,
Marissa Fischer 
Type: Standards Track
Status: Final
Version: 2
Created: 2013-02-18
Last-Modified: 2018-07-05
Post-History: 2013-11-10
Content-Type: text/x-rst
---

Credits
===

Many developers and external sources helped in this GLEP.

Abstract


This GLEP provides both a minimum requirement and a recommended set of
OpenPGP key management policies for the Gentoo Linux distribution.

Changes
===

v2
  The distinct minimal and recommended expirations have been replaced
  by a single requirement. The rules have been simplified to use
  the same time of 2 years for both the primary key and subkeys.

  An additional rule requesting key renewal 2 weeks before expiration
  has been added. This is in order to give services and other developers time
  to refresh the key.

  The usage of DSA keys has been disallowed.

v1.1
  The recommended RSA key size has been changed from 4096 bits
  to 2048 bits to match the GnuPG recommendations [#GNUPG-FAQ-11-4]_.
  The larger recommendation was unjustified and resulted in people
  unnecessarily replacing their RSA-2048 keys.

  Minimal specification has been amended to allow for ECC keys.

  The option of using DSA subkey has been removed from recommendations.
  The section now specifies a single recommendation of using RSA.

Motivation
==

Given the increasing use and importance of cryptographic protocols in internet
transactions of any kind, unified requirements for OpenPGP 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 (or other OpenPGP providers) 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 OpenPGP keys
===

Bare minimum requirements
-
This section specifies obligatory requirements for all OpenPGP keys used
to commit to Gentoo. Keys that do not conform to those requirements can
not be used to commit.

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

   personal-digest-preferences SHA256

2. Signing subkey that is different from the primary key, and does not
   have any other capabilities enabled.

3. Primary key and the signing subkey are both of type EITHER:

   a. RSA, >=2048 bits (OpenPGP v4 key format or later only)

   b. ECC curve 25519

4. Expiration date on key and all subkeys set to at most 2 years

5. Key expiration date renewed at least 2 weeks before the previous
   expiration date.

6. Upload your key to the SKS keyserver rotation before usage!

Recommendations
---
This section specifies the best practices for Gentoo developers.
The developers should follow those practices unless there is a strong
technical reason not to (e.g. hardware limitations, necessity of replacing
their primary key).

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