Crypographically Strong Software Distribution HOWTO

Tue Jul 3 14:13:02 EDT 2001

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 3 Jul 2001, Ben Laurie wrote:

> What this does not address is the common situation where the
> distribution gets signed by a different person each time (example:
> Apache).

I had hoped the suggestion to identify a release master was sufficient.

Thanks allot for your input. You make very good points, and I'll
extend the next version of the HOWTO to cover this content.

> The obvious answer is "use a role key". This doesn't work - how does one
> control who gets it? How is it distributed? What happens when a
> developer leaves the group (the role key has to be revoked and we start
> all over again?)? You have to build a whole organisation around the key,
> which is unlikely to happen at all, let alone be secure.

In the case of small projects the role key could be shared,
distributed hand to hand on a floppy or sent through PGP
encrypted email. In the case of a large project like Apache,
this obviously isn't possible.

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?

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.

The howto is just a guide.  It is meant to be modified by
individual projects as they see fit. I don't see the model
you're describing as a barrier to adoption of a strong
distribution model on the part of the apache project.
In fact, the Apache Group seems to be using a strong
distribution model for most of it's releases now. I modeled
some of the content in the howto after the Apache practices.

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

Thanks,

	- VAB
- ---
V. Alex Brennen      <vab at cryptnet.net>
[ http://www.cryptnet.net/people/vab/ ]
[ http://www.advogato.org/person/vab/ ]
     C R Y P T O A N A R C H I S T

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Made with pgp4pine 1.76

iD8DBQE7Qgs2+pIJc5kqSz8RAmwiAKCSBoEZEEdExv77vgrY0r/drF5dpQCcDdL8
BxIZ4EqSmNb36eJGjxo00cY=
=gRvW
-----END PGP SIGNATURE-----

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