Subject: Re: Server decryption / signing (was RE: Encrypting RFC822 headers in S/MIME or PGP/MIME messages)

From: [email-masked]
Date: Mon, 28 Sep 1998 04:07:25 -0700 (PDT)

William H. Geiger III [[email-masked]] wrote:
>I don't like it. It goes against the concepts of end-to-end encryption. If
>I want to send an encrypted message to someone, I want *only* that
>recipient to be able to read that message, not someone down in MIS, not
>some mail clerk, or god knows who else that has access to the local
>network. 

I think there's a definite use in corporate-land; just as when I submit an
order to a web-server I use a corporate ordering encryption key, there's
no reason why when I send an order in by email I would use a personal key
rather than a group key. Just as the web-server decrypts the order and
probably stores it in a plaintext file somewhere, the mail server can 
decrypt the order and pass it in plaintext to the first available clerk.

In some cases I want to send mail to a particular person in the company,
but in most cases I just want to send it to a particular department, who
would have to either share a key or have a decryption server. As long as
PGP warns that it's a shared/server-decrypted key (there was talk of 
creating an Open-PGP flag to indicate this, but I don't know whether it
happened) I don't see a problem.

And as I've mentioned before, this system solves most if not all of the
problems that CMR claims to solve, without the new problems it creates.

    Mark

---

From: Adam Back <[email-masked]>
Date: Mon, 28 Sep 1998 13:23:23 +0100

William Geiger writes:
> I don't like it. It goes against the concepts of end-to-end
> encryption. If I want to send an encrypted message to someone, I
> want *only* that recipient to be able to read that message, not
> someone down in MIS, not some mail clerk, or god knows who else that
> has access to the local network.
 
This is the way that I think would make sense to set this up.  (I
spent some specing a system to do this for corporate environments).
Bear in mind there is a trade off with some brackets of users: letting
them manage their own keys may be worse than having a machine locked
up in a machine room decrypting for them.  Certainly having a machine
in a machine room AND them both decrypting (super-encrypted traffic)
is more secur than them decrypting on their own.

You have your normal PGP encrypted messages for individuals.  You also
have a outgoing auto-encrypter and an incoming auto-decrypter.

Auto-encrypter:

If the recipient has an individual key (the email adddress is an
individual address) the auto-encrypter encrypts for that individual if
the message is not already encrypted.  You optionally super-encrypt
with the auto-decrypter's public key.

If the recipient does not have an individual key, the message is
encrypted with the recipient's system's auto-decryptor public key.

Auto-decrypter:

Decrypt anything which is decryptable with the auto-decrypter's
private key.

This then is strictly more secure than just PGP on it's own because it
adds security for:

- people who forget to encrypt
- people who don't want to learn how to use encryption
- all messages between sites having the auto-decrypt/auto-encrypt ability

For bonus points you observe that the traffic between the
auto-decrypt/auto-encrypt could just as well be encrypted with forward
secrecy.

You might also observe that installing IPSEC on sending and receiving
mail hub would achieve exactly the same thing (including forward
secrecy).

> problems that CMR claims to solve, without the new problems it creates.

Agree strongly!

Adam