At 6:55 PM -0700 7/30/97, John Gardiner Myers wrote:
[blues (clear signed) and reds (opaque signed) deleted...]
And an apparent problem with multipart/signed is that it is sometimes
transparent in contexts where it is desired to be opaque.
Exactly right.
Well, it appears to be a natural law that you can have "red" or "blue",
but not both.
You can allow both types to be sent and describe how recipients should
handle each. That's what's in the S/MIME spec.
Some people are saying that they have a need for "red"
properties. I'm saying that if there is a sufficiently strong need for
something "red", then design something that is good at being "red" and
which can be easily converted from and to things which are "blue".
The latter part does not describe signedData since it cannot be easily
converted by a human reader.
Don't try to design something which is both sort of "red" and "blue" at
the same time, as you're going to end up with something which is
neither. Drive on one side of the road or the other, don't drive on the
median.
I think you're missing the point in S/MIME: you can choose either.
I've read all over the archives of pem-dev and I just don't understand
the engineering logic behind the proposed form and use of
application/mime. We like multipart/signed because the signed content
can be read by the installed base. But the signature on a
multipart/signed gets munged by some existing gateways, and some UAs
can't dispatch on a multipart/signed. So, we want to stick in a shim to
make the multipart/signed opaque to said gateways and dispatchable to
said UAs. Except the shim also makes the multipart/signed opaque to the
installed base of MIME-aware UAs.
This is a conscious design decision to, if necessary, make messages more
likely to be human readable than to be dispatchable by MIME-aware UAs that
do not follow the S/MIME spec. Said a different way, app/mime will probably
break the signature-verifying capabilities of a small number of non-S/MIME
UAs but will let the large number of people with non-S/MIME UAs read the
messages sent to them.
Yes, we are favoring the human over the legacy non-S/MIME MUAs. That's
purposeful.
So, people are therefore expected to
run around changing their installed base of UAs to be able to deal with
the shim,
They don't need to do this if they followed the S/MIME spec.
Also, it is unclear how many non-S/MIME UAs that can process
multipart/signed X.509 signatures exist. I believe the number is
vanishingly small. The few PGP/MIME UAs deployed can't handle X.509
signatures, so they don't count. I think that leaves PEM clients. We are
saying "those few PEM clients aren't as important as people who don't have
S/MIME being able to read a signed message."
--Paul E. Hoffman, Director
--Internet Mail Consortium