Policy suggestion #. Re: non-disclosure of infrastructure problem a management issue?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff Spaleta wrote, On 08/25/2008 01:56 PM:

 Just assume we are starting from scratch because
how to handle this in a community sensitive way has never come up for
serious discussion.

-jef


Writing for MYSELF.

I would like to suggest something like the following item be placed in the new policy: There shall be an RSA [PGP|GPG] key which shall only used to sign other Fedora keys (a master key). This master key shall exist on removable media only [CD|DVD|Smart Card], and when not in use the media shall be stored in a safe place[1]. The Pass [Phrase|Key|Pin] for the master key shall exist on a different media [paper|removable media] in a different safe place[2]. The master key shall only be used in a machine that is not connected to a network. The machine the master key is used in shall not use swap space[6]. The machine the master key is used in shall be cold booted before use and powered down after use. The machine the master key is used in shall be under reasonable configuration control[7]. All new keys for fedora distribution, i.e., for rpms, security email, Fedora board members (limited to time of service key), shall be signed[3] with the master key. The master key shall only be used to sign, and if need be revoke[4], other keys. The public portion of the master key shall be included in|with other public keys[5] in all following fedora release media. {And there should be some statement as to who and when access should be granted for the key and Pass [Phrase|Key|Pin] }


The purpose of the master key:
So when we have an online breach or suspected breach, and want to distribute a new key for a purpose, the recipients of the new key have an old public key that because the master private key was kept off line, they can trust to distribute new keys. Secondary purposes, so that we can know for sure that it is THE fedora security key, or this persona is a board member persona.


The reason I am suggesting this:
Once I started _suspecting_ that there were POSSIBLY private key compromise issues in the current situation, I also realized I had no way to _immediately_ trust any new key, because of how the fedora keys are distributed. And yes I understand, that unless I somehow build a solid web of trust back to the Fedora master key, I would be still be taking a risk trusting the master key, but the lack of refuting evidence over time can at least build a cobweb of trust. And that cobweb of trust is what we have been running on with the fedora keys[8] for a long time, now someone has disturbed the dust.


[1] Right now some safe at Red Hat corporate HQ makes sense.
[2] probably still at Red Hat corporate HQ but a different safe???
OK, I am probably being a little nuts with this one, but at least not on the same media. [3] IIRC rpm has a problem working with keys that are signed, if this is still the case, then a detached signature should be used. [4] Been a while since I looked at 'web of trust' use. Can a master signer 'revoke' a key it signed? [5] such as in fedora-release-8-5.noarch.rpm, of course the new user should take a copy of this key to some non modifiable media at install time. [6] for a modern machine which is only doing key signing, swap space should NOT be NEEDED. [7] What is loaded on it? Who has used it? BIOS upgrades? TPM? Memory clearing procedures? Guard to make sure no copies are made? Whole system on a live cd?...

[8] actually MOST of us have been running on various cobwebs of trust for a long time... we have been trusting mozilla.org and microsoft.com to load trustworthy root certificates in our browsers with out us verifying them ourselves in some out of band fashion for over ~12 years.


--
Todd Denniston

--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux