Jesse Keating wrote: > On Mon, 2009-04-20 at 17:15 -0700, Toshio Kuratomi wrote: >> Would it make sense from a security and release standpoint to still have >> two keys but to divide their use differently? >> >> Key 1 is for beta/preview/release. >> Key 2 is for updates-testing/updates. >> >> It seems like this would prevent most of the churn surrounding resigning >> since the resigning happens between packages from (beta => preview => >> release) and (updates-testing => updates) rather than (release => updates). >> >> It would also mean that we could create a revocation certificate for Key >> 1 and then delete the private key after beta/preview/release. That >> would limit the time a malicious party could compromise the key used to >> sign rpms on media and in the release tree which seems like it would >> give us a better chance of having a known good base should we ever be >> faced with distrusting packages that made it into our repository. >> >> Security is hard, though, so maybe someone can point out an error in my >> thinking :-) > > RPM et al doesn't yet understand revocation certs, so that isn't going > to help you much there. Yeah, the revocation cert is so we can revoke it from any key servers. Nothing rpm related. Other than that, since we'll be using new keys > each release, I'm not even sure how much added value there would be in > using two different keys. > The added value is that once the release was cut, the key for the release would no longer be able to be stolen. So that cuts the window of vulnerability. But it only cuts the window a maximum of 13 months: * Anytime before the release, the key could be stolen in either scenario. A key stolen in this way could be used to compromise the initial release after the release is cut (1) With a single key, from release to 13 months out, the key could be stolen and potentially be used to inject bad packages into either the release or updates tree. (2) With two keys, from release to 13 months out, the key to the updates repo could be stolen and used to inject bad packages into the updates repo only. The release repo would be safe. Related thoughts: For us to trust the release repo and only rekey the updates repo, we'd need to know the time that a key could have been stolen. If we couldn't determine that, we'd want to rekey both repos just to be safe. The release repo is easier to verify (at least in part) than the updates repo because we generally have media that we can compare against for at least part of the package set. -Toshio
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
