ietf-smime
[Top] [All Lists]

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

1998-09-25 13:41:15
-----Original Message-----
From: William H. Geiger III [mailto:whgiii(_at_)invweb(_dot_)net]
Sent: Friday, September 25, 1998 1:22 PM
To: Steve Hole
Cc: Ned Freed; ietf-open-pgp(_at_)imc(_dot_)org; ietf-smime(_at_)imc(_dot_)org
Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages

In <SIMEON(_dot_)980918095519(_dot_)E(_at_)gallileo(_dot_)esys(_dot_)ca>, on 
09/18/98 
   at 10:55 AM, Steve Hole <steve(_at_)esys(_dot_)ca> said:

Also there has been discussion many times in the past of 
having "proxy 
security handling" for IMAP servers where the IMAP server handles
decoding encrypted messages on behalf of the client and sending the
decoded content over an encrypted data connection to the 
client.   Note
that this is not a  real situation now, but there are lots 
of reasons for
people to want this  behaviour in the future and it continues to be
discussed.

IMHO this is *not* a good idea.

The purpose of using end-to-end encryption is to avoid the 
use of unknown
3 party systems to relay encrypted data. Decrypting on the server then
re-encrypting via different means devalues the original encryption and
brings unnecessary exposure of the raw data. It would also 
require that
the decryption keys of the recipient be stored on the server adding an
added level of insecurity.

The originator can encrypt for the server, which will then decrypt the
message and send it on to the recipient.  The server does not need to
have the recipient's private key -- in fact, the recipient may not have
a keypair at all (only the server).  The value of the original
encryption is to keep things protected at the message level over the
public Internet, and then place the plaintext on the local trusted
network.  This allows for organizations to implement message-level
security without having to put cryptography on the individual desktops.

While I have played with "proxy security handling" in the 
past it has been
for out-bound encryption, in-bound signature verification, and policy
enforcement. In-bound decryption & out-bound signing should 
never be done
by anyone but the owner of the private keys.

The server can have private keys also, and the semantics of the outbound
signature is that the server (or organization) signed the message, not
the individual.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060


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