>From: Amanda Walker <amanda(_at_)intercon(_dot_)com>
>Subject: Re: limitations of mime-pem transformation
>Date: Tue, 27 Dec 1994 21:08:20 -0500
>> The idea that the semantics of multiple signatures applied to an object
>> is up to the recipient stikes me as complete foolishness!
>
>If you can explain how to unamiguously denote the semantics of any
signature,
>digital or not, I'm all ears. My current understanding, which includes a
>certain degree of background in semantics, semiotics and discourse
modelling,
>leads me to believe that this is impossible to achieve, and that the
semantics
>of any communication depends on the context in which that communication
>occurs.
The technique is called standardization. Its quite easy to design for;
one labels implicitly or explicitely the object with the associated
meaning. the labelling system is documented in an architecture. Yes,
the Internet security architecture document is a long time coming....
P2, P35, ODA, SMGL. HTML, even MIME (!) all do the same thing within
there respective defining frameworks. Some of them even have security
architectures attached which protect those semantic bindings from
undetectectable attack. MIME/PEM is one such example.
But, one of the intellectual problems of MIME/PEM is that it introduces
the notion of a "digital signature service." This is a fundamental
deviance from PEM, which had no such "service".
What PEM did have for various modes of service, as I tried to point out
yesterday with my silly counter-contradictory example, and what
MIME/PEM may or may not have, depending upon the interpretation of a
given recipient, was a *defined* meaning for a signature. We have been
though this 100 times. The ambiguity is compounded in the case of
encryption, and signed message encapsulation. If the document would
state these things to be wrong, by stating that X is the case, Ill
learn from it with pleasure.
The consequence of the PEM proof system, in which are carefully bound
message origin authentication procedures, data origin authentication
procedures, and key distribution facilitating origin proofs with
non-repudiation, is that in a connectionless environment, one can,
counter to intuition, achieve your impossible - establish the semantics
of a communication and use them to provide for privacy by ensuring that
attacks on the agreed semantics are detectable, or always ensure a
fail-safe system. That a system can be designed which requires no
operational human intervention, is really quite remarkable. for less
stringent operational processes, one can relax this a little and allow
human judgement to enter in the ajudgement of trust, upon which the
design is based. This is one area which the design specifically
accomodates the reality of the internet users.
And this is what PEM is. A careful system which specifically addressed
the semantics associated with the protocols it specifies for
vulnerabilities which could cause an attacker to exploit ambiguity and
thereby defraud or cause unauthorized disclosure.
MIME/PEM says that the pem-signature protocol ensures that MIME/PEM is
semantically identical to PEM. yet a number of the bindings between the
many system components were broken during the reformatting, and
redesign. So no, MIME/PEM is not PEM. no amount of threat, abuse, or
intimidation will force this through.
MIME/PEM is TIS's design for an Internet secure mail system though. And
by the look of it, can attact many followers who require only those
things which it provides. In moving to a lower featured design, Dave
Crocker may well be 100% right - that this is what the mass-market is
demanding. I suspect he's right also.
So, once again, we have the closure repeated. So Ned obtains
confidence to market and refine his products.
(1) Multipart security structures are big success as a framework. They
enable a number of distinguished secure mail protocols to be carried
over the MIME infrastructure. Goes forward. will be refined with
experience.
(2) MIME/PEM has been clearly identified as to what it is in terms of
security. It has clearly enough followers with a clear vision of its
market to drive it home. Goes forward. satisfing the demand between
(MIME/)PGP and PEM, in the IETF.
(3) PEM. Does what it always does. Sets the standard.
To the future of 6 months, I suspect
PEM will integrate with the MIME multipart structures, I have no doubt,
in time, based probably on the experience gained from MIME/PGP and
MIME/PEM.
I certainly intend once the docs get to RFC status to go and get UCL's
old MIME+PEM code, and see if we can do some reimplementation and get
some implemenation experience, here with the MIME/PEM design. If I can
buy it in reasonable cost source code, even better...
What more do people want?
That those who want to prioritize the next 6 months WG work on MIME/PEM
sounds reasonable. the 6 months following could be a v3 certificate
concentration period, foollwoing up on those of use
who are doing serious early deployment with that technology to address
some of PEM's and other protocol's operational problems in the Internet
community.
I do suggest we now have a join platform upon which to proceed in this
implementors group, which has identified a great deal of work is to be
done, in a number of design and operational areas.
(Its my belief that the EDI folk are crying out for MIME/PEM, and that
its security design is possibly ideal for the way that this market
sector traditionally operates. This is one of the motives we have to
engage in this MIME/PEM work being under US Federal mandate to get
messaging EDI up and running fast, on a large open scale, ...)