PGP CAKware & IETF controlled Open-PGP standard

One aspect of PGP's controversial CAK system in pgp5.5 that I have not
seen discussed is the standardisation aspects.

How does the introduction of corporate access to keys (CAK), and
government access to keys (GAK) features fit into the IETF framework?

Are PGP Inc's CAK features intended to be part of the now IETF
controlled Open-PGP standard?

What is the IETF's stance on politics having influence on security?

A weakly comparable example might be perhaps the IPSEC standardisation
process, and the effect of export regulations on key sizes.  Are IPSEC
key sizes allowed to be restricted in the standards so that IPSEC
products can be exportable?


Now some would argue, and with some justification, that emails sent
using company equipment are the property of that company.  However
there are other considerations also.  Expectation of privacy is one.
The negative aspects of a society in which most companies have become
little brother institutions, becoming small versions of what many of
us are fighting: mandatory government access to keys, big brother
wanting the ability to read all traffic.


I would be somewhat concerned if PGP Inc's recently announced the key
escrow functionality becomes part of the Open-PGP standard, because it
will set a bad precedent, and possibly force others who would
otherwise wish to implement to the open-PGP standard to also implement
features useful to secret service special interests in enforcing
mandatory domestic government access to keys, or implement only partly
compatible systems.

I need hardly comment that such an eventuality is not in the interests
of the internet community.


Specific questions relating to the standard are perhaps:

- Are the certificate flags informing the recipient that
  communications to a key is escrowed, and that email which is not
  encrypted to the escrow key will be bounced expected to be part of the
  Open PGP standard.

- Can a conforming application ignore the key escrow flags?

- Or must a conforming application display a suitable warning perhaps
  such as:

    WARNING: the person whose key you are using has the misfortune of
    being forced to use software supplied by a company which has sold
    out to key escrow, therefore you data may be read by others than
    your intended recipient.

  and perhaps a note tacked on to the email for the recipient to read:

    SAY NO TO KEY ESCROW.  Boycot little brother and big brother.
    Don't buy PGP Inc software.

  or must conforming applications be more polite.

Aside from the snide remarks about key escrow, I am concerned about
PGP's actions harming internet privacy, and helping indirectly the
introduction of mandatory key escrow which the US administration and
UK secret service and department of trade and industry are pushing.

A system which implements all the features necessary for mandatory key
escrow as a business solution may indirectly help the mandatory key
escrow proponents.  Plausible events which might happen in such an
event might be:

- companies encouraged to use (or penalised for not using) open-PGP
  corporate escrow compatible systems

- service providers also encouraged to use such systems

- companies legally required to use such systems, and hand copies of
  corporate master keys to government (corporate escrow then becomes
  government escrow for business communications)

- ISPs and individuals legally required to use such systems, and hand
  copies of corporate master keys to government (full blown mandatory
  key escrow)

I am concerned about the possibility that the IETF might be steered by
PGP Inc into putting features into the Open-PGP standard which are not
in the interests of the internet community.

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`

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

	Jon



-----
Jon Callas                                         jon@pgp.com
Chief Scientist                                    555 Twin Dolphin Drive
Pretty Good Privacy, Inc.                          Suite 570
(415) 596-1960                                     Redwood Shores, CA 94065
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

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`

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

In <199710110154.CAA06536@server.test.net>, on 10/11/97 
   at 02, Adam Back <aba@dcs.ex.ac.uk> said:

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

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

William Geiger <whgiii@invweb.net> again:
> In <199710110154.CAA06536@server.test.net>, on 10/11/97 
>    at 02, Adam Back <aba@dcs.ex.ac.uk> said:
> >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).
> 
> I didn't see where Jon said that the other versions versions of PGP would
> not recognize these keys. 

Neither did I.  But the question at hand is whether the IETF OpenPGP
should recognize them.

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

I'd argue that it's more than just not necessary, having the
information in the public key is the sole reason I'm arguing that this
is a GAK compliant feature.

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

Not very intuitive to the user though is it.  Also not a very strongly
optional feature if 80% of businesses end up bouncing your mail back
at you because you're "choosing" not to be GAK compliant.

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

