Re: PGP signing releases

On Wed, 2003-02-05 at 00:22, Curt Sampson wrote:
> On Wed, 4 Feb 2003, Greg Copeland wrote:
>
> > If three people are required to sign a package prior to release,
> > what happens when one of them is unavailable for signing (vacation,
> > hospital, etc). This is one of the reasons why having a single project
> > key which the core developers sign may appear to be easier.
>
> I don't see that it makes that much difference. So the release is signed
> only by, say, only three people instead of four. It's still signed.
>

Note that I said "appear to be easier", not that it actually is easier
an any meaningful way. Some of the more paranoid will look for
consistency from those that sign the package in question. The fact
different people sign may be the cause of additional footwork for some.
Which probably isn't such a bad thing. Nonetheless, it could be a sign
of alarm for a few.

> > > One hopes that situations like last week's "ousting" of one of the
> > > core FreeBSD developers are rare but if such a situation were to
> > > arise, a shared project key would be Very Bad (tm).
> >
> > If a revocation key has been properly generated (as it should of been),
> > this is not a problem at all.
>
> Actually, it is still a problem. Revocations are not reliable in PGP,
> and there's really no way to make them perfectly reliable in any system,
> because you've got no way to force the user to check that his "cached
> data" (i.e., the key he holds in his keyring) is still valid. This is why
> we generally expire signing keys and certificates and stuff like that on
> a regular basis.
>

When a package is released which has a new key signing it, revocation
should normally be found fairly quickly. This is especially true if
it's included in the package AND from normal PKI routes. Revocation
should accompany any packages which later follow until the key in
question has expired.

> This one element alone makes me think that individual signing is a
> better thing. (With individual signing you'd have to compromise several
> keys before you have to start relying on revocation certificates.)
>
> > > > 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.

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

> > One could also only allow a single person to hold the passphrase and
> > divide it into parts between two or more. This is commonly done in
> > financial circles.
>
> Hm. Splitting the key into parts is a very interesting idea, but I'd
> be interested to know how you might implement it without requiring
> everybody to be physically present at signing.
>
> cjs

I was actually talking about splitting the passphrase, however,
splitting the key is certainly possible as well. Having said that, if a
private key is shared, it should still be encrypted. As such, a
passphrase should still be considered; as will splitting it.

Regards,

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