Note, however, that the contents of multipart/signed are supposed to be
7bit-friendly when multipart/signed is used with potentially 7bit-only
transports like SMTP. Unfortunately clients exist that botch this.
So I was thinking: Would it be reasonable for us to create a field for the
signature sort of like:
Content-Signed-Part-Encoding: 8bit
which would indicate the CTE used to compute the signature? That way, if an
MTA does downgrade a message, the signature can still be verified because
you can always recover the original content after a downgrade.
I don't think this has much chance. Deploying such a field would certainly be a
nightmare, as it requires new support in things generating signatures, checking
signatures, and doing MIME downgrades.
Changing signature generators is the easiest thing: Just generate the new
field. (It has to have exactly the same value as the CTE field, but that's
easy.) But if you're going to make a change in signature generation, why not
simply change things generating signatures to generate 7bit material?
Systems doing downgrading have a bigger problem. They have to:
(1) Check and make sure this field is present on every 8bit part.
(2) Check and make sure a corresponding CTE field is also present with
identical content, down to the letter.
(3) Encode the part.
(4) Change the value of the CTE to base64 or quoted-printable, but making
sure not to change the positioning of any of the fields and making sure
not to change the spelling of the CTE field label.
I'm also not sure what you do if you're halfway through a complex structure and
find a part that doesn't satisfy (1) or (2). Punt?
Changing signature verifiers is also fairly nasty:
(1) Change the CTE field value back to the contents of the CSPE field. Again,
this has to be done without changing positioning or anything else.
(2) Decode the part prior to MIC caculation.
All this is necessary, of course, because the signature is computed across
part headers (and MIME boundaries and whatever else).
The cost of implementation here is high, far higher than the benefits we'd see
from something like this, so I doubt that many people would implement this.
That's why we didn't define something like this in the security multiparts
document. We did consider this and quite a few similar schemes -- at great
length and in detail.
I think a better way to resolve this problem is to define a different canonical
form for use in computing hashes. (The key characteristic of the new form needs
to be that the hash of part data is done under the encoding.) This could be
indicated in the micalg field by a different hash name. I've been meaning to
write an RFC defining such a thing for quite some time but haven't managed to
find the time to do so. This is also hard to deploy, but has the added benefit
of resolving a different problem, specifically that message stores have to
store both encoded and decoded parts when handling multipart/signed. Many
people believe this is a far more serious problem than an occasional signature
mismatch caused by poor encoding choices, enough that we might just possibly
get some buy-in and some resulting deployment of such a mechanism.
Ned