[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PGP CAKware & IETF controlled Open-PGP standard
-----BEGIN PGP SIGNED MESSAGE-----
In <[email protected]>, on 10/11/97
at 02, Adam Back <[email protected]> said:
>Jon Callas <[email protected]> writes:
>> I am adamantly opposed to any of PGP's business features being MUST
>> features of OpenPGP. If they were, then our freeware and personal
>> privacy products wouldn't be conforming applications, and we have
>> *no* intention of putting them in those products. Wouldn't that be
>> an interesting situation?
>I may be misunderstanding something here, but could you tell me how PGP
>freeware and PGP personal privacy can simultaneously not have recognition
>of GAK compliant keys, and emit messages telling the users that this is a
>GAK key (on receipt of the flag you described), and emit messages warning
>the user that the email will not be delivered (on receipt of that other
>flag you described).
I didn't see where Jon said that the other versions versions of PGP would
not recognize these keys. What Jon did say is that they would not generate
these keys nor force compliance with encryption to a second key. I myself
would want to know that a message encrypted with key A is also being
encrypted with key B though haveing this info in the public key itself is
not necessary.
>If it's defined as being compliant to ignore both of these flags, and the
>message snooping key then users email will bounce without warning.
I don't see this as a problem. My Twit/SPAM filter bounces messages
without warning. As a matter of fact most bounced messages are done so
without warning. :)
>If it's defined to silently send to second crypto recipient, you have
>fully interoperable GAK compliance built in to the core of PGP. If PGP
>Inc will remove the GAK compliance when GAK becomes mandatory, I'm sure
>there are other companies who won't have a problem selling out to GAK (eg
>IBM, or TIS).
This is a stereotypical Strawman. "Even if PGP avoids GAK some other 3rd
party can modify it to be Gakware." Every version of PGP had the ability
to encrypt to multiple recipients. As I stated in my previous posts I can
get PGP 2.6.x to do everything 5.5 does with a couple of scripts. Are you
no willing to take the position that ALL versions of PGP are GAK
compliant???
>If it's defined to warn but give the option to send to second crypto
>recipient, well you've still got mandatory GAK compliance, but you've got
>a pretty little warning that you've got mandatory GAK to rub your nose in
>the fact for each message you send too.
No this is not mandatory GAK compliance. Mandatory GAK compliance would be
if every copy of PGP came with a government key and the program *forced*
the user to encrypt all his messages with it. This is really turning into
a shameless FUD campagne on your part Adam worthy of David "FUD"
Sternlight himself.
>> I am strongly opposed the business features being SHOULD features. If I
>> were the only one arguing against them being SHOULD features, I'd make my
>> opposition clear and then shut up.
>>
>> I am in favor of them being MAY features, along with a big section on
>> polite use.
>I'd be interested to see some discussion of how this will work out,
>following up to the specific examples I give above.
>No switching to genaralities this time; please answer: how is it going to
>work? I fear you can't have your CMR setup in pgp5.5 and not be GAK
>compliant. If you can think of a way that you can modify it to break
>this dependency, I'd be interested to hear it. If you can't demonstrate
>such a change I would argue strongly for it not even being a MAY. I'd
>argue for GAK compliancy not to go into the IETF OpenPGP standard.
As far as I am concerned you have not proven your case that PGP 5.5 is GAK
compliant. Your general argument that PGP 5.5 has the potential to be GAK
can cover *ALL* version of PGP. Any system that allows encrypting to
multiple recipients can easily modified into a GAK system.
>I gave lots of examples of other ways to achieve the claimed
>functionality of recovering stored data. Achieving hard to circumvent
>corporate email snooping functionality is harder to achieve without CMR.
>You can do some, but not quite as much. But corporate snooping wasn't on
>your stated list of user requirements. And it's not very savory anyway.
I think this is your real issue here. You don't like the ideal of a
company haveing access to their documents. If that's how you feel then
make your case so it can be judged on it's merits.
- --
- ---------------------------------------------------------------
William H. Geiger III http://www.amaranth.com/~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://www.amaranth.com/~whgiii/pgpmr2.html
- ---------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: cp850
Comment: Registered_User_E-Secure_v1.1b1_ES000000
iQCVAwUBND8Nko9Co1n+aLhhAQEdsQP+JD99L79r4aGkc4GEj4S0rOzbt5aadkQP
GPaERGoRCB3cn9ms0crNRc6JUNmjVEBff/48zMzAH9reeaDhtqZadmW9CrVZIMle
VrOa9A+wqZjuNdFiSLE+5ygyeJ+WN0ofqUluCzUa5dgg2eAVHU4MRzWvRuREkjuN
nRWB6mhCt0g=
=s4jP
-----END PGP SIGNATURE-----