But here is a 4th alternative that Tim May suggested:
""a standard that does not allow ""key recovery"" for Gov or Corp
as there
are other mechanisms (outside communications) to enable this.
I must admit I find ""key recovery"" as used in this thread for GAK
or CAK
in the context of e-mail correspondence, a misuse of the term as
was
originally coined, and that is, a means of obtaining user keys
from a
trusted repository after legal recourse.
It appears, from my reading of this thread, that PGP 5.5 would
allow sender
to also encryt copies to Gov or Corp with or without sneder's
consent or
the consent of the recipient depending on the mail security
policies of
their respective organizations.
This, to me, is a new and disturbing twist on ""key
recovery/escrow""
David Gaon
______________________________ Reply Separator
_________________________________
Subject: Time to move on
Author: iang(_at_)systemics(_dot_)com [SMTP:iang(_at_)systemics(_dot_)com] at
DISAHUB
Date: 10/15/97 10:30 AM
( Quick summary: two contrasting implementations should
advance, outside Open PGP. Open PGP should standardise
the base. Else we'll stall and lose everything! )
We seem to be reaching a new phase in the debate.
There appear to be three possibilities currently circulating:
* PGP Inc-sponsored designs to achieve various customer-
demanded recovery features, as typified by their 5.5
product. These include SMTP policy enforcers and
protocols for communicating warnings and requesting
certain key encryptions, so as to ease the
incorporation of corporate recovery options into large
sites.
* Alternative designs by a cartel led by Adam that seek
to minimise the potential for a GAK attack on any
infrastructure that is built up.
* A base implementation that neither promotes nor impedes
either of the above.
Perhaps the new phase is characterised by exhaustion, or by
battle lines firmly drawn, but for all the efforts put in to
the debate, it would appear that no consensus approach to
data recovery has arisen. So, assuming that if we haven't
by now made everybody in the world happy together, we might
start thinking about strength (and happiness) through
diversity.
As many have pointed out, the Open PGP standardisation
effort should naturally lag behind the implementation of
various companies or cartels. Indeed, where there is
dispute, and competing but potentially incompatible
variants, then there is a need to encourage experimentation
within the market place in order to determine which way
standards should go.
The Open PGP standard needs then to support the competing
implementations without prejudice. It must therefore provide
a base standard that permits additional modes, such as the
space for extra flags, but does not define the behaviour of
such flags so as to not impose any limits on them.
If later implementations succeed in showing that these flags are
beneficial then proposals can be made to add them. There also is
more value in a base implementation that gets out quickly than a
"complete" implementation that takes a long time.
I am also increasingly concious of the need to keep everyone
on board here. If we do develop a rift within the community,
there is some degree of danger that the standard will stall.
Now, this is the worst scenario for all of us, as it will sound
the death knell for an strong independant email standard.
Other efforts have faltered. What we are trying to do within
this standards process is shown therefore to be very difficult.
Remember that just the process alone of developing an RFC is
long and tortuous, and consequently requires a lot of effort.
Some people and companies are willingly providing this effort;
we need to ensure that these efforts are not disenfranchised.
Both the alternate implementors have signalled their willingness
to pursue their philosophies, and this can best be done and
debated outside the Open PGP forum, within other more development
oriented groups. As long as we are agreed that the Open PGP
standard does not in any way impinge on either variant, then we
can get on with the really important task of producing the RFC.
iang
PS: see also TCMs post.