cryptoanarchy.wiki

Arise, you have nothing to lose but your barbed wire fences!

1995-02-10 - Re: why pgp sucks

Header Data

From: “Perry E. Metzger” <perry@imsi.com>
To: cypherpunks@toad.com
Message Hash: cb86d719fdf47bbda552f5029cc4f85b713b0e81e94db77acfae893cd9a0f9ca
Message ID: <9502101958.AA15039@snark.imsi.com>
Reply To: <199502101951.OAA28877@crypto.com>
UTC Datetime: 1995-02-10 19:58:46 UTC
Raw Date: Fri, 10 Feb 95 11:58:46 PST

Raw message

From: "Perry E. Metzger" <perry@imsi.com>
Date: Fri, 10 Feb 95 11:58:46 PST
To: cypherpunks@toad.com
Subject: Re: why pgp sucks
In-Reply-To: <199502101951.OAA28877@crypto.com>
Message-ID: <9502101958.AA15039@snark.imsi.com>
MIME-Version: 1.0
Content-Type: text/plain



Matt Blaze says:
> PGP suffers from its failure to separate cleanly its primary
> mechanism (encrypting and signing messages) from policy (what to
> do with those signed and encrypted mechansims).  Without a clean
> separation, the mechanism is limited to use in those applications
> narrowly envisioned by the system's authors.
[...]
> Personally, I'd much rather see a suite of tools: an encryption/signature
> tool (or maybe tools - let me apply them in whatever order is
> approprate), a decryption verification tool, a certificate management
> system that operates on messages signed with the signature tool and a
> top level that glues all this together and implements local policy
> (like what consitutes a valid signature, key revocation, etc).  If
> we had a system that worked like this,, we could more easily create
> richer key certificates that specify restrictions on what is being
> signed, revocation conditions, etc.

I've been saying this for a long time, and I want to triple-reiterate
it -- PGP needs to be broken down into simple Unix-philosophy style
tools, or it isn't going to be useful in the long run.

I'll also note, yet again, that unless PGP quits this bad practice of
identifying counterparties only by a number, it is NOT going to be
universally deployed. Counterparties need to be identified by a name
that can be looked up in the DNS -- meaning "joe@foo.com" rather than
some key ident number.

Perry

Thread