Re: A brief comparison of email encryption protocols

Brad Knowles (brad@his.com)
Fri, 23 Feb 1996 05:13:51 -0500 

At 6:49 PM 2/22/96, Mark S Feldman wrote:

>                                Even if a few enlightened mail program
> vendors add security, users then have trouble because not enough mail
> programs on the various platforms they use provide those security
> services, so interoperability is non-existent.  A chicken and egg
> problem.

    Part of that chicken-and-egg problem can be solved by
convincing large service providers or OS vendors to include a
"good" standard by default.  For example, if America Online
started providing original PEM-style encryption, I suspect that
it would be an incentive for a fair number of people to have to
be able to deal with that.


    Of course, we'd never be so silly as to implement an aged
standard for which support appears to be draining (not
increasing) like PEM, but there are some security standards (or
drafts) today that do look very attractive, from the standpoint
of a company that is interested in providing this kind of
service for their customers.

    I think the whole complexion of this issue might have been
changed if, for example, we'd rolled out S/MIME a day or two
before the conference.  Of course, the vast majority of our
users are home users, and for those who care, they tend to care
about PGP.  So, if we were to have already rolled something out,
we probably would have rolled out PGP, with serious intention of
going PGP/MIME in the near future.

    And if you look at the set of existing standards with which
I am familiar and which I recently posted an updated comment on
to this list (based on what I said at the workshop), the ones we
find most attractive are MOSS (for overall structure and MIME
integration, since we're already pretty much fully MIME-aware at
the gateway) and PGP/MIME, with "original flavour" PGP a big
step back.


    Get a few large providers of this kind of service (or OS),
and you've got some pretty serious momentum.

> One way to short-circuit the chicken end egg/bootstrapping problem is
> RFC1847 (Security Multiparts for MIME: Multipart/Signed and
> Multipart/Encrypted).  If support for RFC1847, which is cheap and easy
> for any MIME-aware user agent, was adopted by email vendors, security
> packages could easily and seamlessly be added after the fact.  Users
> interested in security could purchase security packages, which might
> implement MOSS, PGP, or even S/MIME if it were modified, and have them
> work with their off the shelf mail programs.  It's the same "helper
> application" model used by MIME and many web browsers.

    One thing that was brought up at the workshop is that there
is an implication of not only feeding data to the
encryption/decryption program, but of getting data back.  The
standard "application/" definition has tended to imply a one-way
flow of information between the programs, with the called
application doing its own display direct to the user.  This has
to change when we start talking about security-aware MIME
agents, whether the encryption algorithms are built into the
agent or called externally.

    Towards this end, and the fact that we can imagine other
cases where this kind of two-way data flow could be required or
at least useful, we might want to consider carefully whether we
attach additional semantic meaning to an existing term or set of
terms and keep this kind of functionality to ourselves, or if we
want to propose a new label that would generically handle
two-way data flow and for which we could specify the particular
interaction required for secure-aware MIME agents.

        -Brad