REPOST : RE: Sad situation!!!

"michel (m.) ranger" <rangerm@entrust.com> Fri, 11 October 1996 11:59 UTC

Received: from cnri by ietf.org id aa19095; 11 Oct 96 7:59 EDT
Received: from neptune.hq.tis.com by CNRI.Reston.VA.US id aa07230; 11 Oct 96 7:59 EDT
Received: from neptune.tis.com by neptune.TIS.COM id aa04623; 11 Oct 96 7:34 EDT
From: "michel (m.) ranger" <rangerm@entrust.com>
To: peter%verisign.com%bnr400.tis.com@tis.com
Cc: pem-dev@tis.com, 'smime-dev%rsa.com'%local.smime-dev@rsa.com, 'dave_d%systrends.com'%local.dave_d@systrends.com
Subject: REPOST : RE: Sad situation!!!
Date: Thu, 10 Oct 1996 08:17:11 -0400
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: pem-dev-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9610110728.aa04618@neptune.TIS.COM>

Peter,

I messed up the quoted reply, here is a better version.

Michel

----------
From: 	peter%verisign.com@bnr400[SMTP:peter%verisign.com@bnr400]
Sent: 	Friday, October 04, 1996 1:29 PM
To: 	rangerm%entrust.com@bnr400
Cc: 	pem-dev%tis.com; smime-dev%rsa.com; 'dave_d%systrends.com'
Subject: 	RE: Sad situation!!!  

Michael,

>Will Entrust's S/MIME application and toolkit ensure that
>sites which procure the Entrust product will be able
>to use the cert-server product of their choice, or will
>they be *forced* into using Entrust Key Management?

They will not be forced.   

We provide open systems key management, and our intent is to 
support all the appropriate standards in this area.
Applications can very easily connect to 
Entrust key management by going through our toolkits
today, and less easily by doing their own
implementation of open key management interfaces
at any time.  Note there are zero 
run time fees for an application to use Entrust 
if Entrust is already installed on the
machines in the network.


>The S/MIME spec was carefully written to ensure that
>anyone who claims conformance uses/provides/offers interfaces
>to users which allow integration of *any* parties cert-server -
>which exports the interface specified.

>When Entrust last "based" a product on PEM 1421,
>it denied users the abiity to use third-party
>products in this way. The argument was PEM 1422
>key management was incompatible with
>business requirements, which was fair enough.

Entrust never claimed to interoperate with PEM implementations.
Our customers required features that PEM could not accomodate.
We then just claimed to use PEM headers.

To be really precise we had 'PEM-like' headers
as we used a 2 key infrastructure and
therefore have one certificate for a signature key
and another for the encryption key.  PEM
assumed one certificate does both functions.
Anyway, all this predated S/MIME.  We had to
choose an encrypted file format then and we tried
to be as close as possible to the only thing
out there at that time, that being PEM.
S/MIME, we believe is an alternative to our current
format, that will provide the hope for interoability
we all want.  These interop tests will
identify the issues and problems with multiple CAs and trust models
in our various markets and environments.  

This will allow all of us to improve the specification and products
together in an open and professional dialog.
Our customers expect no less.

>Having learned from Entrust/PEM, S/MIME does
>not mandate any given model for key management
>(users can choose Entrust, PGP, SET, etc), yet
>it *does* mandate a syntax and messaging
>service for interacting with those
>third-party cert-server products (from Netscape,
>Microsoft, PGP Inc, etc.).for the most basic
>function - communicate a cert request, and communicate
>a cert chain response. All other value is at the
>vendors discretion.

>Does Nortel commit to be open on the use
>of the _required_ interfaces (required in the sense of
>being labelled "conformant"), or will it "omit"
>the _open use_ of the specified interfacing to third-party
>cert-servers from Netscape et al?.

We will implement the standard with all the minimum required
functionality including algorithms, etc.


>To be blunt; many Internet user sites are investing in Netscape
>and Microsoft cert-server products. They should be able to use their
>Entrust-procured S/MIME tools with that invested infrastructure, as
>they deploy it. Should they move to a Microsoft
>cert-server also offering S/MIME cert-server
>interfaces, when they tire of their Netscape
>product's functionality (say), then they should be able to swap out
>one vendor products, for another, when performing
>S/MIME specified key management functionality.

Agreed.  However we believe vendors will use the Entrust toolkits
when they want to build an Entrust-aware product.  The development
work is really simple, especially if the application developer
has thought about security before.  Recently a developer from a
large client/server application product did the integration 
(for proof of concept demo) in one day.


>How open is Entrust to competition? ... and third-party bundling
>by system integrators?

Entrust key management only has value if many applications 
can use it.  We are working with lots of software vendors and
system integrators to achieve this.  Recent ones that have announced
are IBM, HP, Harbinger, and Symantec(now JetForm). 

>What committements does Nortel give to not repeating what
>it did with PEM 1421 based mail security?

We never claimed to provide full PEM interoperability nor 
intended to.  We just used what was relevant 
until something better came along.  The secure email standards
battle today sure seems like the S/MIME will win,
and we will support S/MIME.  Anyway, we will always do what our
customers want- i.e.., we ship MSP for Military customers.

>Is the Entrust S/MIME strategy an open or closed strategy
>wrt key management systems from independent third parties?

Entrust S/MIME toolkits are designed to work on the
Entrust key management infrastructure.  As the S/MIME is standardized,
is it possible to put another back end key management system replacing
Entrust- >Yes.  It is our job to make sure Entrust key management keeps
providing value to the customer so they will keep it.


<other stuff deleted>