Crypographically Strong Software Distribution HOWTO

Ben Laurie ben at algroup.co.uk
Tue Jul 3 14:36:18 EDT 2001


"V. Alex Brennen" wrote:
> In the case of such a large project, perhaps you could issue
> a separate role key pair to each developer and generate
> revocation certificates which are held by the core group for
> those keys. When a developer leaves the group, the revocation
> certificate for his key would be circulated.  Role keys could be
> identified by signatures from a "Master Key" in a traditional
> model (much like PKI), through the posting of a list of authorized
> keys digitally signed with a master key, or in an anarchistic model
> (which it sounds to me is what you're describing) by signatures
> from other core developers.  A threshhold could be established to
> consider a key officially certified for release, or a single signature
> could be acceptable.  Maybe this is what you're looking for, a model of
> authorization like PKI except that it is based in the model of PGP's
> decentralized web of trust?

I am, but I don't like the idea of "core developers" - you are merely
pushing back the place where you want a single key (or a well-defined
set of keys) - and I claim that is not a realistic plan. You have to
also allow the set of core developers to gradually change over time.

> Granted totally decentralized project like Apache cannot
> adopt the steps of the howto exactly as they are written
> with out altering their release model. However, such projects
> can make extremely beneficial use of third party testimonials,
> as the Apache Project does.  Third party signatures on releases
> could be distributed with the release and the third parties
> performing those signatures could be the core developers.
> Core developers are obviously in a strong position to speak
> about authenticity and content. While the use of core developer
> signatures as third party testimonials would make such a group
> slightly more vulnerable to trojan horse attacks via faked key
> pairs, this level of increased vulnerability is not (in my
> opinion) very significant.

Agreed.

> I think it would be good to see the Apache Project make a
> policy as to request (require) the signature of releases
> by the individual responsible for the release.  It would
> also be good to ask apache core members to generate new
> version 4 openPGP keys to replace older keys and continue
> to build the excellent web of trust that the group has
> established. The October ApacheCon in Europe would be an
> excellent time to integrate new version 4 keys into the
> Apache web of trust.

I'm not sure I understand the significance of this request - why are
version 4 keys better?

> Also, it would be nice to see the
> Apache group make its use of PGP signatures more prominent
> by posting a signature policy (if one is developed), and by
> linking to keys on a trusted keyserver as well as distributing
> them from the site so that new signatures are immediately
> available to people who wish to verify the testimonials of
> the core developers. Finally, perhaps the Apache Foundation
> would be willing to pick up the standards put forth in the
> HOWTO for files names of signatures?  Everyone is pretty
> much doing their own thing right now - I tried to pick up
> the most popular stuff for standards I put forth in the
> howto.
> 
> > So, you pretty clearly have to do something that allows multiple keys to
> > be used. It seems to me that the way to do this is to have tools that
> > manage a set of keys which may change over time. The keys sign each
> > other (the signatures would have to be tagged as signatures that allow a
> > particular software distribution to be signed) and the user trusts the
> > _set_ of keys, using the tools to check how keys get added and removed,
> > ensuring that appropriate signatures are on new keys, and that
> > revocations of old keys/signatures are checked.
> >
> > Organisations like the Apache Software Foundation can also have
> > cross-checking between sets of keys to reduce the pain of building
> > initial trust in a set of keys for a new piece of software from that
> > organisation.
> >
> > [...]
> >
> > It is a non-trivial task, so if anyone wants to help with it, please let
> > me know!
> 
> I've been working on code similar to what you're describing as prototype
> perl scripts which I intend to port to patches against GnuPG.  I'd be
> happy to help develop the tools necessary to allow Apache to embrace a
> strong distribution model more easily.  Further, I would be greatfull to
> have an opportunity to contribute to a project such as Apache.  Just let
> me know what you have and what you need.

OK, looks like a new project is about to be born. Apache guys: does the
ASF want to adopt this (given that the substrate is likely to be GPLed)?
Or shall I set it up on my servers?

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com




More information about the cryptography mailing list