From: Adam Back <aba@dcs.ex.ac.uk>
Date: Sat, 24 Jan 1998 08:51:34 +0800
To: cypherpunks@cyberpass.net
Subject: IETF S/MIME to follow PGP in building in GAK?
Message-ID: <199801240031.AAA00863@server.eternity.org>
MIME-Version: 1.0
Content-Type: text/plain




You may recall the furor generated by PGP Inc adding a GAK enabling
feature thus making it easier for governments to impose GAK on the
deployed PGP 5.x user base.  PGP Inc called this feature CMR
(Corporate Message Recovery) or ARR (Additional Recipient Request).

Over on IETF S/MIME, right now there is a thread which looks set to
add an almost identifical feature to S/MIME (spooky how similar the
feature is even).  Most of the regular contributors on S/MIME work for
GAK sell out companies anyway, so I figure this is pretty much a done
deal.

(S/MIME already has another form of GAK also, in that the X.509 key
directory specs allow the directory to optionally keep _private_ keys
also).

I think the ARR mechanism is actually more dangerous than keeping
locally escrowed copies of keys in PGP because of the web of trust
model.  (See: http://www.dcs.ex.ac.uk/~aba/cdr/ for my thoughts on
this).

In the S/MIME world where there is a more hierarchical approach to
Certification, you can expect government run CAs which demand a copy
of your private key also.  (eg. the UK DTI document on crypto
licensing proposals was talking about this method).  For S/MIME,
S/MIME style ARR seems fairly balanced in lethality to CAs which keep
private keys.

I wonder if Phil Zimmermann feels proud of himself now that S/MIME
looks like it will adopt his CAK/GAKware design.

You might be amused at this introductory remark from the proposer on
S/MIME IETF:

: As a side note, this is not a radically new concept as something very
: similar has already been proposed and implemented by PGP.
:  
: Flames welcome.
 
The guy's proposal below.  It was well received too.  Someone else
proposed adding it in as a core MUST S/MIME requirement to handle
these additional recipient requests.

(You can follow the thread on the hypertext archive at www.imc.org
(look for IETF S/MIME mailing list, or by subscribing to
ietf-smime@imc.org).

Adam

======================================================================
Date: Fri, 23 Jan 1998 13:07:01 -0700
From: "Steve Russell" <steve.russell@worldtalk.com>
Subject: Corporate Key mechanism
To: <ietf-smime@imc.org>

A new and somewhat radical thread....
 
 

Because I believe the following to be true:
 
- Requiring key recovery is a bad thing (complexity, cost,
  implementation, etc.)

- Companies do have a need to access mail encrypted to or encrypted by
  their employees (lost keys, legal investigations, etc)

- We are all working on methods of satisfying US export requirements
  so that we can export a cryptographically useful product

- The is a middle step between full key recovery and no hope of
  recovery which involves encrypting messages to a 'corporate key' in
  addition to a individual public key when sending a message.
 
Basically, what is involved is changing the user certificate format to
designate a field for a second certificate which represents the
corporate public key appropriate for that user.  An application
intending to encrypt mail to that user MUST then encrypt the message
to both the user key and the corporate key.
 
By no means am I implying that everyone that implements S/MIME leave a
back door into all of their messages.  However, since most companies
that are implementing secure messaging are setting up their own CA
(Entrust, OnSite, Netscape, etc.) and they have control over what
fields are populated and with what information, they are able to
choose whether or not they need visibility into their own data.
 
As a side note, this is not a radically new concept as something very
similar has already been proposed and implemented by PGP.
 
Flames welcome.
 
Steve