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

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


On Tuesday 04 February 2003 9:15 am, [EMAIL PROTECTED] wrote:
> There are generally two ways to do it: have a "project" key, or have
> each developer use their own key. The advantage of the first way is
> that each release is signed by the same key, which is clearly
> associated with the project. The disadvantage is control, security,
> and accountablility. The second way pretty much reverses the
> arguments: each key is controlled by one person, but there is no
> obvious mapping between that person and the project. Individual keys
> also have a history associated with them, and are usually already
> integrated into the Web of Trust.
> Many projects use the individual method, including Apache, GnuPG, and
> OpenSSH. Some use the project method, such as sendmail and proftpd.
> Either is okay with me, but some questions need to be answered if
> using a project key:
> Who will actually hold the key? Where will it be physically kept?
> How many people will know the passphrase?
> Who will be responsible for signing the files? Is there a backup person?
> Will it be a signing-only key? What size? Should it expire?
> How is verification of the files before signing accomplished?
> I've got some ideas about most of those, especially the last two. This will
> not be that easy of a process, but on the other hand, new versions do not
> appear very frequently, and it is important to get this right the first
> time.

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Reply via email to