At 15:49 -0700 on 11/05/1997, William H. Geiger III wrote:
In <v03110702b086a28c9aa5(_at_)dolores(_dot_)scd(_dot_)ucar(_dot_)edu>, on
at 03:32 PM, "Richard Johnson" <rdump(_at_)river(_dot_)com> said:
It is not fear-mongering to request that the tags not even be defined
because they unnecessarily weaken the security of the standard.
How does having a request tag in the key weaken security?? The tag can be
used or ignored as the implementors see fit. No one is saying that you
MUST respect the request tag and no one is saying that you MUST generate
keys that contain such flags.
If only it were just a request tag. PGP Inc's SMTP policy enforcer turns
the "request" into more of a demand. It says, in its most strict
incarnation, 'encrypt to a 3rd party key we specify, or else your message
will not be allowed to reach the intended recipients.' (Given the tags in
the messages, if PGP didn't write such an enforcer, someone else would
Please, let's not place hooks that can easily be abused to require
encryption to 3rd party keys into the standard. Enforcement of such
requirements by software such as PGP's SMTP agent are all too real
possibilities (er, that exists already, doesn't it).
<sigh> the biggest "hook" for the type of abuse you are so fearfull of is
the ability to encrypt to multiple keys. The CMR tag is quite trivial
compaired to this. So are you willing to continue with your logic that
such "hooks" are to be avoided and call for a complete re-write of PGP so
this can be advoided??
The problem I'm worried about is _forced_ encryption to 3rd party keys by
senders who don't need or desire to encrypt to those keys, but acquiese
because their messages won't get through if they don't.
Here, we just differ by a matter of degree. Taking your point about
encryption to multiple keys being a "hook" a (large) step further, the
ability to encrypt to even a single key is a "hook" that should probably be
avoided if we want to keep attackers from having any chance of decrypting
Humor aside, I think capabilities that can easily be abused (and are being
abused?) to _require_ encryption to 3rd party keys do not belong in the
Such features offer a many orders of magnitude reduction of effort and
storage needs to a drift-net attacker who wants to decrypt a large number
of messages. Instead of having to obtain, sort and use thousands of
individual keys, the attacker will only need to steal (or legislatively
require access to) a single high value, long term recovery key.
Also, in a worst-case attack scenario where the adversary is a national
government (not necessarily your government...), it will certainly be
politically easier for them to require access to recovery keys, as a wedge,
than it will be to require access to all individual keys. Granted, either
could be achieved by a government, but the high value recovery keys will be
easier for them to both obtain and manage.
In other attack scenarios with fewer overtones of big brother (or big
French uncle), a high value, long term recovery key still reduces the work
that needs to be done by an attacker seeking to perform corporate espionage.
Message recovery, as implemented in PGP 5.5 with forceable encryption to
3rd party keys, is an unnecessary weakness in the message format that
scales too well for the attacker.
Instead, let's leave message recovery up to the implementors of
individual applications, as an added feature not part of the official
open-pgp standard. Those who sell into markets where such features are
desired can add them. The rest of the world will not have to be forced
to go along.
No one is forceing anyone to do anything here. No one is calling for MUST
CMR key generation, no one is calling for MUST CMR implementation, all
that is being requested in the spec is the definition of the CMR tag in
the key. If you don't like it don't use it!! I think this falls in line
with letting those who wish to implement message recovery to do so and
those who do not don't.
PGP Inc.'s SMTP policy enforcer shows quite clearly how use of the CMR keys
can be (and is being?) required. The tags should thus not be defined as
part of the official standard, as this leaves a wide opening (already being
exploited?) for forcing encryption of messages to 3rd party keys.
This unnecessarily weakens the security of the standard. Message recovery
can and should be done only for those markets that need it, in the clients
they run, to avoid forcing the rest of the world to share the increased
risk. Message recovery features thus need to be outside the open-pgp