Re: [gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update; full text

2018-07-05 Thread Michał Górny
W dniu śro, 04.07.2018 o godzinie 23∶43 +0200, użytkownik Kristian
Fiskerstrand napisał:
> On 07/04/2018 11:28 PM, Michał Górny wrote:
> > W dniu śro, 04.07.2018 o godzinie 23∶12 +0200, użytkownik Ulrich Mueller
> > napisał:
> > > > > > > > On Wed, 04 Jul 2018, Michał Górny wrote:
> > > > 
> > > >b. Signing subkey: 1 year maximum
> > > > 5. Key expiration date renewed at least 2 weeks before the previous
> > > >expiration date.
> > > 
> > > This is crappy as a scheme, since it will make it impossible to keep
> > > the expiration date at a constant month and date.
> > > 
> > 
> > Nobody forces you to prolong it for exactly the same amount, exactly two
> > weeks before expiration.  The only point made here is to give services
> > time to sync rather than the common combo of renewing key once it
> > already expired.
> > 
> > Especially, if you follow the recommended scheme below you can easily
> > get periodic expiration dates.
> > 
> 
> As I understand ulm's concern, the issue is with the max 1 year in
> combination with this, e.g it effectively prohibits extended a subkey
> expiring 2018-12-31 to 2019-12-31 two weeks before, since that exceeds
> one year maximum
> 

We could say 'N year(s) + 2 weeks' but it would be kinda silly.  Given
that people are unhappy about one year anyway, let's defer this one for
now.

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update; full text

2018-07-04 Thread Kristian Fiskerstrand
On 07/04/2018 11:43 PM, Kristian Fiskerstrand wrote:
> On 07/04/2018 11:28 PM, Michał Górny wrote:
>> W dniu śro, 04.07.2018 o godzinie 23∶12 +0200, użytkownik Ulrich Mueller
>> napisał:
 On Wed, 04 Jul 2018, Michał Górny wrote:
b. Signing subkey: 1 year maximum
 5. Key expiration date renewed at least 2 weeks before the previous
expiration date.
>>>
>>> This is crappy as a scheme, since it will make it impossible to keep
>>> the expiration date at a constant month and date.
>>>
>>
>> Nobody forces you to prolong it for exactly the same amount, exactly two
>> weeks before expiration.  The only point made here is to give services
>> time to sync rather than the common combo of renewing key once it
>> already expired.
>>
>> Especially, if you follow the recommended scheme below you can easily
>> get periodic expiration dates.
>>
> 
> As I understand ulm's concern, the issue is with the max 1 year in
> combination with this, e.g it effectively prohibits extended a subkey
> expiring 2018-12-31 to 2019-12-31 two weeks before, since that exceeds
> one year maximum
> 

fwiw, this can be mitigated by allowing e.g 1.25 years / 15 months
instead of one year.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update; full text

2018-07-04 Thread Ulrich Mueller
> On Wed, 4 Jul 2018, Robin H Johnson wrote:

>> >b. Signing subkey: 1 year maximum
>> 
>> > 5. Key expiration date renewed at least 2 weeks before the
>> >previous expiration date.

> Only catch is that if I was doing it 2 weeks before, I'd want to
> push it out another year or 6 months (depending on what), so it
> would briefly be valid for 54 weeks.

Exactly, and that would be forbidden by the new policy.

Also I don't see why a shorter expiry of the subkey should be
mandatory. Has the current policy (which permits same expiry of main
key and subkey) caused any issues in the past?

Ulrich


pgpJfluJIM0_V.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update; full text

2018-07-04 Thread Kristian Fiskerstrand
On 07/04/2018 11:28 PM, Michał Górny wrote:
> W dniu śro, 04.07.2018 o godzinie 23∶12 +0200, użytkownik Ulrich Mueller
> napisał:
>>> On Wed, 04 Jul 2018, Michał Górny wrote:
>>>b. Signing subkey: 1 year maximum
>>> 5. Key expiration date renewed at least 2 weeks before the previous
>>>expiration date.
>>
>> This is crappy as a scheme, since it will make it impossible to keep
>> the expiration date at a constant month and date.
>>
> 
> Nobody forces you to prolong it for exactly the same amount, exactly two
> weeks before expiration.  The only point made here is to give services
> time to sync rather than the common combo of renewing key once it
> already expired.
> 
> Especially, if you follow the recommended scheme below you can easily
> get periodic expiration dates.
> 

As I understand ulm's concern, the issue is with the max 1 year in
combination with this, e.g it effectively prohibits extended a subkey
expiring 2018-12-31 to 2019-12-31 two weeks before, since that exceeds
one year maximum

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update; full text

2018-07-04 Thread Robin H. Johnson
On Wed, Jul 04, 2018 at 11:12:31PM +0200, Ulrich Mueller wrote:
> > On Wed, 04 Jul 2018, Michał Górny wrote:
> 
> >b. Signing subkey: 1 year maximum
> 
> > 5. Key expiration date renewed at least 2 weeks before the previous
> >expiration date.
> This is crappy as a scheme, since it will make it impossible to keep
> the expiration date at a constant month and date.
Why will it make things difficult?

In the expire prompt, you CAN specify an exact expire date or timestamp.

Only catch is that if I was doing it 2 weeks before, I'd want to push it
out another year or 6 months (depending on what), so it would briefly be
valid for 54 weeks.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136


signature.asc
Description: Digital signature


Re: [gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update; full text

2018-07-04 Thread Michał Górny
W dniu śro, 04.07.2018 o godzinie 23∶12 +0200, użytkownik Ulrich Mueller
napisał:
> > > > > > On Wed, 04 Jul 2018, Michał Górny wrote:
> >b. Signing subkey: 1 year maximum
> > 5. Key expiration date renewed at least 2 weeks before the previous
> >expiration date.
> 
> This is crappy as a scheme, since it will make it impossible to keep
> the expiration date at a constant month and date.
> 

Nobody forces you to prolong it for exactly the same amount, exactly two
weeks before expiration.  The only point made here is to give services
time to sync rather than the common combo of renewing key once it
already expired.

Especially, if you follow the recommended scheme below you can easily
get periodic expiration dates.

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update; full text

2018-07-04 Thread Ulrich Mueller
> On Wed, 04 Jul 2018, Michał Górny wrote:

>b. Signing subkey: 1 year maximum

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

This is crappy as a scheme, since it will make it impossible to keep
the expiration date at a constant month and date.

Ulrich


pgpFK0sjc6DBj.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update; full text

2018-07-04 Thread Michał Górny
Updated complete text after applying two more patches on k_f's request.

---
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-04
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 recommended key expiration rules have been moved to the minimal
  specification. Changing the expiration date of existing keys is possible
  in-place so there is no need to provide for transitional 'minimum' value.

  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. Key expiration:

   a. Primary key: 3 years maximum

   b. Signing subkey: 1 year maximum

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 
CAST5 BZIP2 ZLIB ZIP Uncompressed

   # If you use a graphical environment (and even if you don't) you should 
be using an agent:
   # (similar arguments as  
https://www.debian-administration.org/users/dkg/weblog/64)
   use-agent

   # You should always know at a glance which User IDs gpg thinks are 
legitimately bound to
   # the keys in your keyring:
   verify-options show-uid-validity
   list-options show-uid-validity

   # include an unambiguous indicator of which key made a signature:
   # (see 
http://thread.gmane.org/gmane.mail.notmuch.general/3721/focus=7234)
   # (and 
http://www.ietf.org/mail-archive/web/openpgp/current/msg00405.html)
   sig-notation issuer-...@notations.openpgp.fifthhorseman.net=%g

   # when making an OpenPGP 

[gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update; full text

2018-07-04 Thread Michał Górny
W dniu śro, 04.07.2018 o godzinie 12∶23 +0200, użytkownik Michał Górny
napisał:
> Hi, everyone.
> 
> Following comments and other discussion, here's a bigger patch set
> that updates GLEP 63 to v2.

And of course I forgot to include the full text.  Here it is:

---
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-04
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 recommended key expiration rules have been moved to the minimal
  specification. Changing the expiration date of existing keys is possible
  in-place so there is no need to provide for transitional 'minimum' value.

  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. Primary key and a dedicated signing subkey, both of EITHER:

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

   b. ECC, curve 25519

3. Key expiration:

   a. Primary key: 3 years maximum

   b. Gentoo subkey: 1 year maximum

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

5. 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 
CAST5 BZIP2 ZLIB ZIP Uncompressed

   # If you use a graphical environment (and even if you don't) you should 
be using an agent:
   # (similar arguments as  
https://www.debian-administration.org/users/dkg/weblog/64)
   use-agent

   # You should always know at a glance which User IDs gpg thinks are 
legitimately bound to
   # the keys in your keyring:
   verify-options show-uid-validity
   list-options show-uid-validity

   # include an unambiguous indicator of which key made a signature:
   # (see 
http://thread.gmane.org/gmane.mail.notmuch.general/3721/focus=7234)
   # (and 
http://www.ietf.org/mail-archive/web/openpgp/current/msg00405.html)
   sig-notation 

[gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update

2018-07-04 Thread Michał Górny
Hi, everyone.

Following comments and other discussion, here's a bigger patch set
that updates GLEP 63 to v2.  It's divided into three parts:

(1) editorial changes (do not change the spec but improve its wording)

(2) backwards-compatible changes (existing keys still work)

(3) backwards-incompatible changes (minimal spec updates)

Each patch comes with a little rationale of its own, so I won't be
repeating that here.  Additionally, each patch is subject to separate
discussion.

Depending on the feedback, I might end up presenting those updates
for Council approval in smaller parts.

--
Best regards,
Michał Górny


Michał Górny (11):
  glep-0063: Use 'OpenPGP' as appropriate
  glep-0063: RSAv4 -> OpenPGP v4 key format
  glep-0063: Clarify dedicated signing subkey in minimal reqs
  glep-0063: Root key → primary key
  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 recommended expiration terms mandatory
  glep-0063: Require renewal 2 weeks before expiration
  glep-0063: Disallow using DSA keys

 glep-0063.rst | 98 +++
 1 file changed, 67 insertions(+), 31 deletions(-)

-- 
2.18.0