Gentoo Archives: gentoo-project

From: "Robin H. Johnson" <robbat2@g.o>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] [RFC] OpenPGP Authority Keys to provide validity of developer/service keys
Date: Sun, 17 Feb 2019 06:56:22
Message-Id: robbat2-20190217T063210-580941267Z@orbis-terrarum.net
In Reply to: [gentoo-project] [RFC] OpenPGP Authority Keys to provide validity of developer/service keys by "Michał Górny"
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

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies