ietf-openpgp
[Top] [All Lists]

Re: Just say NO to key escrow or CMR/ARR revisited

1997-11-05 16:04:57
-----BEGIN PGP SIGNED MESSAGE-----


In <v03110702b086a28c9aa5(_at_)dolores(_dot_)scd(_dot_)ucar(_dot_)edu>, on 
11/05/97 
   at 03:32 PM, "Richard Johnson" <rdump(_at_)river(_dot_)com> said:

At 13:25 -0700 on 11/5/97, Jon Callas wrote:
At 08:04 AM 11/5/97 -0800, mark(_at_)unicorn(_dot_)com wrote:
   I have no great problem with defining the neccesary flags and tags
   as 'implementation defined' so that non-CMR applications won't barf
   when they see them, but I certainly do not want to have to build
   snoopware into my applications in order to comply with the standard.

This is *PRECISELY* what my original suggestion was. I think this is why
some people talk about "fear mongering." No one has ever suggested anything
by just defining the tags, and leaving treatment up to the application,
except the fear mongers.



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.

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??

Also, use of "recovery" keys to which a large amount of traffic is
encrypted merely provides a high value key as a target for attack, by any
adversary, government or not.

Well then don't implement it. No one is calling for CMR to be maditory in
the specs. You don't like it don't use it.

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.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~whgiii
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html                 
       
- ---------------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: cp850
Comment: Registered_User_E-Secure_v1.1b1_ES000000

iQCVAwUBNGD6c49Co1n+aLhhAQFRewQAzV5dB+EtRwLsUEHEP34JwUa8C4NZCbPQ
+0QabYKSyjVlCd/OQ+vS1sRZXTfrOikinPbY3ZV5h+Ou1r+GELsV7wVizRbg3VCb
3xa+zwS8pQRzATQud43GEctc9WjNcPFlddsATqcy7Cyycszhs1MSGo8cor8nAszs
eR+2ISJbjXw=
=h9gy
-----END PGP SIGNATURE-----


<Prev in Thread] Current Thread [Next in Thread>