Comments intermixed below. On Tue, 2003-02-04 at 12:04, Steve Crawford wrote: > Having just started working with GPG I shouldn't be considered an expert but > it seems to me that each core developer should create a key and should > cross-sign each others' keys to form a web of trust to verify the
This is a good idea regardless as which "key" approach is used. Being able to reliably trust a key is only as strong as the associated "web of trust." > authenticity of those signatures. In any case, I think that if > security-related projects like GnuPG and OpenSSH use the individual method > then it wouldn't be a bad idea to follow their lead. > There are pros and cons associated with each approach. Neither is really better IMO. 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. > One hopes that situations like last week's "ousting" of one of the core > FreeBSD developers > (http://slashdot.org/article.pl?sid=03/02/03/239238&mode=thread&tid=122&tid=156) > 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. The revocation key is quickly shot over to the known key servers and included with the newly generated project key. As people add and confirm the new project key, the old key is automatically revoked. Again, if this is properly handled, it is not much of a problem at all. PKI, by means of revocation keys, specifically addresses this need. > If I understand GPG correctly, one can create a "detached signature" of a > document. As such, any or all of the core developers could create and post > such a signature and a user could verify against as many signatures as > desired to feel secure that the file is good. > > Cheers, > Steve > IIRC, PGP and GPG both support detached signatures. > > > > Who will actually hold the key? Where will it be physically kept? Good question but can usually be addressed. > > > > How many people will know the passphrase? As few as possible. Ideally only two, maybe three core developers. 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. The exact details will be mostly driven by the key approach that is picked. > > > > Who will be responsible for signing the files? Is there a backup person? > > This is important to make sure that any backup people are properly included in the "web of trust" from the very beginning. > > Will it be a signing-only key? What size? Should it expire? > > Keys should always expire. If you want to allow for one year, two year, or even maybe three years, that's fine. Nonetheless, expiration should always be built in, especially on a project like this where people may be more transient. > > How is verification of the files before signing accomplished? > > The person creating the initial package release should also initially sign it. From there, the web of trust for the people signing it can work as designed. Once the initial package has been generated, it should not leave his eyes until it has been signed. Regards, -- Greg Copeland <[EMAIL PROTECTED]> Copeland Computer Consulting ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
