Re: APT public key updates?

[Thomas Bushnell BSG <tb@becket.net>]

Steve Langasek <vorlon@debian.org> writes:

> For a user with a compromised local network, the only safe solution is to
> validate the new key via some web of trust.  This is the feature that's
> missing today, to give Joe User some reasonable method of checking keys
> against the web of trust before importing them.

I think I understand now.  This is very helpful.

So suppose I said that "I trust keys sign by AJ Towns."  I could then
indicate that.  Of course, I am now susceptible to any compromise of
AJ's key, right?

But that means that AJ should rotate his key too.  How do I know which
key is really AJs?  By checking the signatures, from keys which could
be compromised and so they should rotate.  And so on, and so on.  All
of us need to start rotating all out keys in order for this to work.

Another way to put the same point, inverted if you will, is to ask why
it's ok to trust AJs non-rotating key, but not to trust a non-rotating
archive key.

>> If the key is compromised, which is the only way the non-expiring key
>> method can be broken, then the expiring key doesn't seem to be
>> offering all that much additional security.  
>
> Indeed it doesn't.  Ideally, if the previous key has been compromised, users
> would be verifying the integrity of the new key using other signatures; but
> in the worst case, verifying using the signature from the previous key (if
> they're disconnected from the web of trust) is no worse than not being able
> to verify it at all.

I think I now understand better, and I can better express the
uncertainty I was groping at.  A key is only as good as the keys that
sign it.  The reason for rotating the key is that there is some
non-zero risk that it will be compromised, and this limits exposure.
But in order to validate the new key, which is only as good as its
signatures, I must rely on whatever signs the new key.

I trust AJ.  So I trust AJ to sign the new key correctly.  Surely, it
seems to me, the risk of AJ allowing his own key to be compromised is
just about the same as the risk of his allowing the archive key to be
compromised.  What am I missing?

Thomas