Concerning the the "gaping security hole" of using S/MIME's
multipart/alternative approach with a remote message validation
server:
Since the remote validation server is S/MIME-aware (it is checking the
signature), then it can also check if the message it is verifying is
multipart/alternative. If it is, then it can simply confirm that the
data in the "clear" part is the same as the data inside the PKCS
part.
I already covered this matter in my original posting on this subject and
explained why your approach won't work. I'll expand on my original statement
here, not only to show why it won't work, but to show that it only makes
matters worse. But first of all, a notational point -- I don't want to call the
extra copy of the data the cleartext since that's not what it is, so I'm going
to call it the alternative form.
The problems with performing a security check the alternative form of the data
are twofold, but both arise from the essential nature of multipart/alternative.
multipart/alternative was only designed to provide alternative version of the
same object. It was not designed to provide any sort of security service. As
such, there are agents out there that treat in ways that are incompatible with
a security service -- its content may be reformatted, converted, or otherwise
processed, rendering the signature invalid. This is especially true of
alternative out of all the various multipart formats since its providing
alternative views and massaging things to restrict or expand or alter those
view is a very natural operation to undertake.
multipart/signed, on the other hand, is explicitly defined to be a
security-related enclosure. Agents can be told quite explicitly not to
mess with it.
This is not an academic argument, either -- agents exist that do what I have
described. For example, the software I work on -- Innosoft's PMDF -- often
performs operations on multipart/alternative objects that would alter the
alternative form and render a signature across it invalid. multipart/signed, on
the other hand, is handled correctly -- its content is not considered to be
eligible for such transformation.
The second problem is more insidious and is the real showstopper.
multipart/alternative provides a *generic* set of alternative formats of the
same thing. Nowhere does it say *why* there are different versions, nor are
there any rules for selecting one alternative out of many. There's a rule that
the "simplest" part must appear first, but the criteria for simplicity are not
defined anywhere. And countless examples with very different semantics exist in
practice. It is used to present plain text, postscript, and wordprocessor
output of the same document. It is used to present different forms of external
body access (local file, FTP, mail server). It is used to present different
language versions of the same document. It is used to present lo-fi moni and
hi-hi stereo. And so on. The possibilities are endless.
Now S/MIME proposes that multipart/alternative be used to present a readable
form and a signed form of the same document. That's fine as far as it goes, but
the semantics of *why* the alternative is being used aren't attached. And this
proposal effectively assumes that the semantics are attached. But you could
come up with exactly the same structure had your intention been to present a
signed version of the document in English along with an unsigned version of the
document in Spanish. The resulting structure is the same and there's no way
software can tell the difference, but of course the signatures cannot possibly
match. THere's no reason why they should match, of course, but since the
software doesn't know why the alternative is being used its in no position to
judge that.
Incidentally, the problem of the mixed semantics in the interpretation of
multipart/alternative is a well known one that has been discussed many times in
the MIME community. Any person who has paid attention to the details of the
process there knows about it. And various suggestions have been made as to how
it could be fixed -- usually along the lines of a "difference" parameter that
defines the distinguishing criteria amongst the alternatives. But the consensus
has always been that this sort of clarification is too little, too late. The
general conclusion is that multipart/alternative, while quite useful in the
small, doesn't scale well at all and should not be overloaded lest it break
down completely.
This would be a good thing to suggest in the S/MIME spec, thus closing
the "security hole."
Sorry, not only does it not close the hole, by suggesting this you guarantee
the generation of lots of spurious "signature didn't match" warnings. Everyone
knows that software that cries wolf too often tends to get ignored (that pesky
human nature thing again), so in effect this proposal just makes the hole
bigger than ever.
Ned