In response to Theodore Tso's request for issues and concerns, I would add the
following:
I am evaluating PEM for secure e-mail as well as for general encryption
services at Texas Instruments. I attended the recent IETF and share many of
the concerns that have been recently expressed in this mailing list.
At the IETF, I was concerned to hear it said that implementing a Certification
Authority using X.509 certificates is a non-starter. That is, such an
approach will fail. I am also concerned about the lack of interoperability
between existing internet drafts providing similar services. I believe the
coexistence of the PEM-MIME draft and rfc1421 make PEM implementations more
difficult for companies who want and need those services.
One goal of our PEM effort is to enable TI to securely communicate with trading
partners and customers across the internet. In this setting, I believe a
certification authority is the only way to ensure, with any certainty, the
correctness of a name associated with a public key. Using the PGP web of
trust model to exchange certificates does not work well for a large number of
users and it requires possibly cumbersome out of bandwidth procedures for
strong certificate verification.
To promote use of certification authorities, we need two things.
First, an automated certificate signature process to make certificate
generation easier. This process could authenticate a user then generate and
sign a certificate on his behalf with no manual intervention.
Second, we need a well-defined trust model for the CA so the responsibilities
and level of trust is clear. For example, the fact that a certification
authority signs a certificate should 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. Based on our experience
in this exercise, putting separate encryption services in PEM, MIME-PEM, shttp,
etc. will require separate export licenses for each product. This is true even
if all these products use the same underlying encryption algorithms (RSA, RC2,
DES, etc.). This issue also raises the need for a choice of encryption
algorithms and key sizes within encryption services
In summary, as a potential PEM, MIME, shttp customer I believe we need the
following:
- Single set of encryption services which can be integrated into any
application (MIME, shttp, etc.)
- Easily implemented and managed certification authority.
- Limit the functionality of the encryption services to encryption only. Any
special processing required by an application should be carried out in that
application.
Additionally, we need to do everything possible to maximize interoperability.
This includes interoperation between implementations of the same service as
well as the ability to share data across different services.
Regards; Phil Smiley psmiley(_at_)lobby(_dot_)ti(_dot_)com