On Wed, May 04, 2005 at 03:08:42PM -0700, Matt Zimmerman wrote: > > Which can't be done (savely) if the key is compromised or expires > > before the update (like it does every year). > > If the key is compromised, we lose, no matter what we do. > > I recommend that we create keys which will not expire before the next > release.
istr discussing (or at least thinking to myself) a method of "rolling"
keys, where one key was used to sign another key, which would then
ideally be kept somewhere Safe for the case of unexpected expiration.
this second key could then be used to sign a third key, and so-forth.
i guess this wouldn't handle upgrades of apt that skipped a "key epoch",
but that could probably be worked around by keeping the old keys around
somewhere so that they could be used to somehow establish a chain of
trust to the newest key.
in the case of a compromise you'd still need an extra verification;
because you'd have to assume that the compromised key could have been
used by the mean people to sign phony keys. that could pretty easily
be accomplished by attaching another d-d's signature to it when it
was generated, right? if the key was really kept somewhere Safe, there
would be no risk of the first key's compromise affecting it.
sean
--
signature.asc
Description: Digital signature
