On Fri, Jan 06, 2006 at 12:12:50AM -0800, Thomas Bushnell BSG wrote:
> Anthony Towns <aj@azure.humbug.org.au> writes:
> > No, a key is only as good as (a) how hard it is to break; and (b) how
> > easy it is to trust. Key rotation helps make it harder to break (since
> > the 2004 key won't do you much good now); and also forces us to consider
> > how to make new keys easy to trust, which we otherwise might neglect.
> Looking at the parenthesis: the 2004 key would have been quite
> valuable a week ago. It could have been used to sign a fake 2005 key.
> Oh wait: *it still can be*.
It shouldn't be, since the 2004 key expired almost a year ago. Maybe we
should be revoking expired keys as well.
> And once the 2004 key expires, that
> should mean that now I have no reason to trust the 2005 key.
Sure you do: it's already on your disk.
> (Except
> for the fact that it's signed by AJT. But then, why not just use that
> as the archive key directly?)
Because the archive key signs things automatically, and I'm not uploading
my secret key to ftp-master and putting the passphrase into a script.
Perhaps there are five phases we need to consider:
(a) key is published, available for signing by developers, but unused
(b) key is used to sign archive, along with previous key
(c) key is used to sign archive alone
(d) key is used to sign archive, along with next key
(e) key is expired and/or revoked
Any of those could be zero length. (a) might be useful for out of band
authentication ("I trust AJ", "my book says the fingerprint should
be..."); (b)/(d) is useful for transitioning to new keys. At the moment
(b) and (d) are around one month windows, maybe they should be longer.
Cheers,
aj
Attachment:
signature.asc
Description: Digital signature