Re: Secrecy and user trust

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

 



Jeff Spaleta wrote, On 09/04/2008 07:22 PM:
A really long email, read it here:
https://www.redhat.com/archives/fedora-list/2008-September/msg00523.html

0) Although it has been stated that the old fedora key's pass phrase was not used during the exposure, it is intimated that the soft version of the private key was available on the machine and could have been copied by the 'agent'. I, and I believe Bill & Bruno, see this as Someone other than authorized Fedora representatives have opportunity to have the pass phrase protected private key, and time to beat on the pass phrase, which means to us the key IS compromised.
You and a few others, give the appearance that this means nothing.


1) we agree that the best web of trust is generated when ALL of the parties have physically met and verified each other, i.e., 1 meeting for every public key I have, granted that's not a web.

2) we apparently do not agree that
(Assuming I like the way A and C verify the folks they sign for.)
if I met A and C and exchanged keys with them, and I get a public key for B that was signed by A and C in an email from B, then I can trust the key to be from B, and after some getting to know B, I might even be sane in accepting a key for D that was signed by B who I have still never met in person.

3) you apparently believe that RPM must be able to directly use these signatures.
I believe The extra signatures are for USERS to VERIFY _before_ feeding the DATA of the KEY to RPM.

Do I believe in our current climate (crypto education level) that a large percentage of Fedora users will take advantage of this out of band data? NO.
Will a reasonable percentage of those who need to use fedora (think support
for new hardware or and algorithms not yet in RHEL), and are supposed to use
due care|diligence in their job, take advantage of this out of band data? I
believe the answer to be YES.

4) So far the only signature on 0X4F2A6FD2 (the old key) that I have _some_ trust in is from 0xDB42A60E.

5) we both agree that a key that is JUST signed by random internet users who were not given the key data securely from the physical machine to be of little to no value.
However I may be under the mistaken idea that a few of the folks who
are community members, actually work and live very near Red Hat's brick and
mortar location.  And I could be under the further mistaken idea that a subset
of those might actually be willing to make the trip to get the key and begin
the web.
BTW, I consider many of the Red Hat employees to be part of the Fedora community.

6) you and apparently disagree that OUT OF BAND conformation of data has value. Where in band would be a signature RPM could use.

7) I believe communicating on this list and suggesting that I would like to see out of band data created, counts as 'talking' to some of the 3rd parties I would like to see sign the data. It appears in your message that you do not.

8) to answer the question of "Who should be the first to sign the key?":
SOME ENTITY IS USING THE NEW KEY TO SIGN NEW PACKAGES... CORRECT?
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01310.html
That entity would be the logical choice for _one_ of the first signatures
placed on the public key, even if _I_ don't have them as an ultimately trusted
source.

9) RE:
> At best we could maybe get the release engineering people who have
> direct access to the key to create detached signatures, <SNIP>
> Are those people in your web of trust?

Not sure, funny thing about a web of trust, a person knows a couple of other
folks and they intern know a few folks...
Oh and there the, very near the signing machine, persona of <security@xxxxxxxxxx> and <secalert@xxxxxxxxxx> which are probably already fairly protected by the policies of the company standing behind them.


10) RE:
>  We don't have
> a compelling reason to distribute those detached signatures as part of
> the fedora-release package which will contain the key.

Note that the only detached signatures which I ever suggest should be
distributed with the fedora-release package were of a Fedora master key
persona that does not YET exist.
Think about "PKI" a little bit,
is "GTE CyberTrust Global Root" Serial Number 01:A5 a person?
is "Akamai Subordinate CA 3" Serial Number 04:00:04:03 a person?
is "www.redhat.com" Serial Number 01:00:00:00:00:01:17:6B:14:92:65 a person?
we both know the answer is NO to all the above, and we both know that for the
persona "Akamai Subordinate CA 3" and the persona "GTE CyberTrust Global Root"
ultimately a (probably trust-able) person enters appropriate data under
appropriate rules to make the key available for the encryption system to sign
other data.
And we both trust it every time we go to https://www.redhat.com/archives/fedora-*

I am asking that the fedora project create a 'root' that will be protected
appropriately so it can be ultimately trusted into the future, so the PROJECT
can vouch for any other NEW keys they HAVE to distribute, so that the new key can be trusted AS SOON as it is made available. And I am proposing that it will, by the time it is needed, be trusted much as the keys we have for <security@xxxxxxxxxx> and <secalert@xxxxxxxxxx>, i.e., some have chains that go to the source, others will trust based on age and lack of complaints.


BTW infrastructure folks and J. Keating, I think you have been doing the best job possible. What you see in this message is my attempt at a discussion mostly over policy.

--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter

--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux