ietf-openpgp
[Top] [All Lists]

Just say NO to key escrow or CMR/ARR revisited

1997-11-04 10:12:00
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Would someone please post the name of the correct mailing list for discussing 
this, as I do not believe that what I am about to say is appropriate for this 
forum.
   
At 11:38 PM 11/3/97 GMT, Adam wrote:

Jon Callas suggests that CMR has been discussed vigorously.  What was
the outcome?

Here's a short summary of a more secure and less politically
controversial alternative to CMR:

1. Escrow employee company use encryption keys.
2. Don't escrow employee personal use encryption keys.
3. Don't escrow employee company use signature keys.

Who do you work for Adam, the CIA, FBI, Interpol?  Escrowing company keys 
creates a target for abuse.  If security and privacy is the goal there is no 
room for ANY key escrow except that copy of the private key that the 
individual maintains for their own backup. 

Message recovery, when used properly, enhances security and privacy as 
follows:
        1) There should never be only one message recovery key that can access 
all 
organizational information.  It creates a security risk. In the event that 
such a key is compromised all previously secured intellectual property would 
be at risk.
        2) Message recovery is to be configured at the client for small 
organizational units.
        3) The unit's "TMR", trusted message recovery key, is to be accessed by 
trusted members of the group under the following conditions:
                a) The holder of the private key cannot decrypt the 
message/file. (forgot 
passphrase, on vacation, dropped dead, went to jail, etc.)
                b) TMR requires cooperative access by two or more individules 
within the 
organizational unit. (Won't get into my "shared/split split/shared secret" 
scheme at this point.)
        4) Compromise of the TMR key would require collusion. In the event that 
such 
compromise occurred, its impact would be limited to the single organizational 
unit and uncovering the weak link would be a fairly simple process.

TMR gives honest people the ability to protect their privacy and to secure 
their work from their own memory loss as well as unknown spies. 

As pgp5 packet format already supports multiple encryption sub keys
attached to signature keys, all that has to be done to support the
above is to put comments in the userID to say what purpose the keys
are for:

Jon Callas <jon(_at_)pgp(_dot_)com> (personal use)
Jon Callas <jon(_at_)pgp(_dot_)com> (company use)


99.9% (at least) of corporate users of encryption are not cryptographers. 
Understanding the difference between public and private keys, what 
encryption, decryption, digital signatures, and signature verification means 
is enough of a challenge without adding the complexity of multiple keys to be 
used for different purposes.

Provide support in the business verion of the software to escrow the
company use key.  Provide support for both company use and personal
use keys.  If some companies want to disallow personal use, you might
consider adding this feature.


This approach would only be appropriate if you were creating a surveillence 
system or a burdensome corporate control structure designed to invite 
corruption.  

The above is already provided for without CMR/ARR.

CMR/ARR fields add political and security risks, so why bother?


So what is PGP Inc's position on the future of CMR?

Is it going to be phased out?


I hope not. It solves the problem of multi-dimensional trust when 
communicating on behalf of yourself and the organization of which you are 
part.

Is it going in the OpenPGP standard?

Are there any security, privacy or political objections to local
escrow?

Yes to all of the above. The rule of thumb here is..

Just say NO to key escrow.

Andrea
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQA/AwUBNF9W9KIk/IORSe0LEQIWAwCgjgEi+ghc/Z7OZZF39N7s+Aqh0pUAoNxy
vR/2fZep9VozQn35qVVZFleT
=7EXd
-----END PGP SIGNATURE-----


<Prev in Thread] Current Thread [Next in Thread>