Proposal: Single GPG key per Fedora release (starting with 11)

[Toshio Kuratomi]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090420/5ee7f761/attachment.sig>