[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: bits from the release team



Le Mer 10 Mai 2006 11:05, Goswin von Brederlow a écrit :
> Pierre Habouzit <madcoder@debian.org> writes:
> > Le Ven 5 Mai 2006 18:41, Florian Weimer a écrit :
> >> * Lionel Elie Mamane:
> >> > Why can't we have a master key that signs the yearly keys? After
> >> > all, we have a long-term unique X.509 master key, so what's the
> >> > difference with OpenPGP?
> >>
> >> End users are typically not exposed to the X.509 keys, which makes
> >> things a lot easier.
> >>
> >> By the way, if you've got a master key, you need to plan for key
> >> rollover, too.  Why not apply that procedure directly to the keys
> >> used to sign the release files?  A yearly key change just results
> >> in unnecessary administrative overhead for our users, without
> >> providing any real benefit to them.  A key compromise still needs
> >> manual intervention.
> >>
> >> At the very least, if we have to keep that yearly key change for
> >> political reasons, please schedule it in a way that it doesn't
> >> happen in January.
> >
> > Proposal 1:
> >
> >   a possible way would be to have two valid keys at any time. like
> > one new key per year (or 6 month like you want) with a validity of
> > 2 years (resp. one year).
> >
> >   that would obviously mean two signatures per package (but I don't
> >   think that's that much work) and would require the user to update
> >   their "keyring package" only once every year (or 6 month), which
> > looks like a quite reasonnable trade-off. Even stable updates can
> > use that scheme, since it's released more than once a year.
>
> Except that apt-get fails if any of the signatures are unknown or
> expired. So you still need both keys and not just one of them as you
> intent.

that is obviously "fixe-able"

> > Proposal ...:
> >
> >   there is a lot of such ideas IMHO, one just has to think 10
> > minutes to imagine a couple of ones.
> >
> >
> > IMHO, changing the key every year at any date is not problematic at
> > all, because there is plenty of solution to do smooth replacement
> > of the key.
>
> Do you see any drawbacks with my proposal of having Release.key next
> to each Releas.gpg or do you have a better idea that will work for
> every apt-getable archive?

this is obviously a valid idea, except that you have to have those key 
over https to avoid MiM attacks, with a valid https CA (like in not 
self-signed).
-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

Attachment: pgpPVKicWamwo.pgp
Description: PGP signature


Reply to: