From: Adam Back <aba@dcs.ex.ac.uk>
Date: Sat, 11 Oct 1997 10:39:09 +0800
To: jon@pgp.com
Subject: Re: PGP CAKware & IETF controlled Open-PGP standard
In-Reply-To: <3.0.3.32.19971010145005.00a32360@mail.pgp.com>
Message-ID: <199710110154.CAA06536@server.test.net>
MIME-Version: 1.0
Content-Type: text/plain




Jon Callas <jon@pgp.com> 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).

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.

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).

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.

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

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.

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`