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

[Todd Denniston]

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