Re: [gentoo-dev] Signing everything, for fun and for profit

[Patrick Lauer <patrick@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 4004 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]