Crypographically Strong Software Distribution HOWTO

[Greg Broiles]

At 02:13 PM 7/3/2001 -0400, 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.

Because current systems don't, to my knowledge, allow the creators of 
revocations to specify the reason(s) for revocation, I wonder if it would 
be better to rely on short-lived keys or certs which are renewed frequently 
during a person's membership or association with a group.

Specifically, a revocation which does not distinguish between "stopped 
working on the project because very busy at new job" and "left laptop with 
private key on public transit" or "discovered installed rootkit on machine 
storing unencrypted private key" does not help people decide whether they 
can reasonably install old(er) distributions of a software package. If the 
package was signed by a person who is no longer participating as a 
builder/distributor, their key should not be current - but that doesn't 
mean that everything which has been signed with their key should be 
considered untrusted, as it would be in the case of a key compromise.

In particular, consider the example of a person who's the last within a 
group to maintain a port/build/distribution on a hard-to-find platform, who 
then leaves the group - it may be difficult to find someone else to replace 
them, so new builds may not be available - but software which was once 
considered working and "official" shouldn't lose that status because of the 
change in group membership.

Certainly, in the best of all possible worlds, everyone who installs 
software would have access to online CRL and CA resources, and we wouldn't 
need to think about whether or not a particular snapshot of reality is 
misleading in an especially optimistic or pessimistic way - but I believe 
we should not design (only) for that world.

In the absence of semantic information about revocations, I think that 
expiration is a more appropriate model where no compromise is reasonably 
suspected, and that revocation is a more appropriate model where compromise 
is suspected or asserted.


--
Greg Broiles
gbroiles at well.com
"Organized crime is the price we pay for organization." -- Raymond Chandler




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