>From: Ned Freed <NED(_at_)sigurd(_dot_)innosoft(_dot_)com>
>Subject: Re: summary of technical issues
>Date: Thu, 22 Dec 1994 17:02:56 -0800 (PST)
>We want things to interoperate. This means restricting ourselves to some
subset
>of the available solutions, even when that subset doesn't always offer the
best
>performance, use of available bandwidth, or whatever.
Ned, as a designer, you argue this quality designer's line for the MIME
and SMTP issues, but for PEM issues evidently, through your support for
the current MIME/PEM concept, wish some users to have a public-key key
distribution system which will not even attempt to engender
interoperability with others who also claim and desire to support the
same basic PEM privacy service.
This is contrary to the fundamental service and scaling goal, I claim.
In my most humble and ignorant opinion, I suggest we cannot afford to
sacrifice the privacy notion or the goal of actually scalable privacy.
I also suggest that other and more accomplished designers than are
present on the TIS/PEM team put work into the PEM design, and their
judgements are not to be just discarded just to accomodate the
innovative MIME work, as-is. I continue to believe that the Internet is
not served by even 100,000 pockets of satisfied MIME/PGP users.
This view and understanding is clearly represented in reality by the
fact that MIME/PEM will go one way, and PEM another within the IETF. I
suspect they will merge later on, once the Web angle is brought into
play; and this will be the major harmonising influence I guess. PEM and
MIME/PEM are clearly very much alive and kicking away at some very
hard, common problems. The WG spoke this, and so spake the mailing
list.
Now consider some emerging commonality of direction and trend.
The acheivements of MIME/PEM to identify and address some of the issues
of Internet deployment of RFC 1422, can be now considered in the light
of X.509 v3 directly (though clearly the ISO people have been doing
this for some time as part of the ISO/IETF JTC1 liasons, informal or
otherwise)
PEM already evolved once to account for some of the claimed need to be
more general in the organization of the privacy domain, in the
formation of the PCA concept; and the syncronous and
financial-community key distribution techniques and associated
identifier forms.
The community reaction to the PCA idea was not good, as, though
logically sound, the separation by policy of users defeated the purpose
of the protocol in the Internet environment; human nature ensured that
almost everyone insisted on being a PCA depite their lack of expertise
in such an endeavour. So no wide-area privacy service ever developed in
practice based on PEM protocols. (This is my analysis of PEM's
underlying weakness - too much granularlity of policy => no privacy
wide-area service in practice! a simple lemma. The belief that !MIME =>
!PEM is so far without any justification whatsoever.)
Now, PEM has a _public-key_ key distribution service defined. It
defines identifier, format, and implies various key distribution
mechanisms. These mechanisms assume a general purpose,
multi-application infrastructure, going beyond MIME messaging, way
beyond the Internet and even telematic services, in fact. Any need to
adopt the certification policy in the Internet of PGP is automatically
handled without change.
Reimposition of a single domain hierachy would, I suggest, specialise
the policy options once again back to something doable, and usable.
That we might be able to accomodate the experience which derived from
TIS/PEM and RSA PEM/PKCS pilots and the activity to formulate the
wholly-alternative MIME/PEM, within an adoption and profiling of the
new certificate. This might be considered a new activity of the WG
formulated as a specific response to Dave Crockers requirements.
Some of the kludges introduced into PEM to accomodate X.509
deficiencies, to accomodate the assurance policy notion, and to
accomodate Interent identifier, could be considered. We could act to
now profile X.509 v3 for the PEM 1422 goals, given the syntactic and
procedural flexibility we now have available. The profiling activity
could be more prominent and perhaps standardized, so as to discourage
proliferation of policies, within the community.
This suggestion is completely in the other technical direction to where
MIME/PEM designers are currently going in their camp, note - which is
to add generality, (im not sure if Ned is being sarcastic or not about
adding algorithms to the mechanism pot) and make the underlying
deployment or privacy service continue to face an underlying set of
continual problems of operational choice, causing a delay yet worse
than that already introduced by PCAs.
These are the issues which when addressed will entail usage, I feel.
Of course the MIME/PEM work, and its integration into PEM, happen in
parallel.