Jim,
Sorry for the delay in this response. Some of this still seems to be
appropriate to the ongoing discussion.
Author: galvin(_at_)tis(_dot_)com@INTERNET
Yes, there are problems with the PEM-MIME specification.
Paul, my question was specific to the thread Jeff and I were discussing,
not a general one. If there are problems, please be specific about
exactly what is an issue and why.
I was following the specific thread. The discussion had digressed into details
of database modifications to support the PEM-MIME key selectors. The real
problem is the general one. Much of the discussion has focused on changing
specific mechanisms. I was recommending that we step back at look at the
requirements that these mechanisms address. I believe that much of the debate
is based on the differing expectations of PEM-MIME. Some confusion may also
originate from the current documentation of the PEM-MIME mechanisms.
>I think Jeff and I could both really use some alternative >insight.
This is not a problem of mechanisms, but of requirements. It is
true that many interesting mechanisms can be defined to
distribute public keys. Not all of these mechanisms are
necessary. As a working group we need to focus on what
requirements PEM-MIME should address.
How does key distribution factor into the discussion at hand? To date
this issue has not been discussed.
Many interesting ways can be developed to retrieve (a better choice of words
than distribute) public keys. PEM-MIME uses Identifiers, Name Forms and Key
Selectors. Not all of these are seem to be necessary. The interactions
between the trust models that are now allowable with these approaches have not
been defined.
Changes have been made in PEM-MIME that add requirements to
existing implementations of RFC1421 PEM beyond the basic MIME
encapsulation formats. Rather than spending too much time
rationalizing how a data base can be changed, as a group we need
to focus on the mechanisms that these
Your sentence ended abruptly. Where is the rest?
Gone ... looks like I need some integrity checking ...
While I have been following the basic discussions on mechanisms, the PEM-MIME
specification does not describe the problems these mechanisms are intended to
solve (yes, I know there are a list of changes at the back of the
specification, but changes are not requirements).
Your rationalization for some of the PEM-MIME changes are based on the success
of PGP. It is worth noting that PGP is much simpler than PEM-MIME. PGP does
not suffer from the ambiguity in naming and trust models that damage the
viability of PEM-MIME. PGP has a single useful naming convention that includes
a name and a optional e-mail address (e.g. "Joe Hacker
<galvin(_at_)tis(_dot_)com>" ).
PGP is freely available (internationally), robust (filtering of text prior to
MIC calculation), efficient (supports compression) and available on multiple
platforms. PEM-MIME has none of these advantages.
Currently I recommend the use of PGP to groups within my company that are in
dire need of security (we have lots of foreign offices). This is only a short
term solution. During the last year Motorola has been attempting to make PEM
available to all corporate e-mail users. Strict naming conventions, revocation
mechanisms, certificate distribution systems and well defined trust models are
critical for successful fielding of these mechanisms in a large corporation.
Classic PEM (RFC142x) is well designed for application within a large
corporation and had only a few minor quirks that needed fixing (IMHO - like
support for MIME, improved MIC-CLEAR, alternate/enhanced documentation of
distinguished name conventions, X.509v3 support and minor format changes for
efficient processing).
I am convinced that some of the requirements that PEM-MIME address are not
compatible with the original requirements of RFC142x. These RFCs were
carefully structured documents that forced specific assumptions of "good"
security practice. Classic PEM provided structure with well defined trust
models. Nouveau PEM opens doors to new trust, certificate and naming
architecture's without warning users of issues lurking behind these doors.
Naming anarchy is a feature of PEM-MIME and it supports free-form names
certified by certificate-like structures with ill defined security policy
semantics. Structure and anarchy are not compatible requirements.
Regards,
Paul A. Lambert
Motorola, Inc.
M/S AZ49-R1209 Internet: Paul_Lambert(_at_)email(_dot_)mot(_dot_)com
8220 E. Roosevelt Rd. Phone: +1-602-441-3646
Scottsdale, Az. Fax: +1-602-441-8864
85257 USA
PS For my own amusement I have been trying to collect PEM-MIME requirements
from the specification and comments sent to this list. I will post these
separately.