PGP CAKware & IETF controlled Open-PGP standard

[Adam Back <aba@dcs.ex.ac.uk>]

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`