d not make the CA responsible for the
actions of the certificate owner. The signature merely validates, with some
degree of assurance, the identity of the certificate owner.
This approach would provide a strong form of authentication without the
manual
bottlenecks and issues regarding legal responsibility.
Regarding encryption services in general, I believe there are common needs in
MIME, text based e-mail, shttp, and other applications. Typically, users
will
employ some combination of these services. We need one common encryption
interface supporting a well defined set of algorithms to be used by any
application.
There are many reasons why this is desirable.
Interoperability. For example, an encrypted message received via e-mail
(under
rfc1421) should be forwardable using MIME without reformatting the message
for
MIME-PEM format. There will be other situations where data will need to be
shared by different applications. Also related to interoperability,
customers
will not accept a proliferation of public keys to support a number of
applications providing similar encryption services.
Cost. We cannot afford the cost to continually solve the same problem under
different applications. Customers of these services will not be willing to
pay
the price and this duplicated effort delays delivery of these services.
Export/Import issues. This issue is not going away soon. We need to solve
it
once and leverage off that solution. We have begun the application process
for
export/import licenses for encryption software for TI. Bas
----------------------------------------------------------------
Dennis Doubleday (dday(_at_)sware(_dot_)com) (404)315-6296 (x62)
SecureWare, Inc. 2957 Clairmont Rd., Suite 200 Atlanta, GA 30329