>From: Ned Freed <NED(_at_)sigurd(_dot_)innosoft(_dot_)com>
>Subject: Re: Key selectors (Was: Re: unpublished public keys )
>Date: Fri, 23 Dec 1994 15:12:45 -0800 (PST)
>We need to look at and see if anything needs to be addressed. The present
>multipart security mechanism is in part a result of this examination.
Ned,
I feel though I trust you almost implicitely on MIME issues.
Im sure you have been through this for your own purposes, but
can you describe in short how PGP interfaced to MIME, please, in the
"old" way?
What was considered wrong with it?
(a) did it facilitate forwarding, with all modes of message security
(b) did it support list explosion, with all modes of message security
(c) did PGP change in any way, in integrating with MIME
(d) can PGP used in this mode to protect (recursively) MIME messages
(e) was it easy to integrate with MIME handlers
(f) did multiple signature issues arise in practice?
(g) how did the MIME versus non-MIME issue go?
What did the community of MIME/PGP (old) complain about to
consider change?
Can we learn from this, and justify the progressive harmonisation
of MIME/PEM and PEM on this experience?
Perhaps really we can leverage of PGP and harmonize much
faster than imagined:
When we look at the advantages of the MIME multipart constructs versus
conventional MIME standard, can we *just*, for starters, do what old
MIME/PGP achieved?
(perhaps this means just supporting encryption (or privacy) services,
in the meantime, as identified by users as the primary demanded
feature)
And can we do this without jettisoning any core PEM services? including
the various forms of key distribution, or secured mail exploding, or
the privacy service of RFC 1422?
Or, are the multi-part constructs responsible for the need to jettison
core PEM services?
Or were these jettisoned for reasons of the designers' judgement as to
what the users want, or communities to be served, only? (there are some
tricky ego issues, here, to hopefully avoid.)
If MIME/PGP within the multipart constructs is to be a reality, and we
are all actively expecting a world of multiple signature protocols
ANYWAY, then surely we have a perfectly usable and harmonious way of
addressing PGP in the Interent, anyway!! And we can avoid changing PEM
so fundamentally. (That PGP's concept of trust may be accomdated in a
future version of PEM's privacy service, would be a further bonus)
Ive said before that I believe that most of the TIS publicised
underlying justification of MIME/PEM design was founded upon reaction
to implementation and piloting issues of TIS/PEM and some design issues
concerned with their research product, combined with raw fear of PGP's
growth and success.
I find with your reasoning a far more tenable line as its based on
choices of a clear and articulate expert who doesnt emit iconoclastic
statements, and doesnt based reasoning wholly on one set of evidence.
If you can help bring us all up to speed on the design issues
concerning an integration of secured messages with MIME, I certainly
believe that a fast and progressive integration of MIME/PEM and PEM
will happen, to everyone's benefit.
Im convinced that the last 3 weeks of dicussion have identified all big
issues which can direct the integration emphasis of MIME/PEM and PEM.
Is there a will to merge and compromise, by adjusting things around a
bit? Or do you believe it has to be the goals of MIME/PEM, or
MIME/PEM?
If people believe that the intention is to merge the goals of PEM with
the innovations of MIME/PEM, than I don't believe that there will be
any lack of concensus to supporting the promotion of MIME multipart ID
to stds track, in order to get lots of implementation experience going
with the MIME multipart constructs. (Its happening anyway!)
That PGP is merged in there at the MIME level, that multipart
constructs become commonly used all round for messaging
signature-protocols, and PEM's quality and mechanisms of privacy are
available to users who require them, would be a most satisfying,
doable, outcome.
It would be a strategy to create a common goal of all the active
parties, here. No?