-----BEGIN PGP SIGNED MESSAGE-----
In <01FF24001403D011AD7B00A024BC53C53A7176(_at_)cane(_dot_)deming(_dot_)com>,
on 09/25/98
at 01:47 PM, "Blake Ramsdell" <BlakeR(_at_)deming(_dot_)com> said:
-----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.
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 whole point of end-to-end encryption, I don't have to
"trust" any network security, all I have to trust is my local security and
my recipient's local security. While not putting encryption on the users
desktop may be a selling point to the pointy haired bosses it is a
downgrade of the encryption protocols and not a direction I would
recommend.
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.
IMHO this is poor practice. Corporate documents should be signed by the
author(s) of those documents not some universal company signature. Even
with corporate entities, one still needs to tie back to individuals in the
corporation during communications. I may be missing something here, but I
don't see the value of a generic corporate signature.
- --
- ---------------------------------------------------------------
William H. Geiger III http://www.openpgp.net
Geiger Consulting Cooking With Warp 4.0
Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
- ---------------------------------------------------------------
Tag-O-Matic: Windows? Homey don't play that!
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a-sha1
Charset: cp850
Comment: Registered_User_E-Secure_v1.1b1_ES000000
iQCVAwUBNgwJTY9Co1n+aLhhAQE96gQAlGhKml9VG7pPUnY+7lDTudU8RN+KFcVF
Ds/LHrL0LEQYQj/y6XZ+ai4Vq4OjLCEQnJTG41qJqUnMhNcNTDR3JbUXyEY4bCta
a4Uw18dOavsbT525YPc+9emOUbl62FAAbjsdnDSLN8ACBwhyD8IuPjDdTloAUTSk
avXbyVsbkX4=
=fkoP
-----END PGP SIGNATURE-----