Re: PGP signing releases - Mailing list pgsql-hackers

On Thu, 5 Feb 2003, Greg Copeland wrote:

> > > > > Who will actually hold the key? Where will it be physically kept?
> > >
> > > Good question but can usually be addressed.
> >
> > It can be addressed, but how well? This is another big issue that I
> > don't see any plan for that I'm comfortable with..
>
> The reason I was vague is because it depends on the key route.
> Obviously, if each person signs, each person must protect their own
> key.  If there is a central project key, it's simply a matter of
> determining which box is used for signing, etc...while important, it's
> certainly not difficult to address.

It seems to me extremely difficult to address. Unless you are physically
monitoring someone, how do you prevent someone from copying the key off
of that machine. At which point anybody with the passphrase can use it
for anything.

> > > > > How many people will know the passphrase?
> > >
> > > As few as possible.  Ideally only two, maybe three core developers.
> >
> > Um...I'm not sure that this is a relevant question at all. The
> > passphrase is not part of the key; it's just used to encrypt the key for
> > storage. If you know the passphrase, you can make unlimited copies of
> > the key, and these copies can be protected with any passphrases you like,
> > or no passphrase, for that matter.
>
> If you're concerned about this to that extent, clearly those people
> should not part of the web of trust nor should they be receiving the
> passphrase nor a copy of the private key.  Remember, trust is a key (pun
> intended) part of a reliable PKI.

In that case, I would trust only one person with the key. Making copies of
the key for others gives no additional protection (since it takes only one
person out of the group to sign the release) while it increases the chance
of key compromise (since there are now more copies of the key kicking around,
and more people who know the passphrase).

Keys cannot be transfered from one person to another since, being digital
data, there's no way to ascertain that the original holder does not still
(on purpose or inadvertantly) have copies of the key. So in the case where
we want to transfer trust from one person to another, we must also generate
a new key and revoke the old one.

This is now exactly equivalant to having each developer sign postgres
with a signing key (signed by his main key) for which the other
developers (or appropriate authority) have a revocation certificate.

And back to the passphrase issue, once again, can't you see that it's
completely irrelevant? At some point, someone who knows the passphrase is
going to have to be in a position to use that to decrypt the key. At that
point he has the key, period. Changing the passphrase does no good, because
you can't change the passphrase on the copy of the key he may have made.

A passphrase is like a lock on your barn door. After you've given
someone the key and he's gone in and taken the cow, changing the lock
gives you no protection at all.

cjs
-- 
Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.netbsd.org   Don't you know, in this new Dark Age, we're
alllight.  --XTC