Ned Freed writes:
I'm sorry, but I just don't buy it. Part of the MIME work has been to
provide
means to integrate capabilites into existing mail systems in a as seamless
and automatic a fashion as possible. A considerable amount of effort has
been
invested on this front, with the result that it is possible to add MIME
capabilities to an enormous number of existing mail systems fairly easily.
As someone interested in supporting encryption services in MIME, Non-MIME, and
other applications, this is good news. Does this mean the encryption and
digital signature capability can be easily abstracted and used in other
applications such as secured file storeage, etc? If so, are we dependent on
individual MIME-PEM vendors do to this? I really don't want to install (or
pay
for) this type of service multiple times.
This depends on the specific ways that vendors elect to manifest the services
in their products. In a fairly modular product I would expect to see this done
as a collection of tools that could readily be adapted to non-messaging
services. (This is how we plan to do it in our products.) Most MIME products
are more or less forced to implement along these lines given the nature of MIME
itself.
However, there are some exceptions on low-end systems, where the constraints of
the operating environments may make place insurmountable obstacles in the way
of modular implementation practices.
One related (possibly obvious) question:
If I receive a Trusted public key, name form from someone, I assume I need to
store it for further use. If so, I need a database which stores public keys
accessable by name form or something else. Is it anticiapted that MIME-PEM
products will include this or is this additional effort for deployment?
Any viable product has to provide a means to do this. In addition, it is almost
imperative that products provide hooks to tie into other systems as well --
support for smart cards and similar stuff depends on the availability of such
hooks.
If
it's provided by the vendors, will this database be exposed for applications
described in the previous paragraph?
Supporting the replacement of the database is one thing. Supporting the
use of the database by other applications is quite another. I don't know
how far vendors will be willing to go along these lines, given than
standardizing such interfaces limits their long-term implementation options.
Probably the best outcome would be for this to be taken up by a group that does
API specifications, e.g. the IETF CAT Working Group.
There is also the issue of whether the database is kept at a system level,
user level, or both.
My apologies if this is obvious, I'm trying to work through the possible
implemenation, scalability issues.
There are many of them. In fact whenever I get together with any of the
TIS/PEM implementors I usually end up talking at length about issues along
these lines.
BTW, I agree with the comments regarding the call for comments on MIME-PEM so
close to the holidays. Was a decision reached on that?
Not as far as I can tell.
Ned