1 |
On Sat, Feb 16, 2019 at 09:40:21AM +0100, Michał Górny wrote: |
2 |
> Your comments? Anything I've missed? |
3 |
Overall, strong +1 to the idea. |
4 |
|
5 |
Some questions/remarks: |
6 |
0. I will oppose any intentions to tie this proposal to the GLEP76 or other |
7 |
requirements of disclosing "legal" names. I realize other developers may object |
8 |
to this, but I don't believe that "legal" names in this context actually gain |
9 |
us anything of value. |
10 |
|
11 |
1. Where are non-dev users trying to verify developer keys directly at the |
12 |
moment? I thought all prior work discouraged that, in favour of verifying |
13 |
service keys instead. I do see this proposal being of a LOT more use in the |
14 |
infra-run systems that verify incoming commits/pushes. |
15 |
|
16 |
2. The uid signatures should NOT be naively exported to keyservers. They |
17 |
should use the CAFF method of generating a uid signature, writing it to a file, |
18 |
and sending it as an encrypted message to the uid address. The uid owner is |
19 |
responsible for decrypt + sending to servers. This ensures that the email |
20 |
address and key are still tied together. |
21 |
|
22 |
3. As raised elsewhere on the thread, what delays should be implicit on a new |
23 |
dev joining vs having their key auto-signed? |
24 |
|
25 |
4. uid signatures cannot generally exceed the lifetime of a primary key; the L2 |
26 |
signing service will need to resign regularly. How will this interact with the |
27 |
CAFF design above? |
28 |
|
29 |
5. You state that the users should trust the L1 key directly. Can you clarify |
30 |
your intent here to cover the trust? |
31 |
|
32 |
The most obvious interpretation to me is trust signature of of the L2 key, with |
33 |
depth=2 domain=gentoo.org [1]. |
34 |
|
35 |
[1] trust signatures domain restrictions are actually regular |
36 |
expressions; but GnuPG limits the input thereof. Just answering the |
37 |
query: |
38 |
> Please enter a domain to restrict this signature, or enter for none. |
39 |
> Your selection? gentoo.org |
40 |
Actually generates: |
41 |
> :signature packet: algo 22, keyid THROWAWAY |
42 |
> version 4, created 1550385418, md5len 0, sigclass 0x10 |
43 |
> digest algo 8, begin of digest f0 e4 |
44 |
> hashed subpkt 33 len 21 (issuer fpr v4 THROWAWAY) |
45 |
> hashed subpkt 2 len 4 (sig created 2019-02-17) |
46 |
> hashed subpkt 5 len 2 (trust signature of depth 2, value 120) |
47 |
> critical hashed subpkt 6 len 24 (regular expression: "<[^>]+[@.]gentoo\x5c.org>$\0") |
48 |
> subpkt 16 len 8 (issuer key ID THROWAWAY) |
49 |
> data: [255 bits] |
50 |
> data: [256 bits] |
51 |
|
52 |
-- |
53 |
Robin Hugh Johnson |
54 |
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer |
55 |
E-Mail : robbat2@g.o |
56 |
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 |
57 |
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 |