>> I suppose there might be some situations where that is helpful. But it
>> sounds dangerous as a default behaviour. Old keys would never get retired /
>> revoked. This could leave users vulnerable to attack. Otherwise, what's the
>> point of rotating keys?
>
> I see. If I understand you correctly, you're suggesting that the old
> component would be dropped. Are you suggesting that people resign their old
> messages when they retire an signing subkey (that sounds like a lot of work)?
> If not, how would a third party verify an old signature?
Yes, I think the old component should be dropped by default.
No, I don't think old packages should be re-signed by the new key. Rather, I
think that the key master ought to keep old keys inside the certificate unless
they want to revoke it (e.g. due to an attack). The old keys would still have
expiry dates, so RPM would complain about old signatures -- but this can be
overriden.
To reiterate, I think the common scenarios would be one of:
1. The key master keeps a long history of keys (as subkeys) inside the
certificate. This is what Google does.
2. The key master publishes keys with separate certificates, so they can be
installed simultaneously. I think this is the more common practice.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2577#issuecomment-1646670658
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/issues/2577/1646670...@github.com>
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
