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 --
Attachment:
signature.asc
Description: Digital signature