I expect to see lots of environments use remote verification services for
signatures, where messages are forwarded to a remote verifier.
I suspect that this will not be the case, but alas, the market will decide
for both of us. Also, I can't imagine why a remote verification service
can't return to the client the verified text. Perhaps you have some
additional insight into how such remote verification services will work.
Steve, the problem isn't whether or not the use of this model is widespread. I
think you're dead wrong about this and are ignoring the reality of a huge,
real, and demonstrable installed base, but what I think doesn't really matter.
The problem is that your design assumes that its an unreasonable thing that
nobody will ever do. But it is nothing of the sort. Around here we try very
hard to design systems that work under all reasonable conditions. This is a
reasonable condition and your system doesn't handle it right. I therefore
conclude that S/MIME is fatally flawed.
As for people reading the result of the verification, sure they may do this.
But how many people will bother when they have the alternative text right in
front of them? They're going to read what's in front of them right now, send
the thing off to be verified, and ignore the content of what comes back from
the verifier. It is simply human nature to do this.
While we're on the topic of multipart/signed versus multipart/alternative,
I'd like to bring up the next point that was made during the architecting
of the S/MIME spec.
The multipart/alternative construct was deemed more useful for backward
compatability to non-MIME readers. This is because the "alternative" part
is in readable ASCII. The use of multipart/signed infers a requirement
that the "signed" text be transported from sender to recipient intact. In
practice, this would cause a tendency to encode the text for transport
rendering it unreadable by non-MIME readers.
This reasoning once again demonstrates a real lack of understanding of both the
design principles of MIME as well as a lack of understanding of what real-world
MIME deployment looks like. The reality is that there is no requirement that
the text in a multipart/signed be encoded into an unreadable format for safety,
so people won't do it. This is both a design principle and an implementation
reality. There simply is no "requirement" here, implied or otherwise. In
addition, the reality of multipart/alternative is that parts are often encoded
in exactly the same way as multipart/signed will be -- using the
quoted-printable encoding. As such, you gain nothing and lose much with your
approach.
Ned