The Deming tool satisfies many of these requirements. Try it
for free, at
http://www.deming.com.
The RSADSI S/MIME page has a list of alternative vendors
with similar products, including alternative Exchange plug-ins.
The Deming producyt doesnt give you "invisible" security. This seems a dangerous
thing to ask, as all users need to be aware of at least the
residual risks when using any key-based security technology. User
access to the protection service however, is "fully integrated" as a natural
part
of the exchange interface, however, as if shipped with Exchange
by Microsoft!
The workflow angle is addressed, as the plugin comes for free behind
MAPI, as used by any MS exchnage-related workflow tool, including
much of the windows desktop's Document Send features!
Peter.
----------
From: Samuel Pickard
Sent: Friday, October 04, 1996 9:05 AM
To: kent(_at_)bbn(_dot_)com;
'fha%dde.dk%bnr400'%local(_dot_)fha(_at_)dde(_dot_)dk;
'dave_d%systrends.com%bnr400'(_dot_)dave_d(_at_)systrends(_dot_)com; 'michel
(m.) ranger'
Cc: pem-dev(_at_)TIS(_dot_)COM;
'iesg%ietf.org%bnr400'%local(_dot_)iesg(_at_)ietf(_dot_)org;
smime-dev(_at_)rsa(_dot_)com; resolving-security(_at_)imc(_dot_)org;
ietf-ediint%imc(_dot_)org%bnr400(_dot_)la(_dot_)tis(_dot_)com(_at_)TIS(_dot_)COM
Subject: RE: Sad situation!!!
From my point of view, I need a MAPI complient secure E Mail system to
integrate within a workflow system. The choice of algoritm is secondary to
this, provided I have a resonable guarantee of security. This will also need
to be able to transfer across the internet, but invisibly. The current choice
of E Mail application for us in MS Exchange. Ideally we want a plugin for this
that will give the user an invisible level of security.
Samuel Pickard
----------
From: michel (m.) ranger[SMTP:rangerm(_at_)entrust(_dot_)com]
Sent: 03 October 1996 21:53
To: kent(_at_)bbn(_dot_)com;
'fha%dde.dk%bnr400'%local(_dot_)fha(_at_)dde(_dot_)dk;
'dave_d%systrends.com%bnr400'(_dot_)dave_d(_at_)systrends(_dot_)com
Cc: pem-dev(_at_)TIS(_dot_)COM;
'iesg%ietf.org%bnr400'%local(_dot_)iesg(_at_)ietf(_dot_)org;
smime-dev(_at_)rsa(_dot_)com; resolving-security(_at_)imc(_dot_)org;
ietf-ediint%imc(_dot_)org%bnr400(_dot_)la(_dot_)tis(_dot_)com(_at_)TIS(_dot_)COM
Subject: RE: Sad situation!!!
Comments below:
----------
From:
dave_d%systrends(_dot_)com(_at_)bnr400[SMTP:dave_d%systrends(_dot_)com(_at_)bnr400]
Sent: Thursday, October 03, 1996 9:55 AM
To: Michel Ranger; 'kent%bbn.com%bnr400'; 'fha%dde.dk%bnr400'
Cc: 'pem-dev%tis.com%bnr400'; 'iesg%ietf.org%bnr400';
'smime-dev%rsa.com%bnr400'; 'resolving-security%imc.org%bnr400';
ietf-ediint%imc(_dot_)org(_at_)bnr400
Subject: RE: Sad situation!!!
Thanks Michel for the clarification on Entrust.
I guess I was thinking of the headline on the press release from RSA (see
below) when I equated Entrust with S/MIME.
BTW - Is your toolkit for S/MIME available now?
Limited Beta sites now, will expand shortly.
And does it/will it
encorporate the change that Steve Dusse reported:
Yes.
<<<QUOTE>>>>
Thanks for your interest in S/MIME. Your opinion about the confidentiality
of the signature is shared by others and has been well-voiced in the S/MIME
community. You may be interested to know that in the latest draft of the
S/MIME Implementation Guide (circulated to the S/MIME developer's list
about a month ago) there was a significant change to address this point.
The (new) default mechanism for providing a signed and enveloped message in
S/MIME is to first sign the message then envelope the entire signed
message, thereby hiding the signature. With this change, I believe a
number of companies are considering S/MIME for protection of EDI and other
sensitive applications.
<<<END-QUOTE>>>
----------------------------------------------------------------------
NORTHERN TELECOM (NORTEL) ENDORSES S/MIME
SPECIFICATION
ANAHEIM, California, April 30 -- Northern Telecom (Nortel) today announced,
at the Electronic Messaging Association '96,its endorsement of the
Secure/Multipurpose Internet Mail Extensions (S/MIME) specification for
secure electronic message exchange between different secure communications
systems.
S/MIME, based on the RSA Public-Key Cryptography Standards, allows vendors
to develop interoperable RSA-based security for various e-mail products so a
message encrypted with one product can be decrypted by another.
Nortel also announced its plans to develop a toolkit, for building S/MIME
e-mail and messaging applications based on its leading Entrust encryption
and digital signature software. Many companies are already using an Entrust
toolkit to make their products ``Entrust-aware'' and plan to use the new
Entrust S/MIME toolkit to allow for secure interoperability among
messaging systems. The new toolkit is scheduled for availability in the
third quarter of 1996.
-0- 04/30/96
For further information:
Laura Teder, Nortel 214-684-8721,
----------------------------------------------------------------------------
----------
At 11:54 AM 10/2/96 -0400, michel (m.) ranger wrote:
Just wanted to address some comments made about Nortel's Entrust.
Michel
----------
From:
dave_d%systrends(_dot_)com(_at_)bnr400[SMTP:dave_d%systrends(_dot_)com(_at_)bnr400]
Sent: Wednesday, October 02, 1996 8:39 AM
To: kent%bbn(_dot_)com(_at_)bnr400; fha%dde(_dot_)dk(_at_)bnr400
Cc: pem-dev%tis(_dot_)com(_at_)bnr400; iesg%ietf(_dot_)org(_at_)bnr400;
smime-dev%rsa(_dot_)com(_at_)bnr400;
resolving-security%imc(_dot_)org(_at_)bnr400
Subject: Re: Sad situation!!!
Stephen is right, Deming does indeed have an impressive product in its
Secure Messenger. I have tested the beta available through download and
really like the key management features and the ability to choose
encryption
and digital signature algorithms on the fly.
Another product I have tested and I know that has been adopted in at least
one large corporation here in Phoenix for secure EDI/e-mail is Nortel's
Entrust - also based on the S/MIME, RSA routines.
Back to our old debate, however, I also agree that S/MIME is unacceptable
for high confidentiality/security needs of financial EDI and some Health
Care EDI. This is due to the signature being outside the encryption
envelope. Since Deming's Secure Messenger and Nortel's Entrust are based
on
S/MIME I would not recommend them for use in EDI applications requiring
high
secrecy/confidentiality.
Nortel's Entrust is not based on S/MIME, it supports S/MIME as one
of many security envoloping protocols and services that
run on the public key infrastructure.
We focus on delivering key management, certificate management
and trust management for PKIs. Application developers and end-customers
pick and choose what services they want through a number
of APIs and services. e.g. the app can put signatures inside the
encrypted envelope.
To address your security/confidentiality concern, we have spent a lot of
time
ensuring our crypto module complies with FIPS 140.1 a US NIST
specification for
security kernels and we have certification for our DES implementation.
This is a requirement for handling sensitive Gov't information
such as health records, among others.
We also offer interfaces to optional, external crypto devices such as
smart cards and PCMCIA cards for those that want h/w assist.
------------------------------------------------
Michel Ranger rangerm(_at_)entrust(_dot_)com
tel: 613-763-8943 fax: 613-765-3520
http://www.nortel.com/entrust
Entrust : Intranet/Internet Wide Encryption, Certificate and Trust
Management.
Entrust Validation String : F8HY-NCBE-DHXA
======================================
| David Darnell
| SysTrends, Inc.
| Arizona EC/EDI Roundtable
| 1850 East Carver Road
| Tempe, AZ 85284-2510 USA
| Tel (602)838-5316
| Fax (602)897-8032
| mailto://dave_d(_at_)systrends(_dot_)com
======================================