On Fri, 2006-05-19 at 22:03 -0400, Ned Ludd wrote: > If there is anything you or genone need to make signing happening you > have to the full support of the
> council That should not be difficult if the proposal is discussed and accepted by all other groups > infra it should be non-invasive and well documented > hardened/security. ... while offering good security So I suggest that infra and hardened/security warn of any problems they see, it would be silly to have a detailed battleplan only to have someone kill it at the last minute ... ===== Some short comments on robbat2's proposal: > > Summary: > > ----------- > > This is a brief summary of the suggestions and choices above. > > This summary outline is assuming a model such as the hybrid or complex > > models. > > > > - Each developer shall have a GnuPG key. > > - Each developer key shall contain at least one uid, with name and Gentoo > > email > > address of the developer. > > - Each developer must create a secondary cryptokey with the following > > parameters (designated as their Gentoo signing cryptokey): > > Key Type: RSA > > Key Length: 2048 or 4096 > > Expiry time: Set at 6 months out > > Usage: Marked as signing only. I think these parameters are acceptable. I can't think of compelling technical reasons to change them. > > - Each developer shall regularly update the expiry time (GnuPG enforces > > this) of the cryptokey, keeping it no further than 6 months ahead of > > the present date, except where otherwise decided. Enforcing this will be difficult, so I think it should be seen as a strong guideline (we can't stop you, but please don't mess up) > > - Each developer should have a revocation certificate for their key, and > > store two copies in a secure offline location (I suggest two CD-RWs, > > of different brands, stored in separate locations, refreshed every 6 > > months, but floppy disks would work as well). No way to enforce this > > - Each developer will sign all of their commits with their Gentoo > > signing cryptokey only. They should not sign anything else, nor use > > other cryptokeys for signing Gentoo commits. > > - (Optional, for those creating new keys only) a best practice would be > > to have a primary key that is marked as certifying only. Sounds reasonable > > (This part here needs more discussion, which may end up that N=1 is > > valid). > > - There will be N master keys. For N>1: who controls the master keys? > > - A master key will have a secondary cryptokey conforming to the same > > requirements as the developer Gentoo signing cryptokey. > > - A master key will certify all Gentoo developer keys on a regular > > basis. This can be done on 4 month intervals safely, with once-off > > events to sign keys of incoming developers, or other special cases. Why not sync this to the 6 month expiry time? Also you might want to add: - All keys and the master key shall be made available on Gentoo media (install-cd etc) and other ressources (ebuilds, download from known locations, stored on public keyservers) > > - When a developer leaves, the certification on their key shall be > > revoked. > > - Both infra and the council should hold the revocation control for a > > master key in some way so that cooperation is needed to actually revoke > > a master key. This will be very tricky to implement. > > (For future stuff:) > > For performing releases of Gentoo (releng), a designated key be used, > > and be certified by the master key. This should be discussed with releng. While I don't see why they should disagree I dislike forcing any policy on others. > > Outstanding points: > > ------------------- > > - Discussion of how the keymaster(s) should operate to maintain the > > keyring. Plus, of course, what to sign, how to sign it, how to handle failures. Patrick -- Stand still, and let the rest of the universe move
signature.asc
Description: This is a digitally signed message part
