FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.

» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora User

LinkBack Thread Tools
Old 08-25-2008, 10:50 PM
Todd Denniston
Default Policy suggestion #. non-disclosure of infrastructure problem a management issue?

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.


Writing for MYSELF.

I would like to suggest something like the following item be placed in the new
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
[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
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Thread Tools

All times are GMT. The time now is 04:14 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org