Re: PGP CAKware & IETF controlled Open-PGP standard

-----BEGIN PGP SIGNED MESSAGE-----

In <6661.wsimpson@greendragon.com>, on 10/10/97 
   at 10, "William Allen Simpson" <wsimpson@greendragon.com> said:

>I'm getting a bit tired of the rants on this topic to the Open-PGP list. 
>Yes, there are problems, but the whole purpose of IETF review is to find
>solutions to problems.

I agree, I think the political debates can be better handled on the CP
list rather than here. In that light I have created a PGP 5.5 digest that
covers the various threads on this topic from the CP list, the open PGP
list and the PGP Users lists (for the neswgroups you are on your own). I
will also provide a daily digest as long as these threads continue
(cut-off time 5pm central time zone). Anyone wishing to receive a copy let
me know (digest, daily, or both).

>The PGP staff have some ideas on how business message recovery can be
>done.  It seems there is a business need.  It seems that they have
>thought about it, and made some effort toward implementation.

>What annoys me is that the PGP formats are now supposed to be "open", yet
>no proposed formats for this new "feature" have been documented for our
>review, and other folks' suggestions for a better K-of-N mechanism have
>been ignored.

>We don't even have the current formats.  When will the PGP 5.0
>internet-draft be ready for review?

>There is already a PGP 5.0 separation between signing and
>communication keys; why not have separate message storage keys?

>Why not have a K-of-N system for BMR?

>Why have a communication enforcement filter, when the only usage is
>supposed to be for recovering archival storage?

>Let us decide _what_ the goals are, _how_ to solve the problems, and
>_then_ decide the protocol details and formats to match the solution.

An excellent suggestion. Perhaps you could detail your ideals on these
areas so we can work on them.

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

iQCVAwUBND8W+o9Co1n+aLhhAQEW2wP/Ya18Xh44vRqsy/5uhPLeprw8C9z+MgWE
MOdoRrKq8BvkCA9qoCEpm6bmFajR18IcvkEE1rurEV69yehpi0/YfYOQ4adntiEd
xTIQ8OLpQ6DMion7FauBb9Y1/XeKef/jOqddlM4qmgUswpkzMA7RMdaHoL7yrLI+
jGjJnD6qmKk=
=KxW9
-----END PGP SIGNATURE-----

William Geiger wrote:

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

Yes, but as Adam says, the average Mr. Windows can not. In any case,
this is not a narrow technical argument. Of course any system with
multiple recipients can be turned into GAKware. The point is that we
don't want to make it ANY easier for anyone to do so.

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

Again, as Adam says, how long would it take for a government to
introduce legislation making this mandatory once PGP 5.5-type systems
took off? Or, more insiduously, using its purchasing power - "Federal
agencies will only buy CAK-enabled systems" - to ensure the vast
majority of systems did so.

> Ok Adam here is a challenge for you:
> 
> -- Explain why Corporations do not have the right to access *their*
> documents in whatever form they may be in.

Can I take this one up ;-) The point is, with *communication* keys,
corporations will have full access to the plaintext because it will be
decrypted by the recipient as soon as it arrives. I appreciate your
point about corporations being able to read *their* documents - although
doing so by snooping, without the sender's knowledge, is rather
unethical to say the least - but I don't think they have the right to
snoop on all *incoming* communications, whoever they may be from. This
is the really scary part of PGP 5.5...

> explain why there were no great outcries that PGP 2.6.x is
> GAKware???

...because PGP 2.6.x does not include an SMTP automatic snooping agent.

William Simpson wrote:

> Let us decide _what_ the goals are, _how_ to solve the problems, and
> _then_ decide the protocol details and formats to match the solution.

Absolutely. Can we start with Adam and William's proposal that we should
have three separate types of key: communication, signature, and storage.
This would be very simple to implement; probably the easiest and most
backward-compatible way would be to define a new packet type specifying
a key's usage. 

> Why have a communication enforcement filter, when the only usage is
> supposed to be for recovering archival storage?

Absolutely. I can see the point, and appreciate the difficulties faced
by PGP Inc., in most of the CAK features of PGP 5.5. But I just can
*not* see how the twisted idea of the SMTP snooper ever came about.

Ian.

