Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev@l.g.o
Cc: "Michał Górny" <mgorny@g.o>
Subject: [gentoo-dev] [PATCH 3/3] glep-0063: Include a rationale
Date: Sat, 04 Aug 2018 08:11:23
In Reply to: [gentoo-dev] [PATCH 0/3] GLEP 63: rationale part by "Michał Górny"
1 ---
2 glep-0063.rst | 129 ++++++++++++++++++++++++++++++++++++++++++++++++++
3 1 file changed, 129 insertions(+)
5 diff --git a/glep-0063.rst b/glep-0063.rst
6 index e40ddd3..cab52b0 100644
7 --- a/glep-0063.rst
8 +++ b/glep-0063.rst
9 @@ -132,6 +132,122 @@ of the fingerprint field. In any place that presently displays
10 the "``gpgkey``" field, the last 16 hex digits of the fingerprint should
11 be displayed instead.
13 +Rationale
14 +=========
15 +
16 +Foreword
17 +--------
18 +
19 +This policy aims to provide a good set of OpenPGP usage policies both
20 +to protect Gentoo resources from unauthorized access and to protect developer
21 +identities from being spoofed. The former is significant since it could
22 +be used to deliver malicious content to Gentoo users; the latter because
23 +it could be used to damage the reputation of Gentoo.
24 +
25 +Separate signing subkey
26 +-----------------------
27 +
28 +The specification requires that a separate subkey is used for signing. This
29 +is a subset of more general recommendation of using the primary key only for
30 +the purpose of important key operations and storing it offline, while using
31 +separate subkeys for day-to-day operations.
32 +
33 +The main purpose of this is to reduce the attack surface. By reducing the use
34 +of primary key and keeping it offline, the risk of attacks against it is
35 +reduced. If the attacker manages to compromise the developer's keyring, only
36 +subkeys are compromised and the developer can revoke them without having
37 +the whole key compromised.
38 +
39 +Furthermore, the specification requires separate subkeys for different
40 +purposes. This is a generally agreed on practice (e.g. GnuPG defaults to
41 +using a separate encryption key) aiming to further reduce the attack surface.
42 +Kristian Fiskerstrand points out e.g. it is technically possible to obtain
43 +a valid signature over crafted data while using the subkey for purposes
44 +of authorization [#COUNCIL-MEETING-20180729]_.
45 +
46 +Revocation certificate
47 +----------------------
48 +
49 +The specification recommends the best practice of storing a copy
50 +of the revocation certificate off site. A common recommendation is to have
51 +the ASCII-armored version of the certificate printed on paper, to protect
52 +against hardware failures (but beware that print servers may store a copy
53 +of the data!).
54 +
55 +The goal of the revocation certificate is to provide the developer with
56 +ability to revoke the key in case the access to it is lost, e.g. due to
57 +hardware damage combined with lack of backups, major events resulting
58 +in backups being destroyed as well, or more importantly in the event
59 +of hardware being stolen or lost.
60 +
61 +Key algorithm and length
62 +------------------------
63 +
64 +The choice of key algorithm and length defines the resistance of the key
65 +against brute-force attacks.
66 +
67 +Originally, the specification permitted using DSA keys. However, there is no
68 +compelling reason to continue using DSA. According to the GnuPG FAQ, RSA has
69 +much wider support in smart-card solutions [#GNUPG-FAQ-11-1]_. Furthermore,
70 +the RFC 4880bis draft removes the requirement of DSA support in clients favor
71 +of obligatory RSA (and ECDSA) support [#RFC4880bis]_.
72 +
73 +The RSA algorithm is recommended as it is considered secure at the moment
74 +and provides for the best interoperability. The 2048-bit key length
75 +is considered sufficiently secure for all our uses. Historically, this
76 +specification recommended 4096-bit keys. However, while longer keys are still
77 +permitted, they are no longer recommended as they give little in regards
78 +to security, yet are capable of causing performance problems, especially
79 +when using external hardware [#GNUPG-FAQ-11-4]_.
80 +
81 +Additionally, elliptic curve algorithms using Curve 25519 are allowed.
82 +However, they are not recommended due to compatibility concerns
83 +(in particular, not being supported by GnuPG prior to 2.1).
84 +The remaining curves supported by GnuPG (and appropriately listed
85 +in RFC 4880bis draft) are not allowed since there are concerns about safety
86 +of those curves [#SAFECURVES]_.
87 +
88 +Key expiration
89 +--------------
90 +
91 +It is important to note that the expiration dates as required by this
92 +specification are not to be conflated with key rotation. This specification
93 +does not enforce any specific key rotation scheme; expiration serves purely
94 +the purpose of requiring periodic prolongation.
95 +
96 +This policy serves two purposes. Firstly, it provides a last fallback option
97 +in the event of access to the secret keys being lost and there being
98 +no possibility of revoking them. In this case, the keys eventually expire
99 +and users can clearly see that they are no longer being used. Secondly, it
100 +ensures that the developers periodically confirm their access to the primary
101 +key.
102 +
103 +The expiration period has been chosen as a matter of compromise between being
104 +secure and causing major trouble to developers keeping keys in secure vaults.
105 +The period of 900 days represents the baseline of 2 years with roughly half
106 +a year grace period for extending the expiration date early. Specifying it
107 +in days makes it possible to automatically verify it without having to account
108 +for different lengths of year.
109 +
110 +Additionally, the specification requires renewing the key at least two weeks
111 +before expiration. This is meant to provide the developers early notice
112 +of upcoming expiration and provide time for both the users and Gentoo
113 +Infrastructure to refresh keys.
114 +
115 +Key distribution
116 +----------------
117 +
118 +The specification requires that the key used by the developer includes his
119 +@g.o e-mail address in one of the UIDs, and the key is uploaded
120 +to the SKS keyservers. This ensures that the developer keys can easily
121 +be found by the users. Furthermore, the latter is also necessary
122 +for the Gentoo Infrastructure to fetch the key and its updates.
123 +
124 +Currently the specification does not specify establishing a Web of Trust
125 +between Gentoo developers. While this is generally a good recommendation, it
126 +is not considered possible for all developers to be actually able to meet
127 +other developers, and no other solution has been agreed on so far.
128 +
129 Backwards Compatibility
130 =======================
132 @@ -160,6 +276,19 @@ References
133 .. [#GNUPG-FAQ-11-4] GnuPG FAQ: Why doesn’t GnuPG default to using RSA-4096?
134 (
136 +.. [#COUNCIL-MEETING-20180729] Gentoo Council 2018-07-29 meeting log
137 + (
138 +
139 +.. [#GNUPG-FAQ-11-1] GnuPG FAQ: Which ciphers are recommended, and why?
140 + (
141 +
142 +.. [#RFC4880bis] OpenPGP Message Format; draft-ietf-openpgp-rfc4880bis-05
143 + (
144 +
145 +.. [#SAFECURVES] Daniel J. Bernstein, Tanja Lange. SafeCurves: choosing
146 + safe curves for elliptic-curve cryptography (as of 2018-08-04)
147 + (
148 +
149 .. [#DEVMANUAL-MANIFEST] Gentoo Development Guide: Manifest
150 (
152 --
153 2.18.0