At 02:34 -0700 on 10/15/97, Will Price wrote:
Adam:
...
I'm truly amazed that you would attack in such a spiteful fashion a simple
system which adds a recipient-requested, sender-approved extra recipient
which is end-to-end wherein all recipients are under the sender's control
and each recipient knows who can read the message with no key escrow using
the same old PGP message format we all know and love without change, and
yet you propose a much less secure system which allows hiding critical
information from the sender and does not adequately perform its stated
purpose of data recovery.
I don't see Adam's proposals as spiteful attacks. His proposed
alternatives may or may not do the job, but I believe they are honest
attempts to provide for corporate data recovery without enabling a greater
problem.
Enforcing encryption to a 3rd-party key, in addition to the intended
recipient's key, is bad.
Doing so makes GAK easier for a government or other attacker to manage, as
they'll only have to handle thousands of corporate recovery keys, not
millions of individual keys.
Doing so also provides easy hooks to mandate such access. In the USA, for
example, broadcast messages usually have no legal expectation of privacy.
Encrypting to a general recipient may cause messages to fall into that
category, and thus require no warrant for interception (but IANAL).
Doing so also opens up new avenues for illicit third-party snooping. With
enforced (or merely requested) encryption to 3rd-party keys, it may be
possible, depending on the implementation, to engineer a "man-on-the-side"
attack in order to snoop on message content. At the very least, it's
something else for an implementation to trip over.
Finally, doing so creates a higher value target key, the recovery key. An
attacker who can, for example, social-engineer the passphrase for that key
out of an executive assistant can thus achieve a greater payoff.
For those basic reasons, I would prefer to keep open-pgp simple. Perhaps
specify that conforming implementations must not enforce encryption of
messages to 3rd-party keys, but at the very least simply leave any kind of
specific 3rd-party key specification and enforcement out of the standard.
Richard