ietf-smime
[Top] [All Lists]

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

1998-09-28 10:42:02

Bill Ottaway writes:
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.

Snooping outgoing email for sensitive information isn't a general
commercial requirement.

It is predominantly a government / signals intelligence special
interest goal.

UK's DERA (Defense Research Agency) / GCHQ designed the CASM protocol
to allow snooping on sent and received email.

CASM is partly based on server encryption.  Bill works for DERA
(dera.gov.uk), so I am wondering if he is thinking of CASM in his
comments, in that some of his arguments are couched in terms of a
desire for mail snooping, while others were discussing server
decryption purely in terms of ease of deployment, and adding blanket
super-encryption, security and forward-secrecy for email that would
otherwise not be encrypted.

(CASM includes a form of GACK involving recomputing seed material, for
details see:

        http://www.opengroup.org/public/tech/security/pki/cki/

)

(As an aside, IMO, CASM is not a very elegant protocol: it has many
online messages, uses public key crypto where symmetric could acheive
the same effect with equal security, and has a centralised risk of the
seed material of the root node of the hierarchy being compromised.)

Shared keys or server encryption copes with multiple recipients
needing to be able to decrypt messages (the `sales team' scenario).

Server encryption is useful to augment personal key based security,
and/or to speed deployment of "some" encryption even if not at first
cut personal key based.

I agree with Bill's comments about reduced PKI overhead of server
based crypto, and his ease of deployment comments.

Adam

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