On Tue, 14 Oct 1997, Hal Finney wrote:
You do a good job of saying what you want to avoid, but not much about
what you want to accomplish! You are doing this to satisfy some kind
of market need for commercial access to data. What are the requirements
your design will satisfy? What do the customers need? You can't design
a system based solely on what it doesn't do.
PGP, Inc. has made its design choices based on interaction and discussion
between people responsible for security, human interface, sales/marketing
and customer support, as well as the customers themselves. The lessons
which have come out of this include an emphasis on solutions which
people can use and which will work in the field. This means they have
to be transparent, easy to learn, fit into existing procedures, and
be reliable, as well as being secure. Systems which require extensive
retraining, new operational procedures, or which will hurt reliability
are not acceptable - they simply won't be deployed. That's the reality.
One thing PGP has not looked into would be having a master key such that N
bits will be the same from the corporate master key to any user's key.
Then you could recover any user key from the corporate key, but it would
requrire some expense and effort, so it would prevent casual
eavesdropping by the administrators.
A second method would require N (typically 3) escrow keys to recreate the
access key, and would work best if it only decrypted one user's messages.
I would rather not trust a single party within a corporation.
Right now, whoever has the corporate key can read everyone's email. What
happens when there is an insider trading lawsuit when the CIO reads the
CEO's "private" email? I can think of other examples. And if the
corporate key is compromised, I assume that compromises every piece of
email up to that point?
But let me ask a question about PGP, Inc. - Do they use the PGP 5.5
version with corporate key recovery internally?