1 |
commit: 4a42e869d1517cf77fdc897fbac75ba7b8f3df6a |
2 |
Author: Michał Górny <mgorny <AT> gentoo <DOT> org> |
3 |
AuthorDate: Sun Feb 24 14:11:26 2019 +0000 |
4 |
Commit: Michał Górny <mgorny <AT> gentoo <DOT> org> |
5 |
CommitDate: Sun Mar 3 07:16:15 2019 +0000 |
6 |
URL: https://gitweb.gentoo.org/data/glep.git/commit/?id=4a42e869 |
7 |
|
8 |
GLEP 79: Gentoo OpenPGP Authority Keys |
9 |
|
10 |
Bug: https://bugs.gentoo.org/679250 |
11 |
Signed-off-by: Michał Górny <mgorny <AT> gentoo.org> |
12 |
|
13 |
glep-0079.rst | 359 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
14 |
1 file changed, 359 insertions(+) |
15 |
|
16 |
diff --git a/glep-0079.rst b/glep-0079.rst |
17 |
new file mode 100644 |
18 |
index 0000000..3a7eacb |
19 |
--- /dev/null |
20 |
+++ b/glep-0079.rst |
21 |
@@ -0,0 +1,359 @@ |
22 |
+--- |
23 |
+GLEP: 79 |
24 |
+Title: Gentoo OpenPGP Authority Keys |
25 |
+Author: Michał Górny <mgorny@g.o> |
26 |
+Type: Standards Track |
27 |
+Status: Draft |
28 |
+Version: 1 |
29 |
+Created: 2019-02-24 |
30 |
+Last-Modified: 2019-03-03 |
31 |
+Post-History: 2019-02-24 |
32 |
+Content-Type: text/x-rst |
33 |
+Requires: 63 |
34 |
+--- |
35 |
+ |
36 |
+Abstract |
37 |
+======== |
38 |
+This GLEP proposes using Authority Keys to provide developer key |
39 |
+validity proofs that are compatible with web of trust. The signatures |
40 |
+on ``@gentoo.org`` UIDs are automatically maintained, and user can |
41 |
+follow the current set of valid keys by importing and trusting a single |
42 |
+Authority Key. The system operates within standard features of GnuPG |
43 |
+and requires only minimal setup from the user. |
44 |
+ |
45 |
+ |
46 |
+Motivation |
47 |
+========== |
48 |
+All the recent efforts on improving OpenPGP usage in Gentoo were focused |
49 |
+on internal usage and distribution. The existing policies and tooling |
50 |
+are sufficient to account for verify specific usage, including commit |
51 |
+signing (with both internal and user-oriented verification via custom |
52 |
+tools) or release media verification. However, they do not provide |
53 |
+for rapid OpenPGP deployment for secure communications usage. |
54 |
+ |
55 |
+The Gentoo webservers distribute both convenient key bundles |
56 |
+and individual keys via Web Key Directory. While in both cases |
57 |
+the transfer is secured via HTTPS, providing authenticity verification |
58 |
+via PKI/DNSSEC, those channels are meant to *distribute* the keys |
59 |
+and not provide implicit guarantees on their *validity*. For example, |
60 |
+they provide no guarantees that the user identifiers on the keys are |
61 |
+legitimate. [#KEY-BUNDLES]_ |
62 |
+ |
63 |
+Internally, Gentoo's LDAP directory serves as the canonical source |
64 |
+of information on key validity. It stores a list of key fingerprints |
65 |
+for each Gentoo developers, and therefore allows the system to establish |
66 |
+which keys are acceptable in context of a specific developer. However, |
67 |
+the LDAP directory is not available to the public and therefore is only |
68 |
+suitable for internal infrastructure use. [#LDAP-GUIDE]_ |
69 |
+ |
70 |
+The Gentoo website is focused on service keys and not individual |
71 |
+developer keys. While it could easily be amended with full fingerprints |
72 |
+of all developer keys, the necessity of manually verifying such a large |
73 |
+number of keys would be inconvenient to the end user. |
74 |
+[#WWW-SIGNATURES]_ |
75 |
+ |
76 |
+The key package provided in the Gentoo repository is also focused |
77 |
+on service keys, and has limited value in verifying key validity |
78 |
+(currently, it assumes all UIDs on all keys in the keyring are valid). |
79 |
+Providing a package with developer keys would both require frequent |
80 |
+semi-manual updates, and establishing a more precise validity model. |
81 |
+[#KEY-PACKAGE]_ |
82 |
+ |
83 |
+Gentoo-keys project provides so-called seed files that carry enough |
84 |
+information to establish key validity, and are authenticated via HTTPS. |
85 |
+However, they rely on installing custom software that does not integrate |
86 |
+well with regular use of GnuPG e.g. in mail clients, and that is not |
87 |
+easily usable in other systems. [#GENTOO-KEYS]_ |
88 |
+ |
89 |
+The Authority Key proposal aims to provide a more standard way of |
90 |
+establishing validity of Gentoo developer keys. It builds upon the web |
91 |
+of trust model, requiring no special software and minimal setup from end |
92 |
+users. |
93 |
+ |
94 |
+ |
95 |
+Specification |
96 |
+============= |
97 |
+Purpose and usage |
98 |
+----------------- |
99 |
+The purpose of the Authority Keys is to provide an automatically issued |
100 |
+signatures on Gentoo developer OpenPGP keys, based on the information |
101 |
+provided internally in the Gentoo LDAP directory. The service |
102 |
+is provided for all active Gentoo developers, from the moment of their |
103 |
+recruitment. |
104 |
+ |
105 |
+Whenever a developer account is created, reactivated, renamed or has |
106 |
+a new key fingerprint added, a signature is automatically created |
107 |
+on the appropriate ``@gentoo.org`` UIDs and pushed to the keyservers. |
108 |
+Whenever an old signature expires, a new one is automatically created. |
109 |
+Whenever a developer account is disabled, renamed or has a fingerprint |
110 |
+removed, the signatures from obsolete UIDs are automatically revoked. |
111 |
+ |
112 |
+The signatures are issued only on the UIDs matching the Gentoo |
113 |
+developer's ``@gentoo.org`` mailbox address, on keys whose primary key |
114 |
+fingerprints are listed in Gentoo LDAP ``gpgfingerprint`` records. Keys |
115 |
+missing such an UID are ignored. **Names on the relevant user |
116 |
+identifiers are not verified**. The signatures are issued with |
117 |
+an expiration date of 1 year from being issued. |
118 |
+ |
119 |
+ |
120 |
+L1 and L2 keys |
121 |
+-------------- |
122 |
+The Authority Keys are issued in two layers, appropriately called L1 |
123 |
+and L2. |
124 |
+ |
125 |
+The single L1 Authority Key is used only to (manually) certify the L2 |
126 |
+Keys, and is kept securely offline following the Infrastructure policies |
127 |
+on protecting primary keys. The fingerprint of this key is published |
128 |
+on the Gentoo website and users are requested to sign this key to enable |
129 |
+key validity via Authority Keys. |
130 |
+ |
131 |
+The L2 Authority Keys are used directly to sign developer keys. Since |
132 |
+they are used in an automated service, they are exposed to attacks. |
133 |
+They are trust-signed by the L1 key and can be revoked and rotated more |
134 |
+frequently than the L1 key. |
135 |
+ |
136 |
+This dual-layer model aims to combine improved security with user |
137 |
+convenience. While the individual Gentoo keys are signed by the L2 key, |
138 |
+the users sign only the L1 key and the validity is established via chain |
139 |
+L1 → L2 → developer key. This makes it possible to replace the L2 key |
140 |
+if it ever becomes compromised without requiring the users to |
141 |
+reestablish trust. Since the replacement key will be also signed |
142 |
+by the L1 key (provided that it was not compromised), the validity |
143 |
+of developer keys will remain established. |
144 |
+ |
145 |
+ |
146 |
+Validating the L1 key |
147 |
+--------------------- |
148 |
+Establishing the authenticity of the L1 Authority Key is essential |
149 |
+to the system. Initially, the users will be able to determine |
150 |
+the authenticity via comparing the key fingerprint with the one |
151 |
+published on the website. This will shift the authenticity verification |
152 |
+to HTTPS (PKI/DNSSEC). |
153 |
+ |
154 |
+However, at the same time users are encouraged to sign the key upon |
155 |
+verifying it. This will effectively make it possible to establish key's |
156 |
+validity via OpenPGP web of trust. |
157 |
+ |
158 |
+ |
159 |
+Rationale |
160 |
+========= |
161 |
+Authority Key model vs web of trust |
162 |
+----------------------------------- |
163 |
+The regular web of trust model relies on individuals verifying |
164 |
+the Gentoo developer identity and access to the particular |
165 |
+``@gentoo.org`` e-mail address. The particular UID is considered valid |
166 |
+if a sufficient number of people trusted by the user in question have |
167 |
+confirmed the developer's identity. This specifically relies on being |
168 |
+able to establish a chain of trust between the developer and user. |
169 |
+ |
170 |
+At the moment, many of the existing Gentoo developers did not even |
171 |
+establish a chain of trust between one another, not to mention web |
172 |
+of trust coverage that would make it feasible for users to reach any |
173 |
+specific developer. Efforts towards improving that were rejected |
174 |
+by the developers, mostly based on argumentation that many developers |
175 |
+find it impossible to meet any other community member for the purpose |
176 |
+of identity verification. |
177 |
+ |
178 |
+The Authority Key model, on the other hand, assumes that there is |
179 |
+a single trusted authority that verifies Gentoo developers' keys. |
180 |
+The user verifies the key representing this authority and trusts it. |
181 |
+The validity of keys used by all developers is established via a single |
182 |
+point of trust. |
183 |
+ |
184 |
+The procedure of establishing the validity of a specific key does not |
185 |
+involve the necessity of meeting anyone or verifying identity. While |
186 |
+the validity is exposed in a manner compatible with web of trust, it is |
187 |
+verified against LDAP which implicitly proves authenticity of the keys. |
188 |
+ |
189 |
+Therefore, the Authority Key model is much easier to set up. The user |
190 |
+merely needs to verify a single key and trust it, while pure WoT would |
191 |
+probably require trusting multiple third party identities. It is also |
192 |
+more secure as it limits the attack vector to a single key rather than |
193 |
+one of potentially large number of keys that need to be trusted by |
194 |
+the user. If the user decides to stop trusting ``@gentoo.org`` UIDs, |
195 |
+the validity can easily be reverted by disabling the single Authority |
196 |
+Key. |
197 |
+ |
198 |
+ |
199 |
+Authority Key vs gentoo-keys |
200 |
+---------------------------- |
201 |
+The gentoo-keys project provides seed data that is sufficient to verify |
202 |
+the authenticity of the keys. However, this data uses entirely custom |
203 |
+format and therefore requires special tooling to process. This tooling |
204 |
+has not been packaged for any other Linux distribution or operating |
205 |
+system, and is non-trivial to install as unprivileged user. |
206 |
+ |
207 |
+The Authority Key model is based entirely on built-in GnuPG features. |
208 |
+It does not require any special tooling to run. The necessary bootstrap |
209 |
+can be done manually via GnuPG command-line facilities. Eventually, |
210 |
+even that may become unnecessary if the Authority Key is covered via |
211 |
+web of trust. |
212 |
+ |
213 |
+Furthermore, gentoo-keys seed data currently requires manual updates. |
214 |
+The Authority Key system is automated, and therefore subject to smaller |
215 |
+delays in operation. |
216 |
+ |
217 |
+ |
218 |
+Developer coverage |
219 |
+------------------ |
220 |
+In the original proposal, it was debated whether new developers should |
221 |
+be subject to grace period during which their keys would not be signed. |
222 |
+However, no arguments were brought to support such a period, |
223 |
+and therefore the GLEP assumes all developers are covered as long |
224 |
+as they are considered active Gentoo developers. |
225 |
+ |
226 |
+Since only ``@gentoo.org`` e-mail addresses are under Gentoo control |
227 |
+and developer identities outside the distribution are outside the scope |
228 |
+of this project, only UIDs matching the respective developer addresses |
229 |
+are signed. This is meant to prevent the developers from forging |
230 |
+somebody else's identity. |
231 |
+ |
232 |
+The developers' real names are not verified. Firstly, the purpose |
233 |
+of this project is to establish association between keys and specific |
234 |
+Gentoo developers, whose primary identification is the nickname used |
235 |
+in Gentoo. The exact real name is irrelevant to the validity in this |
236 |
+context. Secondly, comparing real names between LDAP and user |
237 |
+identifiers would be non-trivial and most likely cause a number of |
238 |
+developers being silently rejected due to e.g. modified name spelling. |
239 |
+ |
240 |
+ |
241 |
+caff verification model |
242 |
+----------------------- |
243 |
+During the initial debate, using a model similar to Debian's caff tool |
244 |
+was suggested. In this model, new signatures are sent encrypted |
245 |
+to the developers rather than uploaded straight to keyservers. |
246 |
+Developers need to decrypt and add them to their keys themselves. |
247 |
+[#CAFF]_ |
248 |
+ |
249 |
+The main purpose of the caff model is to assist users in verifying |
250 |
+e-mail addresses of the UIDs they are about to sign. By sending |
251 |
+an encrypted e-mail, this model verifies that the recipient is both |
252 |
+able to receive mail at a specific address and decrypt messages |
253 |
+encrypted using the specified key. Since the message contains complete |
254 |
+signature ready to be imported, the key signing process can be completed |
255 |
+entirely by the recipient and the sender does not need to be concerned |
256 |
+past sending it. |
257 |
+ |
258 |
+However, there seems to be no clear reason to employ this model here. |
259 |
+A reasonable assumption can be made that if one is able to access |
260 |
+the LDAP directory as a particular Gentoo developer, one is also able |
261 |
+to access the developer's mailbox. This considered, verifying |
262 |
+the e-mail address in caff fashion is redundant. |
263 |
+ |
264 |
+Furthermore, implementing this model increases complexity both server- |
265 |
+and client-side. The server would need to be entirely stateful to avoid |
266 |
+sending duplicate mails, and at the same time it would need to permit |
267 |
+re-requesting signature e-mails. The developers would need to manually |
268 |
+import the signature and send it to keyservers. |
269 |
+ |
270 |
+It is quite probable that some of the less active developers would be |
271 |
+permanently excluded by being unaware or uninterested in participating |
272 |
+in the new system. Furthermore, signature expirations would cause |
273 |
+potentially extensive periods of key invalidity to occur (between |
274 |
+signature expiration and import of the new one). During those periods, |
275 |
+users' ability to mail developers securely would be hindered. |
276 |
+ |
277 |
+ |
278 |
+Dual-layer model |
279 |
+---------------- |
280 |
+The dual-layer Authority Key model is established in order to combine |
281 |
+security with needed automation. The L1 Key provides higher level |
282 |
+of security, at the cost of requiring manual operation. The L2 Keys are |
283 |
+suitable for automated use but that implies they're exposed to attacks. |
284 |
+ |
285 |
+If the model was based on a single key and that key was compromised, |
286 |
+the key would have to be revoked and replaced with a new one. All users |
287 |
+would have to fetch the new key and validate it independently to restore |
288 |
+the developer key validity. |
289 |
+ |
290 |
+Using two keys introduces a middle link in the trust chain that can be |
291 |
+replaced easily. Users trust the L1 Key which is unlikely to be |
292 |
+compromised. The trust on L2 Key is implicitly provided by the L1 Key, |
293 |
+and users do not need to be specifically concerned about it. If L2 Key |
294 |
+is compromised, the Infrastructure developers can replace it and restore |
295 |
+the trust via (non-compromised) L1 Key. Users only have to fetch |
296 |
+the new key and validity is restored. |
297 |
+ |
298 |
+ |
299 |
+Security considerations |
300 |
+----------------------- |
301 |
+The user needs to be able to verify the authenticity of the L1 Key. |
302 |
+This can be done in one of two ways: |
303 |
+ |
304 |
+a. via comparing the fingerprint against the record on Gentoo website. |
305 |
+ This relies on the security of Gentoo web servers, and the website |
306 |
+ content repository. From user side, authenticity relies on PKI |
307 |
+ and/or DNSSEC, and possibly any other future HTTPS protection |
308 |
+ mechanisms. |
309 |
+ |
310 |
+b. via web of trust, provided the user trusts someone who verified |
311 |
+ the key first. In this case, the authenticity relies entirely |
312 |
+ on the web of trust model, and is subject to attacks specific to it |
313 |
+ (e.g. to wrongly trusting a malicious person). |
314 |
+ |
315 |
+The L1 Key itself is protected from being compromised via current |
316 |
+Infrastructure best practices. At this moment, this involves password |
317 |
+protection and offline storage. If the key ever becomes compromised, |
318 |
+the procedures involve revoking it and announcing the problem. |
319 |
+ |
320 |
+The L2 Keys lack this kind of protection by design. If they become |
321 |
+compromised, the procedure involves revoking the key quickly |
322 |
+and replacing it with a new one. |
323 |
+ |
324 |
+In both cases, the revocation procedure relies on the user periodically |
325 |
+refreshing keys against reliable sources. Typically this involves using |
326 |
+SKS keyservers over HKPS which in turn relies on PKI to prevent a third |
327 |
+party from intercepting propagation of revocations. |
328 |
+ |
329 |
+The validity of developer key UIDs is established via signatures made |
330 |
+by the L2 Key. If UIDs become no longer valid, the signatures are |
331 |
+revoked in order to invalidate them. This also relies on users |
332 |
+periodically pulling keyservers for developer key updates. |
333 |
+ |
334 |
+Additionally, signatures are made with one year expiration time. |
335 |
+In the extremely unlikely case of scripts failing to revoke |
336 |
+the particular signature, it will expire automatically. |
337 |
+ |
338 |
+ |
339 |
+Backwards Compatibility |
340 |
+======================= |
341 |
+This proposal is established independently of existing solutions, |
342 |
+and does not affect them. |
343 |
+ |
344 |
+ |
345 |
+Reference Implementation |
346 |
+======================== |
347 |
+The reference tooling for maintaining Authority Key signatures is |
348 |
+published as gentoo-authority-key project. [#GENTOO-AUTHORITY-KEY]_ |
349 |
+ |
350 |
+ |
351 |
+References |
352 |
+========== |
353 |
+.. [#KEY-BUNDLES] Directory listing including .gpg key bundles |
354 |
+ (https://qa-reports.gentoo.org/output/) |
355 |
+ |
356 |
+.. [#LDAP-GUIDE] Project:Infrastructure/LDAP Guide - Gentoo Wiki |
357 |
+ (https://wiki.gentoo.org/wiki/Project:Infrastructure/LDAP_Guide) |
358 |
+ |
359 |
+.. [#WWW-SIGNATURES] Release media signatures - Gentoo Linux |
360 |
+ (https://www.gentoo.org/downloads/signatures/) |
361 |
+ |
362 |
+.. [#KEY-PACKAGE] app-crypt/openpgp-keys-gentoo-release – Gentoo Packages |
363 |
+ (https://packages.gentoo.org/packages/app-crypt/openpgp-keys-gentoo-release) |
364 |
+ |
365 |
+.. [#GENTOO-KEYS] Project:Gentoo-keys - Gentoo Wiki |
366 |
+ (https://wiki.gentoo.org/wiki/Project:Gentoo-keys) |
367 |
+ |
368 |
+.. [#CAFF] caff - Debian Wiki |
369 |
+ (https://wiki.debian.org/caff) |
370 |
+ |
371 |
+.. [#GENTOO-AUTHORITY-KEY] mgorny/gentoo-authority-key: Script to |
372 |
+ automatically sign developer keys using OpenPGP authority key |
373 |
+ (https://github.com/mgorny/gentoo-authority-key) |
374 |
+ |
375 |
+ |
376 |
+Copyright |
377 |
+========= |
378 |
+This work is licensed under the Creative Commons Attribution-ShareAlike 3.0 |
379 |
+Unported License. To view a copy of this license, visit |
380 |
+http://creativecommons.org/licenses/by-sa/3.0/. |