James M. Galvin wrote:
At 5:10 PM -0400 7/28/97, John Gardiner Myers wrote:
multipart/signed
takes care of the "transparent signed" problem only.
Wrong.
Excuse me? I describe the phenomenon that several message security
services (PEM and PGP to name two) each provide two distinct signature
services. I describe the properties of each distinct signature service,
and attach the labels "opaque" and "transparent" to each set of
properties.
You then redefine the terms "opaque" and "transparent", and in the
context of those altered defintions assert that the above quoted
sentence is incorrect. Well, if you change the definition of the terms
I was using, of course the statement can be shown to be incorrect.
Let's try again.
Many message security systems have two types of signed objects.
There are signed objects which have the property that the signed
data can be read without knowledge of the particular message security
system. I will call such objects "blue signed objects". An additional
property that is common to all "blue signed objects" is that they are
subject to transport mangling and encoding restrictions.
There are also signed objects where the signature system also armors the
signed data against the transport. I will call such objects "red signed
objects". An additional property that is common to all "red signed
objects" is that the signed data is unreadable to software not
implementing the particular message security system.
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.
Multipart/signed solves both problems. It does this because it places no
restrictions on the object that was signed. It can be transparent or not,
according to context.
Multipart/signed does place a restriction on the object being signed.
Currently, the object being signed must itself conform to the
restrictions of the most restrictive transport it will ever be
succesfully transmitted over.
And an apparent problem with multipart/signed is that it is sometimes
transparent in contexts where it is desired to be opaque.
Multipart/signed declares by fiat that its contents are opaque. [...]
In practice, however, we all know this doesn't work because
multipart/signed objects are not treated as opaque by gateways.
So, we've learned that declaring something by fiat doesn't immediately
make it so. Making something so requires engineering and deployment.
Further, although application/(signed or mime) guaratees the opaqueness, I
don't see it as a big win. It seems to me it's more of a "the end
justifies the means", if the end is actually accomplished.
Well, it appears to be a natural law that you can have "red" or "blue",
but not both. Some people are saying that they have a need for "red"
properties. I'm saying that if there is a sufficiently strong need for
something "red", then design something that is good at being "red" and
which can be easily converted from and to things which are "blue".
Don't try to design something which is both sort of "red" and "blue" at
the same time, as you're going to end up with something which is
neither. Drive on one side of the road or the other, don't drive on the
median.
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?
I say this because with it we have two options where we used to have one
and now we have to choose every time we send a message. And don't even
suggest that user agents are somehow going to decide for the user, except
perhaps that they'll set a default (which will no doubt be application/*).
I see "red" systems being used by intermediaries which are unable to
forward something in original "blue" form.
On the other hand, as Ned has said multiple times in past months,
sometimes the right thing to do is to reach inside the multipart/signed
and muck with the signed content, thus destroying the signature. This
is particularly attractive when the only alternatives will result in
destroying or making unreadable *both* the content and the signature.