From: Laurence Lundblade <lgl@qualcomm.com>
Date: Sat, 17 Feb 1996 11:05:09 +0800
To: Raph Levien <pem-dev@neptune.tis.com
Subject: Re: A brief comparison of email encryption protocols
In-Reply-To: <199602142049.MAA20108@infinity.c2.org>
Message-ID: <v03004d0cad4ac6d75935@[129.46.110.231]>
MIME-Version: 1.0
Content-Type: text/plain


Raph, your summary is very useful!  I would like to make a few comments and
suggest a model for breaking down an email encryption system into four
components: the trust model, the key/certificate distribution system, the
on-the-wire certificate data structure and the on-the-wire transport data
structure.  The comments:

At 12:49 PM 2/14/96, Raph Levien wrote:
>....
> An additional grave concern is key management. Contrary to some
>beliefs, key management is not a solved problem. All of the proposals
>contain some mechanism for key management, but none of them have been
>demonstrated to be scalable to an Internet-wide email system. My
>belief is that the problems with key management do not stem from the
>classic Web of trust/certification hierarchy split, but the
>nonexistence of a distributed database (with nice interfaces) for
>holding keys. The encryption protocols also stand in the way of such a
>database, with key formats that are either overly complex, inadequate,
>or both.

Here here! agreed!


>   S/MIME remains firmly grounded in the X.509 certification
>hierarchy, although the FAQ claims that the guidelines for hierarchies
>are "more flexible" than in PEM.

X.509 v3 explicitly does allow for more flexibility.  To quote from section
12.4.1:

 g) Complete flexibility in trust models is required.  A strict hierarchical
    model which is adequate for a single organization is not adequate when
    considering the needs of multiple interconnected enterprises.  Flexibility
    is required in the selection of the first trusted CA in a certification
    path.  In particular, it should be possible to require that the
    certification path start in the local security domain of the public-key
    user system.


>   Probably the most controversial aspect of S/MIME is its signature
>format. An S/MIME signed message is a MIME multipart in which the
>first part is the data to be signed, and the second part is a complete
>PKCS #7 (section 10) signed message.

It is certainly technically possible to use the multipart/signed format
from RFC-1847 (also used in PGP/MIME) with PKCS #7.  It certainly seems
superior is almost every way to the multipart/alternative in the current
S/MIME draft.  Also Steve D. pointed out that the multipart/alternative
format is not the primary signature format.


Going back to breaking things down into four parts, these are some points I
know about.  Please correct me if I say something wrong and pardon some of
the details most of us already know:

The Trust Model
---------------
Any fully implemented system will have to choose some form of a trust
model.  Some possibilities are:
  * web of trust
  * strict hierarchy
  * web of hierarchies or some other hybrid

The important thing here is that there are many trust models that are valid
and useful and it may be useful for other components of the system to be
neutral to the trust model as is clearly the case with MOSS.

The Key Distribution System
---------------------------
A lot of components may go into this (protocols, client/server
architectures, local key stores) and it is probably the most complicated
part of any system.  Some options are:
  * distribution of keys manually via e-mail
  * automatic non-interactive lookup of keys from a server
  * interactive browsing of a key store for keys
  * revocation lists or none
  * online certificate verification via a secure channel
  * certificate caching

Probably the best thing to say, is that there's a lot of work to do here.

The Certificate format
----------------------
It seems possible to pick a certificate format independent of the other
issues.  Doing so would allow us to leverage components like we do with
other data objects like MIME.  There probably only two major contenders:
  * X.509 v3
     + broadly supported by standard bodies
     + supported by several industries (e.g., banking)
     + very rich and flexible
     + ASN.1
     - ASN.1 (tough for a student to get an ASN.1 compiler)
     - complicated
  * PGP keys
     + widely deployed
     + simple to write code for
     - difficult to lookup (linear search on key id required)
     - too simple to support many trust models and distribution systems

Note that both use the RSA algorithms, so they are interchangeable at some
very basic level.

The Transport of Content format
-------------------------------
This is the format of the actual message that is sent from one user to the
next.  I'm going to discard anything that doesn't handle MIME because I
don't think they are important any more.  Raph described a lot of this so
I'll just mention a few considerations explicitly about transport formats.
   * PGP/MIME
       From a data structure format this is a compact binary format.  It
       seems reasonable to implement, is documented and requires no special
       tools.  There is a performance problem with key look ups
       for signed message because a linear search is required unless the
       key or other data is always included with the message.

   * S/MIME  (PKCS + MIME)
       Uses PKCS format with some MIME formatting.  The main problems here
       are the multipart/alternative format for signatures and the ASN.1
       requirement.  An ASN.1 compiler is required to implement this.  PKCS
       has actually been around for a while and has been used for a number
       of cryptographic systems.

   * MOSS
       MOSS is perhaps the easiest to implement and the most flexible since
       it is an ASCII text protocol like other Internet protocols and because
       it explicitly supports several trust models.

I think the most important observation is that PGP/MIME and MOSS share the
security multiparts structure from RFC 1847.  It is also possible to use
the security multiparts format with PKCS #7 and thus S/MIME could be
changed to support it.  If this happened we'd have something in common for
all formats and it would make life much easier for all e-mail client
authors.  An added bonus is that RFC-1847 support allows an e-mail client
to support encryption and signing of full MIME entities with an external
program that can be configured like MIME content viewers are with something
like the mailcap facility.  It can be something as simple as a UNIX pipe to
a command like pgp.

Laurence Lundblade      <lgl@qualcomm.com>
QUALCOMM Inc.           619-658-3584