Re: PGP signing releases

On Wed, 2003-02-05 at 18:53, Curt Sampson wrote:
> 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.
>

This issue doesn't change regardless of the mechanism you pick. Anyone
that is signing a key must take reasonable measures to ensure the
protection of their key.

> > > > > > 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).
>

Which brings us back to backups. Should the one person that has the key
be unavailable or dead, who will sign the release? Furthermore, making
*limited* copies of the key does provide for additional limited
protection in case it's lost for some reason. This helps mitigate the
use of the revocation key until it's absolutely required. Also provides
for backup (of key and people).

Basically, you are saying:
You trust a core developer
You trust they can protect their keys
You trust they can properly distribute their trust
You don't trust a core developer with a key

Hmmm...something smells in your web of trust...So, which is it? Do you
trust the core developers to protect the interests of the project and
the associated key or not? If not, why trust any digital signature from
them in the first place?

Can't stress this enough. PKI is an absolute failure without trust.
Period.

> 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.
>

No one is talking about transferring keys. In fact, I've previously
addressed this topic, from a different angle, a number of times. We are
talking about shared trust and not transfered trust. The transferring
of trust is done by signing keys, not transferring keys.

> 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.
>

So you trust the core developer to sign the package but you don't trust
him to have the key that's required to sign it? You can't have it both
ways.

> 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.

I can assure you I fully understand the implications and meaning of
everything I've said.

--
Greg Copeland <greg(at)copelandconsulting(dot)net>
Copeland Computer Consulting