Not so fast there.  That isn't the stated problem.  The problem is
that not only can some 3rd party adopt it (no modifications necessary,
that's why I'm dubing it "GAK compliant"), but that the rest of the
compliant OpenPGP standards would automatically cooperate to some
degree, and we would thereby be streamlining the migration path to
mandatory GAK.  If PGP retract the GAK compliancy feature, by removing
the functionality in the key, we won't be calling it GAK compliant.
They (and any other government or corporate message snooping feature
implementors) can achieve message snooping without adding this
functionality to the OpenPGP standard.

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

No, they are not.  I've argued in reply to your other post why this is
clearly not so.  The difference is that PGP is creating a new animal:
a key which it is defined will be auto-encrypted to two keys by the
_sender_.  Variations being discussed being auto-encrypt with user
query, or auto-encrypt with user override to disable.  Regardless, the
fact that PGP is encouraging the process of enforcing this dubious
security practice via their policy enforcer means that users are
forced to use the GAK compliancy feature to get through to any
corporates who are using PGP's method of implementing corporate
message snooping.

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

It's less strongly enforced GAK compliance, but I think it is still
a form of GAK compliance.

To see why this might be, consider the effects of 80% of the business
community using this feature, and you as a pro-privacy cypherpunk type
(you are pro-privacy aren't you?).  Consider also that government has
mandated that companies hand over their message snooping master key to
the Feds.

Now what happens.  In the above, you have the "option" not to use the
GAK compliance feature in that you can still send a message, but the
option won't be worth much in that the recipient will be unable to
read it.  If lots of people are using this system, that will cut you
off.  You will be unable to send email to these people.  It's all very
well to say you have the "choice" not to do business with them, but
your choices may be severely restricted.

I hope that following from this discussion you can see the advantages
of PGP switching to the use of the normal multiple crypto recipient
field to acheive this message snooping functionality.  It doesn't
apply at all to the recipient.  The snooping of received email for
those using PGP 5.6 "message snooping for businesses" is done after
decryption in the PGP5.6 "for message snooping enforcing" client.  The
snooping of sent mail for users of PGP5.6 "for message snooping
enforcement" client is done inside the corporate LAN as the message
snooping packet security leak prevention functionality built in to the
PGP 5.6 "SMTP prevention of security leaks enforcer" strips out the
second message snooping crypto recipient packet.

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

You may have not been convinced of the case, but that is because you
have not considered the long term picture, interoperability issues,
and utility to GAKkers of having GAK compliant features in the IETF
OpenPGP standard.

The argument that pgp5.5 has mandatory GAK compliancy does not in any
way apply to older versions of PGP.

PGP 2.x can support voluntary GAK in that the user can send to a
second key that the NSA generates for thme.

It is the features which move the enforcement of this functionality
into the senders client, and the fact that the "optional" nature
becomes weakly optional (meaninglessly optional) if you consider
scenarios where most businesses are using the pgp5.5 SMTP policy
enforcer to bounce your email unless it complies, and where business
are legally required to use such policy enforcers, and businesses are
legally required to hand over the master corporate snooping key to the
GAKkers to go in the NSA database.

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

That's a separate argument entirely.  I believe that I have shown
security advantages in not doing corporate message snooping in the way
that PGP is "proposing" (by steaming ahead and implementing and
deploying it outside of the IETF OpenPGP process).  In addition I made
the point earlier that any form of message snooping is weak... there
are many ways for the determined employee to by pass it.  The only
real protection is surveillance cameras, tamper-resistant key board
logs, and body cavity searches at the door.  So if enforcement is weak
anyway, it seems sensible to trade some small percentage of this
enforceability for enhanced security.

I went to great pains to detail other more secure, and entirely
feasible methods of assuring corporate message snooping functionality
can be built.

I also clearly distinguised between stored documents and documents in
transit in transient communications mediums.

In addition I argued for key escrow of storage keys as good company
backup policy.

You have not been paying attention here, or are playing the function
of the luddite, refusing to accept that better security is obtained by
separating the functionality of encryption keys and storage keys.

A similar example might be if you were to refuse to countenance the
suggestion that having separate signature and encryption keys is
better than not doing using as an argument perhaps the fact that
pgp2.x has been using the same key for both purposes for years.

The point of the IETF OpenPGP standardisation process is to explore
the options and decide on the best technical approach, which is in the
interests of the Internet community.

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`