I should say that I'm not fundamentally opposed to application/{signed or
mime}, I just want to make sure we agree on the facts and the reason why we
need it.
At 9:55 PM -0400 7/30/97, John Gardiner Myers wrote:
James M. Galvin wrote:
Examples of "blue signing" are PGP's "-sta" mode and PEM's "MIC-CLEAR"
mode. Examples of "red signing" are PGP's "-sa" mode and PEM's
"MIC-ONLY" mode.
multipart/signed is a "blue signing" system. It does not armor the
signed data against the transport--witness the mangling taking place at
gateways. Thus, multipart/signed is not a "red signing" system.
Ergo, multipart/signed takes care of the "blue signing" problem only.
You're comparing apples and oranges. PGP and PEM are secure email
protocols. Multipart/signed is not. mp/signed works only in conjunction
with a secure email protocol; it does NOTHING standalone, from a security
point of view.
mp/signed is a framework, it's a wrapper, for conveying email that has been
secured by a secure email protocol from here to there.
Armoring or not is a transport, or MIME decision, not mp/signed. mp/signed
provides some explicit requirements about ensuring the 7bit nature of the
object to be conveyed but that's as close it gets to a transport.
When conveying text, mp/signed is blue if the object to be signed is C-T-E
7bit; it is red otherwise, since the object must encoded prior to signing.
PGP, PEM, and S/MIME combine the decision of armoring with the secure email
protocol. mp/signed doesn't care where the decision is made about
armoring, whether it be the secure email protocol or the MIME transport.
The issue, as I see it, is that MIME is fundamentally flawed from a
security point of view: there is no way to guarantee the integrity of an
object in all cases, i.e., you have to use MIME in a perverted way to
achieve the goal of integrity. More specifically, MIME neither permits
nested encodings nor guarantees the opaqueness of composite objects.
What mp/signed does is ensure that integrity can be guaranteed. It was not
made an absolute requirement principally for backward compatibility with
the installed base.
What application/{signed or mime} does is guarantee the integrity of an
object in all cases.
Now that we have an installed base of a "broken" MIME and the motivation
for backward compatibility is no longer present, application/{signed or
mime} solves a problem in a way that is "compatible" with the installed
base, however perverse when judged against the MIME philosophy.
I've read all over the archives of pem-dev and I just don't understand
the engineering logic behind the proposed form and use of
application/mime. We like multipart/signed because the signed content
can be read by the installed base. But the signature on a
multipart/signed gets munged by some existing gateways, and some UAs
can't dispatch on a multipart/signed. So, we want to stick in a shim to
make the multipart/signed opaque to said gateways and dispatchable to
said UAs. Except the shim also makes the multipart/signed opaque to the
installed base of MIME-aware UAs. So, people are therefore expected to
run around changing their installed base of UAs to be able to deal with
the shim, and we're kinda hoping that while they're doing this, they'll
also bother to also change the installed base to correctly handle
multipart/signed? And the shim can only be applied to a subset of
possible multipart/signed objects and can't protect against all known
forms of transport munging?
So you're recognizing that in spite of the utility of application/{signed
or mime} it has its own set of problems.
Jim
----------------------------------------------------------------------------
James M. Galvin
galvin(_at_)commerce(_dot_)net
CommerceNet +1 410.203.2707
3209A Corporate Court FAX +1 410.203.2709
Ellicott City, MD 21042 http://www.commerce.net/