Peter,
I messed up the quoted reply, here is a better version.
Michel
----------
From:
peter%verisign(_dot_)com(_at_)bnr400[SMTP:peter%verisign(_dot_)com(_at_)bnr400]
Sent: Friday, October 04, 1996 1:29 PM
To: rangerm%entrust(_dot_)com(_at_)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>