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(_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,
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>