ietf-openpgp
[Top] [All Lists]

Re: PGP CAKware & IETF controlled Open-PGP standard

1997-10-12 13:23:06
Adam, one aspect of your suggestion puzzles me:
        One thing which concerns me most is KNOWING when a message I send
(or receive) could be read by someone else. The PGP CMR scheme makes this
very clear: if there is an extra CMR key, the message may be read by
whomever controls that key, if not, only the recipient may decrypt the
message.
        If, however, the message is secretly re-encrypted to a corporate
storage key AFTER it is received, I will never know that.

The reality is that:
        1) Organizations have a legitimate need to recover information. You
can argue about this as much as you want. A great many organizations will
simply NOT INSTALL systems which do not accommodate this. If businesses,
law firms and many other organizations will not use PGP, we will not have a
viable standard.
                We need to find ways to satisfy this need which are as
flexible as possible, which are easy to use and administer, which balance
the rights of the individual against those of the organization, and which
do not mislead people inside OR OUTSIDE of the organization.
        This means, I believe, that they should NEVER INVOLVE HIDDEN BACK
DOORS THAT USERS ARE NOT AWARE OF.
        It also means, I believe, that we should provide systems which
provide as much flexibility and granularity as possible, and which do not
require a central key recovery infrastructure -- or, even worse, a
"trusted" third party key recovery infrastructure.
        2) Handling privileges, access and policies is going to get very
sophisticated and very complicated.
                The keys need to be flexible enough to contain the kinds of
information people are going to want to put in them. But I believe that
most of the agents which make use of this information will operate at the
server level, not the client level.

PGP Inc. has tried to work through these issues in a new way. I think that
we have agonized through a lot of trade-offs and come up with something
that will really work -- and work well.
        There is always the danger that someone is going to use your tools
in ways that you do not approve of. We are trying to make it as easy as
possible for people to do the "right" thing, and to discourage them from
doing the "wrong" thing (like secret snooping).
         With regard to GAK, the objective should be to accommodate
legitimate corporate needs without setting in place the foundation for GAK.
We have tried very hard to do this by creating the foundation for a highly
flexible and decentralized approach which allows different organizations to
do things in very different ways. We have also tried to keep everything
very visible so that every party to a conversation knows exactly how
"private" that conversation is.
        I think that the sort of thing that PGP Inc is doing is the best
defense against GAK. It knocks the pins out from under the argument being
used in this country that corporate message recovery requires a key escrow
infrastructure, and will almost certainly lead to a wide variety of
organization-specific implementations that will be jealously guarded and
very difficult to corral. I cannot imagine your 80% scenario working in the
U.S. where there are so many small and medium-sized organizations and so
much concern about government intrusion. I do worry a little more about
countries like France, but I have yet to see any guaranteed "safe"
alternative (including yours) that the French Government is likely to
accept.
        I am very interested in seeing criticism and suggestions for
improvement and would like to see this discussed and debated as openly as
possible. In particular, I would be interested in how one could reconcile
your scheme of separate transmission and storage keys with my concern that
everyone party to an exchange always be informed about who might be able to
read that exchange.

However, I think that some of this discussion should be separated from the
Open PGP discussion. NO ONE wants to build any sort of mandatory message
recovery scheme into the base Open PGP specification. PGP Inc itself is
committed to always providing a base client software product which does not
implement message recovery keys.

In the end, the issue we need to focus on is what should go into the Open
PGP specification. There are going to be many different organizations
(including PGP Inc.) which build different implementations and services on
top of this.
        The key structure needs to be flexible enough to accommodate all
kinds of uses we cannot now envisage. Yes, I believe that CMR keys should
be supported -- as should a lot of other things we need to talk about.

Finally, let's dispense with the non-productive PGP Inc- bashing. We
founded this company to take something which was going to die because it
had no company behind it, and push it forward. PGP Inc was the first step
in that process. Open PGP is the next step.
        Most companies are very ambivalent about "open" standards. Most of
the time, "open" to them means something which they control and everyone
else adheres to. PGP Inc, on the other hand, is very committed to the
spirit of open standards. We understand very well that we will only be
successful if there is an open and completely interoperable international
standard.
        I also want to assure you that all of the things we do get
extensively debated within PGP. Thus far, we have always been able to work
out consensus decisions which, I believe, are more sophisticated and better
thought-out for that debate. In all of this I have never heard ANYONE at
PGP Inc. suggest that the company add any feature or capability to the
software in order to appease any government agency. GAK is just as scary to
us as it is to you.
        Nor has there ever been any any "shareholder pressure" for any
feature or set of features. Everyone who has invested in this company knows
what we stand for.

        Jonathan Seybold
        Chairman, PGP Inc.

BTW: PGP Inc. currently employs NO "PR flaks." Press releases are usually
drafted by the people directly involved in the product or project and
reviewed informally by anyone else who would like to contribute.