Please accept my apologies if this message is out of bounds, but there's been
a lot of talk recently about implementations, infastructure, and so on. As
someone whose bottom line is directly affected by the output of this working
group, I'd like to make a few observations:
(1) It is easier to fill a vacuum than to displace an object.
Right now, secure MIME is a vacuum. A principal goal of MIME/PEM is
to fill that vacuum with a mechanism that dovetails with RFC 1421 PEM.
However, the choice is not between "MIME/PEM now vs. MIME/PEM later."
The choice is between "MIME/PEM now vs. something else now." If you
think that MIME/PEM has conflicts with Classic PEM, imagine the conflicts
between Classic PEM and anything else.
(2) The market wants secure email now.
The popularity of PGP, as well as its exposure in the popular press
(of which PEM has had absolutely none), is a prime barometer. It's
also quite high on the "requested feature" list we maintain as part
of our customer & market research database.
(3) Market forces accomodate demand.
Put simply, if we don't give people secure MIME, someone else will, and
they will adopt it. Speaking as a vendor, I intend on *shipping* secure
MIME email software within six months, one way or another. This means I
am imlementing it *now*. It sounds like Innosoft, Qualcomm, and other
major email software vendors are in the same boat.
I would like to use the output of this working group, because I earnestly
believe that PEM is sound technology and that the IETF process is the
best way to set standards on the Internet.
But my first responsibility is to my customers. If there is no
proposed standard, I'll use the current draft, or work with RSA and
other vendors to define application/pkcs-7 as a registered MIME type,
or whatever I have to do. And once something else is deployed, current
practice will no longer be a vacuum. MIME/PEM will actually have
competition to displace, without the pent-up demand for adoption that
it currently has. If it ever exists, it will have become a solution to
a problem that no longer exists, and no one will bother with it.
If you want to ensure that PEM will become irrelevant, by all means continue
to refuse to send it forward. RFC 1421 will go the way of RFC 914. Anyone
remember RFC 914? Funny how SLIP made it irrelevant, even though SLIP was
technically inferior. But people built and adopted SLIP. That made all the
difference.
Amanda Walker
InterCon Systems Corporation