multiple signing keys

[Marco Colombo]

On Fri, 7 Sep 2001, Janusz A. Urbanowicz wrote:

> Marco Colombo wrote/napisa=B3[a]/schrieb:
> [Charset ISO-8859-15 unsupported, filtering to ASCII...]
>
> > I see. So, generally speaking, it is not advisable to remove expired =
keys,
> > since they can be un-expired later. But if I delete the (private) key=
,
> > no one can un-expire it (not even me), true?
>
> Yes, and moreover you won't be able to decrypt anything encrypted with
> corresponding public key. This applies to messages received both before=
 and
> after expiration date.

I know. But the key is used *only* for RPM signing. I don't really care:
there shouldn't be any message at all. Even the public key actually never
"goes public": it lives only in root's keyring on target hosts, and it
is placed there by hand - something like:
gpg --export -a <uid> | rsh root@target gpg --import

> > An example:
> > - I create a signing key, with expire 2002-01-01, and export it to th=
e
> >   target hosts;
> > - On 2002-01-01, it expires.
> > - On 2002-01-04, I change the expire date, and sign something with it.
> > - I DO NOT re-export it to targets.
> >
> > Do target hosts verify the signature as good or bad?
>
> The signature will be good although there will be warning that 'Signing=
 key
> has expired on <date>.' or similar.

Oh, ok, now it makes perfect sense to me. That was the missing point.
I need rpm -K to fail when the key expires. I'll try and find a workaroun=
d,
if needed.

> > If it is good, then I see the need to revoke the key, but then I don'=
t
> > understand what 'expire' means. If it is bad, then I guess I need to
> > export the key again to host targets.
>
> Expire date means that signatures made with that key are not to be
> considered valid after the expire date. But they still will be perfectl=
y
> good and verifiable signatures.

So the signature is "good", but to be considered "invalid". I need to
check what rpm -K really does, if that happens.

> > But if an attacker is able to do that (and here the keyring on the ta=
rget
> > hosts is root's one) he can add ANY key to the keyring.
>
> Do what? Reset the expiry date? You need key's secret key to do this.

Ok, I need to make it clearer. The application here is to protect the
target hosts, which use an automated update system, so that only signed
software gets installed. If an attacker is able to tamper with root's
keyring on a target system, he can already do any kind of damage, and
besides that, he can replace or add any (public) key. After that he's
able to have any software installed. The point is that he doesn't need
the private key at all.

>
> Alex
>

I was under the impression that setting an expires helps if the key
is compromized, somewhat limiting the damage (in time). But if one is
able to change the expire date, it doesn't really fit the job.
If the attacker has the private key, he can change the expire date and
make other (valid) signatures with the same key. Or am I still missing
something?

.TM.
--=20
      ____/  ____/   /
     /      /       /			Marco Colombo
    ___/  ___  /   /		      Technical Manager
   /          /   /			 ESI s.r.l.
 _____/ _____/  _/		       Colombo@ESI.it