ietf-openpgp
[Top] [All Lists]

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

1998-09-30 13:23:51
Regarding the need for business access to encrypted communications --
I agree that the need is not strong, and I would hate to have to make the 
business case for a product that had that as its central justification, but 
there are valid examples outside of the military/intelligence community.

You might want to look at the key Recovery Alliance's web site www.kra.org for 
the Business Scenarios report, which addresses some of these needs for business 
key recovery, even for transitive communications.

Examples include review of outgoing communications by stock brokers to ensure 
that they are not engaging in insider trading (I believe this is imposed by 
law), companies who may have a positive duty to investigate a claimed case of 
sexual harassment, internal investigations of possible fraud or theft of trade 
secret information, etc.

Completely independent of these scenarios, there may be an additional 
requirement for server-based encryption of outgoing e-mail to support 
disconnected operation.

If a user composes an email message on his laptop while on an airplane, he may 
not have access to the recipient's certificates, and in particular, almost 
surely does not have access to the current CRLs.  Since the message can't be 
transmitted until the user reconnects, it may be acceptable and perhaps even 
desirable to have the server perform the encryption in the recipient's public 
key, after checking the CRLs, without necessarily making the user wait for all 
this while he is on a pay phone in the airport.  This doesn't mean that the 
information goes from the client to the server in the clear -- a symmetric key 
could easily be used.  

On the other hand, the checking of the certificates could be deferred, and the 
outgoing mail returned if the certificate has expired or been revoked. This 
would not require the server to be trusted.  

Obviously most users would probably prefer this option, but in most companies 
the users don't buy the software does, the IS department does, and their needs 
may therefore dominate.

Caveat emptor.

Bob

William Ottaway <w(_dot_)ottaway(_at_)eris(_dot_)dera(_dot_)gov(_dot_)uk> 
09/29 1:56 AM >>>
At 18:48 28/09/98 +0100, Adam Back wrote:

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.


No I wasn't thinking of CASM. I was just making a point that certain
organisations will want to be able to check their employees email for one
reason or another, this is not a military/government only issue.

Once companies start signing outgoing mail, which they will do, they are
taking some responsibility for the contents of that message. If that
message contained a virus then they could be sued for damage caused by that
virus. Signing is also a powerful mechanism which can be used in financial
transactions. Joe Blogs might not have the authority to perform financial
transactions, but a rubber seal from his organisation does carry the this
authority. This sort of transaction may need to be encrypted so that other
commercial organisations do not get wind of what you are up to. 

Yes the military and government have sensitive information which they do
not want to be mailed out of their organisations, but so do commercial
organisations (e.g. trade secrets, research, etc). This may not be a
requirement of all commercial companies but it still needs to be taken into
account when considering signing and encrypting messages. 

I would expect all large organisations, military, government or commercial
to require the ability to check employees email and to do
encryption/signing by the organisation.




(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

Bill.

<Prev in Thread] Current Thread [Next in Thread>
  • Re: Server decryption / signing (was RE: Encrypting RFC822 headers in S/MIME or PGP/MIME messages), Bob Jueneman <=