On Wednesday, July 30, 1997 12:01 PM, James M. Galvin
[SMTP:galvin(_at_)commerce(_dot_)net] wrote:
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.
The big win is for people who value the signatures more than the
content. Some people might argue "What good is a signature if you can't
verify it?" The current community of people playing with digital
signatures and "gee it's cool that I can digitally sign things" are
going to move closer to "if it ain't signed, or the signature isn't
valid, I don't want it". We are introducing a mail gateway product with
extensive digital signature processing features (our marketing guys call
it an "email firewall" to emphasize the security aspect of it) that can
enforce that exact semantic by customer request: if it ain't signed,
bounce it.
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/*).
So, while it may be a technical move forward, it's not making things any
easier for the user.
Actually, the current spec with signedData vs. multipart/signed already
introduces this problem. Because Netscape *absolutely will not* send
signedData means that someone on the receiving end that does not have
MIME preservation to the point where the signature is verified (read:
LAN email systems, AOL, CServe, etc.) will never, ever, ever be able to
verify a signed message from a Netscape user. Likewise, because Secure
Messenger (WorldSecure Client) for Microsoft Exchange *absolutely can
not* send multipart/signed, someone on the receiving end that does not
have an S/MIME client will not be able to read the received message at
all (unless the user has something to mine his content out of the PKCS
#7 wrapper). Depending on your point of view, each of us is wrong --
because Netscape can't send signedData, there are some cases where the
signature simply cannot be transmitted, so if signature preservation is
your top priority, you can't do it. Because we can't send
multipart/signed from Exchange, there are some cases where the content
simply cannot be read, so if content preservation is your top priority,
you have a workaround which is to send it unsigned to the non S/MIME
recipients.
We have implemented our user interface in such a way that the user is
isolated from this decision. In the event that all of the recipients
are "preferSignedData", then we send the message as signedData -- no
problem. If any of the recipients do not have SMIMECapabilities (we
don't know if they can even receive S/MIME in this case), the user is
warned that this signed message may not be readable by some of the
recipients (since we can't send multipart/signed from Exchange). The
user is presented with the option to remove recipients, or to send the
message anyway. The bottom line is that we do everything we can to make
sure that a non-S/MIME recipient doesn't ever see signedData.
My hope was that the discussion of application/(signed or mime) would
lead us to a suitable replacement for signedData since it could be a
single MIME part that could encapsulate with transfer encoding a
multipart/signed entity. This would solve the problems that signedData
solves (integrity during transmission and keeping the content and the
signature together in a verifiable way), without the nasty side-effect
of giving non-S/MIME clients a PKCS #7 encoded pile of junk with their
MIME strewn about inside of it. At the very least, a client that
received application/signed that didn't know anything about S/MIME would
be able to take the contents and run it through a MIME viewer to get
something nice -- the additional step of removing the PKCS #7 wrapper
wouldn't need to happen.
Blake