What if I have a multipart/mixed MIME message. The first part is just
text, and the second part itself is a multipart/signed MOSS message.
Is this allowed?
Sure its allowed.
What would happen if I sent this off to a remote validation server?
Would it try to tell me "Well, the first part of your message was not
signed and I can't say anything about that, but the other part has a
valid signature." ?
This is one option, but I doubt it will be a popular one. A more popular one
would be to have the remote validation server refuse to verify anything that's
not signed in its entirety. This will be completely configurable in any
reasonable server.
The same thing applies to user agents, both for security multiparts and for
S/MIME, BTW -- since users cannot be expected to understand structural nuances,
agents must be prepared to present things so its clear what is going on. And
far and away the simplest way to insure this is to restrict the number of
allowed formats.
If so, how would this be different from a remote
validation server saying the same thing about the first and second
parts of a multipart/alternative message with an S/MIME signed message
in the second part?
Its different because most security multipart messages will be signed in their
entirety. There is no reason to do otherwise. This contrasts sharply with
S/MIME, where most if not all messages are destined to be in some variant of
this peculiar format, where servers will have no choice but to deal with a
mixed semantic bag.
Issues surrounding the use of partially signed MIME objects, multiply signed
MIME objects, and most especially partially and multiply encrypted MIME objects
are known to be incredibly tricky. We've discussed some of this on this list in
the past, and generally agreed not to open this particular door at the present
time.
For one thing, it just doesn't make much sense to get into a detailed
discussion of complex object semantics until we have a better idea of how these
services are actually used -- we may well spend all our time discussing
variants that are never used operationally while ignoring variants with great
operational importance.
Neverthless, this is definitely an area where lots of additional work is
needed. I for one plan to return to it in the future, but not before more
pressing matters, i.e. general deployment of MOSS, are well in hand.
Ned