RE: Sad situation!!!

["michel (m.) ranger" <[e-mail]>]

Peter, 
I'm sorry for the delay in responding, but I've had a huge backlog
of requests to deal with.

Please find our comments below. My quoted reply seems to be
messed up, let me know if you want me to re-post this
again.

Regards,

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, 
>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. 

>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 a standard, 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>