Re: [Rpm-maint] [rpm-software-management/rpm] rpm --import does not replace old keys with new keys (Issue #2577)
>> 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-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm --import does not replace old keys with new keys (Issue #2577)
> 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? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2577#issuecomment-1646649532 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm --import does not replace old keys with new keys (Issue #2577)
> Can you explain what you are thinking or worried about here? I'm not especially worried. It just sounds like a lot of work! But it sounds like you have already done the work, so there is no problem. > > Can you think of any use cases where this would cause a problem? > > Yes. If the new certificate is missing some components that the existing > version has, signatures that could once be verified may no longer be > verifiable. 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? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2577#issuecomment-1646600750 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm --import does not replace old keys with new keys (Issue #2577)
> @nwalfield, merging certificates sounds like a relatively hard problem to > solve in general. Can you explain what you are thinking or worried about here? The implementation to merge certificates in Sequoia [starts here](https://gitlab.com/sequoia-pgp/sequoia/-/blob/9e48a064/openpgp/src/cert.rs#L2592). We basically turn the two certificates into arrays of packets, and merge the two arrays. Then we [canonicalize](https://gitlab.com/sequoia-pgp/sequoia/-/blob/9e48a064/openpgp/src/cert.rs#L1519-2090) the result, which reorders and dedups the packets. I admit it is a few lines of code, but I think it is a stretch to say that it is a hard problem. > Can you think of any use cases where this would cause a problem? Yes. If the new certificate is missing some components that the existing version has, signatures that could once be verified may no longer be verifiable. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2577#issuecomment-1646546531 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm --import does not replace old keys with new keys (Issue #2577)
@nwalfield, merging certificates sounds like a relatively hard problem to solve in general. In this situation, if the user types ``` sudo rpm --import linux_signing_key.pub ``` then they probably just wants to replace the pre-existing key/certificate with the supplied one. Can you think of any use cases where this would cause a problem? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2577#issuecomment-1646543232 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
