Time to resurrect multi-key signatures in RPM?

[Jim Wildman]

Nils Philippsen wrote:
> On Thu, 2008-08-28 at 20:07 +1000, Bojan Smojver wrote:
>> On Thu, 2008-08-28 at 10:49 +0200, Nils Philippsen wrote:
>>
>>> Just about every bank in Germany would operate like this. After all, we
>>> do have a national ID that is hard enough to fake(*) and if you present
>>> it to entities like banks, they usually make a copy and can verify the
>>> data on the ID with the "Einwohnermeldeamt" (possibly "residents
>>> registration office").
>> In other words, they only marginally trust that ID card. Therefore, they
>> cross-check with the office (but most likely NOT the person that issued
>> the card) that what is on that document is ACTUALLY true.
> 
> I don't know if they do that at all or with everybody, in fact I'm
> pretty sure they will accept the IDs at face value. Maybe they verify
> old documents that don't have all the gizmos that make the ID hard to
> fake today. I just wanted to point out that they can do that.
> 
>> Think of the card as the RPM coming out of Fedora build system, signed
>> with Fedora key (i.e. all the hard to get paraphernalia that the card is
>> made of). Think of the phone call to the office as a comparison to an
>> independently built RPM. Think of the act of opening the bank account as
>> an independent signatory signing the RPM.
> 
> All this doesn't help much if somebody manages to feed the process with
> corrupt data in the beginning -- be that a fake ID when applying for
> replacement for an expired ID, or somebody corrupting the repository
> that keeps the source that is fed to the builders. Besides the
> difficulties in making distributed build verification work solidly, we
> have to harden the system/process that feeds the builders in the first
> place -- which is already much easier than say hacking the builders.
> Otherwise it's just GIGO, all pain and no gain.
> 
> Nils

It is (almost) all about process.  Documented, auditable, verifiable 
process that is reviewed periodically by someone other than those using 
it to make sure it is in fact being followed, verified, audited, etc.

In a sense, fedora and rht just had a hostile audit.  They failed.  Now 
close the feedback loop and use what you've learned to fix the process. 
  New keys are nice, but ultimately useless w/o a better process to 
safeguard them, to ensure their correct usage, by the correct people on 
the correct content, and to enable their revokation if it happens again.

As Schneirer says, good security is hard.  This is not a new path, 
nothing needs to be invented, just some good solid principles 
(separation of duty, verification of trust, independent review and 
audit, etc) followed.

Apparently, there was not enough process in place, or the processes that 
were in place were not followed, or they are (hopefully were) the wrong 
processes.

-- 
----------------------------------------------------------------------
Jim Wildman, CISSP, RHCE       jim at rossberry.com http://www.rossberry.com
"Society in every state is a blessing, but Government, even in its best
state, is a necessary evil; in its worst state, an intolerable one."
Thomas Paine