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

> 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

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


Greg Copeland <[EMAIL PROTECTED]>
Copeland Computer Consulting

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

Reply via email to