Subject: Re: 8BITMIME to 7BIT
From: Ned Freed <[email-masked]>
To: Pete Resnick <[email-masked]>
Cc: [email-masked]
Date: Fri, 10 Jul 1998 14:41:54 -0700 (PDT)

> > 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

Date: Fri, 10 Jul 1998 10:56:05 -0700
To: [email-masked], [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Re: 8BITMIME to 7BIT
Sender: [email-masked]

A discussion started over on the international mail list, but the question
I had seemed more appropriate for ietf-smtp and ietf-822. I've Bcc'ed the
international mail list.

On 7/8/98 at 7:21 PM -0700, Ned Freed wrote:

>You have to check for and make sure not to change anything within a
>multipart/signed. (Multipart/encrypted is a nonissue, as the entire part is
>encoded.) If the multipart/signed contains 8bit I currently default to sending
>it through untouched, which of course is technically illegal but works often
>enough that it rarely results in a problem. I also support configurations
>where
>the signature is simply removed in such cases, either with or without an
>attempt to verify.
>...
>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.

The rule for gateways would be: When downgrading a multipart/signed which
already has a Content-Signed-Part-Encoding, preserve that field exactly as
it was. If there is no Content-Signed-Part-Encoding, add one.

Anyone who's currently following the rules and sending 7bit encodings would
still be fine. Anyone who's breaking the rules and sending 8bit or binary
encodings without any labeling may get some help during the downgrade. The
only problem's going to be recipients who can't verify the signature
because they don't recognize to upgrade back to the CSPE, but there was
some chance that those would fail anyway because the originator sent 8bit
blindy in the first place.

Comments?

pr
--
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated
Work: (217)337-6377 or (619)651-4478
Fax: (217)337-1980 or (619)651-1102