1 |
On Fri, 2006-05-19 at 22:03 -0400, Ned Ludd wrote: |
2 |
> If there is anything you or genone need to make signing happening you |
3 |
> have to the full support of the |
4 |
|
5 |
> council |
6 |
That should not be difficult if the proposal is discussed and accepted |
7 |
by all other groups |
8 |
|
9 |
> infra |
10 |
it should be non-invasive and well documented |
11 |
|
12 |
> hardened/security. |
13 |
... while offering good security |
14 |
|
15 |
So I suggest that infra and hardened/security warn of any problems they |
16 |
see, it would be silly to have a detailed battleplan only to have |
17 |
someone kill it at the last minute ... |
18 |
|
19 |
===== |
20 |
|
21 |
Some short comments on robbat2's proposal: |
22 |
> > Summary: |
23 |
> > ----------- |
24 |
> > This is a brief summary of the suggestions and choices above. |
25 |
> > This summary outline is assuming a model such as the hybrid or complex |
26 |
> > models. |
27 |
> > |
28 |
> > - Each developer shall have a GnuPG key. |
29 |
> > - Each developer key shall contain at least one uid, with name and Gentoo email |
30 |
> > address of the developer. |
31 |
> > - Each developer must create a secondary cryptokey with the following |
32 |
> > parameters (designated as their Gentoo signing cryptokey): |
33 |
> > Key Type: RSA |
34 |
> > Key Length: 2048 or 4096 |
35 |
> > Expiry time: Set at 6 months out |
36 |
> > Usage: Marked as signing only. |
37 |
I think these parameters are acceptable. I can't think of compelling |
38 |
technical reasons to change them. |
39 |
|
40 |
> > - Each developer shall regularly update the expiry time (GnuPG enforces |
41 |
> > this) of the cryptokey, keeping it no further than 6 months ahead of |
42 |
> > the present date, except where otherwise decided. |
43 |
Enforcing this will be difficult, so I think it should be seen as a |
44 |
strong guideline (we can't stop you, but please don't mess up) |
45 |
|
46 |
> > - Each developer should have a revocation certificate for their key, and |
47 |
> > store two copies in a secure offline location (I suggest two CD-RWs, |
48 |
> > of different brands, stored in separate locations, refreshed every 6 |
49 |
> > months, but floppy disks would work as well). |
50 |
No way to enforce this |
51 |
|
52 |
> > - Each developer will sign all of their commits with their Gentoo |
53 |
> > signing cryptokey only. They should not sign anything else, nor use |
54 |
> > other cryptokeys for signing Gentoo commits. |
55 |
> > - (Optional, for those creating new keys only) a best practice would be |
56 |
> > to have a primary key that is marked as certifying only. |
57 |
Sounds reasonable |
58 |
|
59 |
> > (This part here needs more discussion, which may end up that N=1 is |
60 |
> > valid). |
61 |
> > - There will be N master keys. |
62 |
For N>1: who controls the master keys? |
63 |
|
64 |
> > - A master key will have a secondary cryptokey conforming to the same |
65 |
> > requirements as the developer Gentoo signing cryptokey. |
66 |
> > - A master key will certify all Gentoo developer keys on a regular |
67 |
> > basis. This can be done on 4 month intervals safely, with once-off |
68 |
> > events to sign keys of incoming developers, or other special cases. |
69 |
Why not sync this to the 6 month expiry time? |
70 |
Also you might want to add: |
71 |
- All keys and the master key shall be made available on Gentoo media |
72 |
(install-cd etc) and other ressources (ebuilds, download from known |
73 |
locations, stored on public keyservers) |
74 |
|
75 |
> > - When a developer leaves, the certification on their key shall be |
76 |
> > revoked. |
77 |
> > - Both infra and the council should hold the revocation control for a |
78 |
> > master key in some way so that cooperation is needed to actually revoke |
79 |
> > a master key. |
80 |
This will be very tricky to implement. |
81 |
> > (For future stuff:) |
82 |
> > For performing releases of Gentoo (releng), a designated key be used, |
83 |
> > and be certified by the master key. |
84 |
This should be discussed with releng. While I don't see why they should |
85 |
disagree I dislike forcing any policy on others. |
86 |
|
87 |
> > Outstanding points: |
88 |
> > ------------------- |
89 |
> > - Discussion of how the keymaster(s) should operate to maintain the |
90 |
> > keyring. |
91 |
Plus, of course, what to sign, how to sign it, how to handle failures. |
92 |
|
93 |
Patrick |
94 |
-- |
95 |
Stand still, and let the rest of the universe move |