RE: Sad situation!!!

[Peter Williams <[e-mail]>]

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: 	[e-mail]; 'fha%dde.dk%bnr400'[e-mail]; 'dave_d%systrends.com%bnr400'[e-mail]; 'michel (m.) ranger'
Cc: 	[e-mail]; 'iesg%ietf.org%bnr400'[e-mail]; [e-mail]; [e-mail]; [e-mail]
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:[e-mail]]
Sent: 	03 October 1996 21:53
To: 	[e-mail]; 'fha%dde.dk%bnr400'[e-mail]; 'dave_d%systrends.com%bnr400'[e-mail]
Cc: 	[e-mail]; 'iesg%ietf.org%bnr400'[e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: 	RE: Sad situation!!!  

Comments below:

>----------
>From: 	dave_d%systrends.com@bnr400[SMTP:dave_d%systrends.com@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.org@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.com@bnr400[SMTP:dave_d%systrends.com@bnr400]
>>>Sent: 	Wednesday, October 02, 1996 8:39 AM
>>>To: 	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
>>>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                [e-mail]
>>tel: [phone]            fax: [phone]
>>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 [phone]           
>|   Fax [phone]           
>|   mailto://[e-mail]        
>====================================== 
>
>
>
>