Ian Brown <I.Brown@cs.ucl.ac.uk> writes:
> William Geiger wrote:
> 
> > 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.
> 
> Yes, but as Adam says, the average Mr. Windows can not. In any case,
> this is not a narrow technical argument. Of course any system with
> multiple recipients can be turned into GAKware. The point is that we
> don't want to make it ANY easier for anyone to do so.

Agree.  What I am proposing is to make GAK enabled systems
non-interoperable with the OpenPGP standard on the sending end (ie to
define that when you receive a message it won't dictate to you that
you should use GAK compliancy, and to define that if flags indicating
message snooping is ocurring this won't be enforced by your mail being
bounced if you don't, and won't be implemented with encrypting to a
special snooping crypto recipient).  What PGP is proposing with PGP
5.5 is to implement enforcement on end users to send to GAK (or
corporate snooping) enabled keys using the snooping key.

They claim that it's ok, because the user is empowered, as he can
override the sending to the snooping key.  But, if you enable the
sender of a message you receive to state (in syntax defined as part of
the OpenPGP standard, or even if it is not) that if you don't encrypt
to this corporate snooping key (or technically equivalent
functionality: government GAKking key) the message will bounce, how is
this user empowerment, or choice in any meaningful way.  How is this
user empowered to choose when 80% of businesses end up using this
feature?  Or when the government mandates this feature.

> > 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.
> 
> Again, as Adam says, how long would it take for a government to
> introduce legislation making this mandatory once PGP 5.5-type systems
> took off? Or, more insiduously, using its purchasing power - "Federal
> agencies will only buy CAK-enabled systems" - to ensure the vast
> majority of systems did so.

Bingo!

> > Ok Adam here is a challenge for you:
> > 
> > -- Explain why Corporations do not have the right to access *their*
> > documents in whatever form they may be in.
> 
> Can I take this one up ;-) 

You beat me to it ... my reply crossed in the mail :-)

> The point is, with *communication* keys, corporations will have full
> access to the plaintext because it will be decrypted by the
> recipient as soon as it arrives. I appreciate your point about
> corporations being able to read *their* documents - although doing
> so by snooping, without the sender's knowledge, is rather unethical
> to say the least - but I don't think they have the right to snoop on
> all *incoming* communications, whoever they may be from. This is the
> really scary part of PGP 5.5...

Even if you do argue that they do have the right to snoop incoming
messages (and there may be a case for this even if some of us find it
a bit little brotherish), this can still be just as easily catered
for, without building GAK compliance into the IETF OpenPGP standard by
having the user's client software decrypt and store their mail folder
in plain text, or encrypted to a company escrowed storage key.

Such a system would not be at all GAK compliant.

> William Simpson wrote:
> 
> > Let us decide _what_ the goals are, _how_ to solve the problems, and
> > _then_ decide the protocol details and formats to match the solution.
> 
> Absolutely. Can we start with Adam and William's proposal that we should
> have three separate types of key: communication, signature, and storage.

(I am glad that you managed to persuade William that this was
necessary, I didn't notice him agree :-) William should however be
credited for the useful contribution that you can just as easily
implement corporate snooping with the existing multiple crypto
recipients functions of pgp2.x.  (Without the GAK compliancy baggage).

> This would be very simple to implement; probably the easiest and most
> backward-compatible way would be to define a new packet type specifying
> a key's usage. 

I'll go for this idea.  X509 v3 certificates have such an extension,
and it seems like a very useful functionality for OpenPGP to include.

Re. the argument about separating key functionality leading to more
consistent and secure designs, if people don't like 3 keys, you should
see some of the Norwegian standards stuff which was relayed to me at a
eurpean medical messaging standarisation meeting... they reportedly
have 5 key usages defined:

  1. storage
  2. signatures
  3. encryption
  4. certificates
  5. authentication

> > Why have a communication enforcement filter, when the only usage is
> > supposed to be for recovering archival storage?
> 
> Absolutely. I can see the point, and appreciate the difficulties faced
> by PGP Inc., in most of the CAK features of PGP 5.5. But I just can
> *not* see how the twisted idea of the SMTP snooper ever came about.

It came about I suspect because the real unstated feature they are
trying to implement is message snooping, and not stored email folder
access as the "data recovery" badge used by Jon in his first post may
lead one to assume.  Of course the reason they think they are able to
use the argument that "email is both storage and communications" to
justify this is largely because they haven't yet digested the meme
that you should have separate storage keys.

I also heartily agree with William Allen Simpson's comments.

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`