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>
- REPOST : RE: Sad situation!!! michel (m.) ranger