1 |
On Sun, Feb 24, 2019 at 12:10 PM Michał Górny <mgorny@g.o> wrote: |
2 |
|
3 |
> On Sun, 2019-02-24 at 12:04 -0500, Alec Warner wrote: |
4 |
> > On Sun, Feb 24, 2019 at 9:14 AM Michał Górny <mgorny@g.o> wrote: |
5 |
> > |
6 |
> > > --- |
7 |
> > > glep-9999.rst | 359 ++++++++++++++++++++++++++++++++++++++++++++++++++ |
8 |
> > > 1 file changed, 359 insertions(+) |
9 |
> > > create mode 100644 glep-9999.rst |
10 |
> > > |
11 |
> > > diff --git a/glep-9999.rst b/glep-9999.rst |
12 |
> > > new file mode 100644 |
13 |
> > > index 0000000..d66398b |
14 |
> > > --- /dev/null |
15 |
> > > +++ b/glep-9999.rst |
16 |
> > > @@ -0,0 +1,359 @@ |
17 |
> > > +--- |
18 |
> > > +GLEP: 9999 |
19 |
> > > +Title: Gentoo OpenPGP Authority Keys |
20 |
> > > +Author: Michał Górny <mgorny@g.o> |
21 |
> > > +Type: Standards Track |
22 |
> > > +Status: Draft |
23 |
> > > +Version: 1 |
24 |
> > > +Created: 2019-02-24 |
25 |
> > > +Last-Modified: 2019-02-24 |
26 |
> > > +Post-History: |
27 |
> > > +Content-Type: text/x-rst |
28 |
> > > +Requires: 63 |
29 |
> > > +--- |
30 |
> > > + |
31 |
> > > +Abstract |
32 |
> > > +======== |
33 |
> > > +This GLEP proposes using Authority Keys to provide developer key |
34 |
> > > +validity proofs that are compatible with web of trust. The signatures |
35 |
> > > +on ``@gentoo.org`` UIDs are automatically maintained, and user can |
36 |
> > > +follow the current set of valid keys by importing and trusting a |
37 |
> single |
38 |
> > > +Authority Key. The system operates within standard features of GnuPG |
39 |
> > > +and requires only minimal setup from the user. |
40 |
> > > + |
41 |
> > > + |
42 |
> > > +Motivation |
43 |
> > > +========== |
44 |
> > > +All the recent efforts on improving OpenPGP usage in Gentoo were |
45 |
> focused |
46 |
> > > +on internal usage and distribution. The existing policies and tooling |
47 |
> > > +are sufficient to account for verify specific usage, including commit |
48 |
> > > +signing (with both internal and user-oriented verification via custom |
49 |
> > > +tools) or release media verification. However, they do not provide |
50 |
> > > +for rapid OpenPGP deployment for secure communications usage. |
51 |
> > > + |
52 |
> > > +The Gentoo webservers distribute both convenient key bundles |
53 |
> > > +and individual keys via Web Key Directory. While in both cases |
54 |
> > > +the transfer is secured via HTTPS, providing authenticity verification |
55 |
> > > +via PKI/DNSSEC, those channels are meant to *distribute* the keys |
56 |
> > > +and not provide implicit guarantees on their *validity*. For example, |
57 |
> > > +they provide no guarantees that the user identifiers on the keys are |
58 |
> > > +legitimate. [#KEY-BUNDLES]_ |
59 |
> > > + |
60 |
> > > +Internally, Gentoo's LDAP directory serves as the canonical source |
61 |
> > > +of information on key validity. It stores a list of key fingerprints |
62 |
> > > +for each Gentoo developers, and therefore allows the system to |
63 |
> establish |
64 |
> > > +which keys are acceptable in context of a specific developer. |
65 |
> However, |
66 |
> > > +the LDAP directory is not available to the public and therefore is |
67 |
> 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 |
72 |
> fingerprints |
73 |
> > > +of all developer keys, the necessity of manually verifying such a |
74 |
> large |
75 |
> > > +number of keys would be inconvenient to the end user. |
76 |
> > > +[#WWW-SIGNATURES]_ |
77 |
> > > + |
78 |
> > > +The key package provided in the Gentoo repository is also focused |
79 |
> > > +on service keys, and has limited value in verifying key validity |
80 |
> > > +(currently, it assumes all UIDs on all keys in the keyring are valid). |
81 |
> > > +Providing a package with developer keys would both require frequent |
82 |
> > > +semi-manual updates, and establishing a more precise validity model. |
83 |
> > > +[#KEY-PACKAGE]_ |
84 |
> > > + |
85 |
> > > +Gentoo-keys project provides so-called seed files that carry enough |
86 |
> > > +information to establish key validity, and are authenticated via |
87 |
> HTTPS. |
88 |
> > > +However, they rely on installing custom software that does not |
89 |
> integrate |
90 |
> > > +well with regular use of GnuPG e.g. in mail clients, and that is not |
91 |
> > > +easily usable in other systems. [#GENTOO-KEYS]_ |
92 |
> > > + |
93 |
> > > +The Authority Key proposal aims to provide a more standard way of |
94 |
> > > +establishing validity of Gentoo developer keys. It builds upon the |
95 |
> web |
96 |
> > > +of trust model, requiring no special software and minimal setup from |
97 |
> end |
98 |
> > > +users. |
99 |
> > > + |
100 |
> > > + |
101 |
> > > +Specification |
102 |
> > > +============= |
103 |
> > > +Purpose and usage |
104 |
> > > +----------------- |
105 |
> > > +The purpose of the Authority Keys is to provide an automatically |
106 |
> issued |
107 |
> > > +signatures on Gentoo developer OpenPGP keys, based on the information |
108 |
> > > +provided internally in the Gentoo LDAP directory. The service |
109 |
> > > +is provided for all active Gentoo developers, from the moment of their |
110 |
> > > +recruitment. |
111 |
> > > + |
112 |
> > > +Whenever a developer account is created, reactivated, renamed or has |
113 |
> > > +a new key fingerprint added, a signature is automatically created |
114 |
> > > +on the appropriate ``@gentoo.org`` UIDs and pushed to the keyservers. |
115 |
> > > +Whenever an old signature expires, a new one is automatically created. |
116 |
> > > +Whenever a developer account is disabled, renamed or has a fingerprint |
117 |
> > > +removed, the signatures from obsolete UIDs are automatically revoked. |
118 |
> > > + |
119 |
> > > +The signatures are issued only on the UIDs matching the Gentoo |
120 |
> > > +developer's ``@gentoo.org`` mailbox address, on keys whose primary |
121 |
> key |
122 |
> > > +fingerprints are listed in Gentoo LDAP ``gpgfingerprint`` records. |
123 |
> Keys |
124 |
> > > +missing such an UID are ignored. **Names on the relevant user |
125 |
> > > +identifiers are not verified**. The signatures are issued with |
126 |
> > > +an expiration date of 1 year from being issued. |
127 |
> > > + |
128 |
> > > + |
129 |
> > > +L1 and L2 keys |
130 |
> > > +-------------- |
131 |
> > > +The Authority Keys are issued in two layers, appropriately called L1 |
132 |
> > > +and L2. |
133 |
> > > + |
134 |
> > > +The single L1 Authority Key is used only to (manually) certify the L2 |
135 |
> > > +Keys, and is kept securely offline following the Infrastructure |
136 |
> policies |
137 |
> > > +on protecting primary keys. The fingerprint of this key is published |
138 |
> > > +on the Gentoo website and users are requested to sign this key to |
139 |
> enable |
140 |
> > > +key validity via Authority Keys. |
141 |
> > > |
142 |
> > |
143 |
> > + |
144 |
> > > +The L2 Authority Keys are used directly to sign developer keys. Since |
145 |
> > > +they are used in an automated service, they are exposed to attacks. |
146 |
> > > +They are trust-signed by the L1 key and can be revoked and rotated |
147 |
> more |
148 |
> > > +frequently than the L1 key. |
149 |
> > > + |
150 |
> > > +This dual-layer model aims to combine improved security with user |
151 |
> > > +convenience. While the individual Gentoo keys are signed by the L2 |
152 |
> key, |
153 |
> > > +the users sign only the L1 key and the validity is established via |
154 |
> chain |
155 |
> > > +L1 → L2 → developer key. This makes it possible to replace the L2 key |
156 |
> > > +if it ever becomes compromised without requiring the users to |
157 |
> > > +reestablish trust. Since the replacement key will be also signed |
158 |
> > > +by the L1 key (provided that it was not compromised), the validity |
159 |
> > > +of developer keys will remain established. |
160 |
> > > + |
161 |
> > > + |
162 |
> > > +Validating the L1 key |
163 |
> > > +--------------------- |
164 |
> > > +Establishing the authenticity of the L1 Authority Key is essential |
165 |
> > > +to the system. Initially, the users will be able to determine |
166 |
> > > +the authenticity via comparing the key fingerprint with the one |
167 |
> > > +published on the website. This will shift the authenticity |
168 |
> verification |
169 |
> > > +to HTTPS (PKI/DNSSEC). |
170 |
> > > + |
171 |
> > > +However, at the same time users are encouraged to sign the key upon |
172 |
> > > +verifying it. This will effectively make it possible to establish |
173 |
> key's |
174 |
> > > +validity via OpenPGP web of trust. |
175 |
> > > |
176 |
> > |
177 |
> > Is the L1 specific to signing packages, or does it have other duties? |
178 |
> |
179 |
> "The single L1 Authority Key is used only to (manually) certify the L2 |
180 |
> Keys". No more duties. |
181 |
> |
182 |
> > |
183 |
> > |
184 |
> > > + |
185 |
> > > + |
186 |
> > > +Rationale |
187 |
> > > +========= |
188 |
> > > +Authority Key model vs web of trust |
189 |
> > > +----------------------------------- |
190 |
> > > +The regular web of trust model relies on individuals verifying |
191 |
> > > +the Gentoo developer identity and access to the particular |
192 |
> > > +``@gentoo.org`` e-mail address. The particular UID is considered |
193 |
> valid |
194 |
> > > +if a sufficient number of people trusted by the user in question have |
195 |
> > > +confirmed the developer's identity. This specifically relies on being |
196 |
> > > +able to establish a chain of trust between the developer and user. |
197 |
> > > + |
198 |
> > > +At the moment, many of the existing Gentoo developers did not even |
199 |
> > > +stablish a chain of trust between one another, not to mention |
200 |
> establish |
201 |
> > > |
202 |
> > |
203 |
> > establish |
204 |
> |
205 |
> Fixed. |
206 |
> |
207 |
> > +web of trust coverage that would make it feasible for users to reach any |
208 |
> > > +specific developer. Efforts towards improving that were rejected |
209 |
> > > +by the developers, mostly based on argumentation that many developers |
210 |
> > > +find it impossible to meet any other community member for the purpose |
211 |
> > > +of identity verification. |
212 |
> > > + |
213 |
> > > +The Authority Key model, on the other hand, assumes that there is |
214 |
> > > +a single trusted authority that verifies Gentoo developers' keys. |
215 |
> > > +The user verifies the key representing this authority and trusts it. |
216 |
> > > +The validity of keys used by all developers is established via a |
217 |
> single |
218 |
> > > +point of trust. |
219 |
> > > + |
220 |
> > > +The procedure of establishing the validity of a specific key does not |
221 |
> > > +involve the necessity of meeting anyone or verifying identity. While |
222 |
> > > +the validity is exposed in a manner compatible with web of trust, it |
223 |
> is |
224 |
> > > +verified against LDAP which implicitly proves authenticity of the |
225 |
> keys. |
226 |
> > > + |
227 |
> > > +Therefore, the Authority Key model is much easier to set up. The user |
228 |
> > > +merely needs to verify a single key and trust it, while pure WoT would |
229 |
> > > +probably require trusting multiple third party identities. It is also |
230 |
> > > +more secure as it limits the attack vector to a single key rather than |
231 |
> > > +one of potentially large number of keys that need to be trusted by |
232 |
> > > +the user. If the user decides to stop trusting ``@gentoo.org`` UIDs, |
233 |
> > > +the validity can easily be reverted by disabling the single Authority |
234 |
> > > +Key. |
235 |
> > > |
236 |
> > |
237 |
> > Yeah I like the revocation a lot better in this proposal, the previous |
238 |
> one |
239 |
> > seemed a bit impractical. |
240 |
> |
241 |
> Revocation is the same as in the original. Maybe worded more verbosely? |
242 |
> |
243 |
|
244 |
Oh sorry, the previous proposal being the original wot one (where |
245 |
revocation meant "everyone has to revoke the signature of any developer who |
246 |
leaves") |
247 |
|
248 |
-A |
249 |
|
250 |
|
251 |
> |
252 |
> -- |
253 |
> Best regards, |
254 |
> Michał Górny |
255 |
> |