First, let me reiterate that the intention in the S/MIME spec was to
encourage the addition of PKCS security to unencoded (e.g. binary) MIME
objects.
I can envision two different cases here.
In the case where security processing will be done by the user agent, such an
agent must be "upgraded" to support S/MIME. In this case, it seems that we
have
(inadvertantly ?) levied a requirement for such an agent to correctly handle
binary MIME as well. This is certainly not clear from the S/MIME spec and
should be addressed. I'm very interested in feedback from developers of
S/MIME-aware user agents as to whether this requirement presents significant
barriers to deployment.
In the case where a "remote validation server" is to perform security
processing
and pass the results on to "existing" MIME agents (some of which may not
support
binary MIME), let me propose the following; remote validations servers which
are
upgraded to handle S/MIME must also be capable of handling binary MIME and may
(must ?) recode any embedded binary MIME parts into 7 bit (after security is
removed) for consumption by the user agents.
Is this a reasonable approach? Would this work for the security/multiparts
approach as well?
First of all, I find your logic to be more than a little contradictory:
(1) Your stated reason for rejecting the security multiparts approach and using
what S/MIME specifies was because of your belief that existing agents will
not support automatic treatment of multipart/signed and
multipart/encrypted as multipart/mixed. (I note once more that the MIME
specification clearly mandates that this form of defaulting be supported
by all agents and I have yet to see an example surface of an agent that
actually has the characteristics you believe are commonplace.)
(2) S/MIME requires that all S/MIME agents support binary MIME. Examples
abound of agents that do NOT provide such support, nor is such
support required in order to be MIME conformant. (The obvious example I
can cite is Innosoft's PMDF product, which supports binary MIME only in an
SMTP context. Supporting it elsewhere gets into all sorts of nasty
line terminator canonicalization issues, so much so that its doubtful
we'll ever provide such facilities. Pine doesn't support binary MIME at
all. I just checked the Metamail sources, and it definitely doesn't handle
binary MIME correctly, and the number of agents based on MetaMail is
*enormous*. In fact the only agents I know of that support binary MIME in
an email context are a couple of esoteric ones used in voice messaging.)
So in one case your design was supposedly influenced by a desire to cater to
existing in-the-field reality, whereas in the other case you seem to be willing
to require what amounts to a complete rewrite of in-the-field agents to support
binary MIME, thus ignoring in-the-field reality completely.
This just serves to strengthen my position that S/MIME is a flawed
specification that needs to be reworked to use security multiparts.
Now let me return to your questions. The answer is no, I don't think it is
reasonable to ask agents to support binary MIME. Binary MIME is very tricky
stuff, and supporting it fully may be anywhere from difficult to outright
impossible, depending on the file system and operating system being used. (For
example, look at supporting arbitrary binary sequences in TCL.)
As for whether or not this approach would work with security multiparts, I
believe I already answered that. In the case of multipart/signed binary MIME is
a total non-starter since you cannot predict what transports will be used
downstream from you and you cannot change the encoding of the signed part
mid-stream. This implies that you have to use a a lowest-common-denominator
encoding from the start. In the case of multipart/encrypted binary MIME may or
may not be viable, since it depends entirely on the domain of applicability of
the security service. This is why we left it up to the specific security
service to specify what you can or cannot use. In considering a PKCS#7 security
multiparts combination I'd say that the best approach would be to restrict
what's allowed in the secured context to 8bit. I'd also recommend speedy
specification and deployment of a more efficient encoding for use in such
contexts.
Ned