At 16:00 25/09/98 -0500, William H. Geiger III wrote:
-----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,
Have you read draft-ietf-smime-domsec-00.txt?
This contains a section on encryption between servers, and between
individuals and servers. It does not rule out user to user encryption.
I agree with your points on not letting anyone else read your email.
However, organisations want to control the release of messages from their
employees. They want to make sure outgoing messagers do not contain any
sensitive information or viruses. If the sender encrypts his mail using the
recipients key the organisation can not perform any of these checks.
Encrypting and signing using an organisations key rather than an
individuals key reduces the size of the PKI required, and therefore all of
the problems to do with setting up and maintaining a PKI. Plus you are
putting a higher level of credence on the message, its not just coming from
Joe Blogs; its coming from Joe Blogs organisation.
Server to server encryption and signing reduces the cost of buying and
maintaining encryption facilities on the individuals machines. Plus the
burden on the users machine.
You can still tie a message back to the individual by allowing originator
aswell as domain signatures. Infact I recommend the message being signed by
the originator. This gives the organisation the ability to check the
document has not changed, to control who can release messages and a means
of repudination.
Bill.
________________________________________________________________
William Ottaway,
L323, Tel: +44 (0) 1684 894079
DERA Malvern, Fax: +44 (0) 1684 896113
St. Andrews Road, email:
w(_dot_)ottaway(_at_)eris(_dot_)dera(_dot_)gov(_dot_)uk
Malvern,
Worcs,
WR14 3PS